Asymmetric Research Asymmetric Research × Solana Foundation Solana Foundation

Operational

Operational security covers the people and devices that run the protocol. These controls assume the program is sound and ask what an attacker can reach anyway, whether a laptop, a Discord account, or a signer who does not check what they sign.

Team laptops and phones hold sessions, credentials, and signing keys. Attackers who cannot break the program instead target the device of someone who can change it.

O1.1

Endpoint detection and response (EDR) is deployed across all team devices.

O1.2

Mobile device management (MDM) is deployed across all team devices.

O1.3

Timely OS patching, disk encryption, and other critical OS security controls are enforced.

O1.4

Offboarding includes a device audit, and remote wipe capability is in place.

O1.5

Endpoint compliance is enforced, not assumed.

Multisig thresholds only count independent verifications. When every signer approves whatever the same interface displays, compromising that interface defeats a 4-of-7 as easily as a single key.

O2.1(critical control)

Signers use hardware wallets on dedicated devices.

O2.2(critical control)

Transactions are verified out-of-band before signing, for example in a separate channel that confirms transaction details or in an alternative Squads UI.

O2.3

Signing procedures are documented and state what signers must verify.

O2.4

Signer availability and backup procedures are in place.

Permissions granted for a role tend to outlive the role. People join, move teams, and leave faster than access gets cleaned up. Enforced checklists and periodic reviews keep access matched to current need.

O3.1

All internal systems sit behind SSO with hardware 2FA.

O3.2

Access is provisioned following least privilege.

O3.3

Onboarding, offboarding, and eviction checklists are in place and enforced.

O3.4

Access reviews are conducted periodically to catch stale permissions.

A hijacked official account reaches users with the protocol’s credibility intact. One malicious link posted from it can drain the wallets of everyone who trusts the source. These controls keep account access narrow, audited, and recoverable.

O4.1

All protocol-controlled channels are secured with hardware 2FA where possible.

O4.2

Bot permissions and webhook access on Discord, Telegram, and similar platforms are audited and restricted.

O4.3

Admin access is restricted.

O4.4

Admin access is logged.

O4.5

Shared credentials are avoided.

O4.6

Recovery procedures for a compromised channel are documented.

Treasury controls apply separation of duties to the protocol’s own funds. Defined limits, logged movements, and regular reconciliation make an error or an unauthorized transfer visible before it compounds.

O5.1(critical control)

Operational and reserve funds are held in multisig wallets with appropriate thresholds.

O5.2

Spending limits are defined.

O5.3

Approval workflows for spending are defined.

O5.4

Fund movements are logged.

O5.5

Fund movements are reconciled.

O5.6(critical control)

No single individual can move protocol funds.

The inventory records every system, who owns it, and what sensitive data it holds. Systems missing from the inventory are missing from patching, access reviews, and offboarding as well.

O6.1

All systems are inventoried, each with a named owner.

O6.2

Sensitive data in each system is understood, cataloged, and documented.

O6.3

The inventory is kept current through onboarding and offboarding processes.

O6.4

The inventory is kept current through periodic review.

Validators, relayers, keepers, and fee payers sign with keys that live on operational hosts. Rewards and fees build up in the accounts those keys control. An attacker who compromises a host takes whatever balance sits there. Scheduled sweeps to custody cap that balance. Some accounts, such as vote and stake accounts, name a separate withdraw authority. Keeping that authority off every host protects the full balance of those accounts.

O7.1

Every account controlled by an operationally hot key is inventoried with a defined maximum balance. This includes validator identity and vote accounts, relayers, keepers, and fee payers.

O7.2

Rewards and accrued balances are swept on an enforced schedule with a defined maximum interval. No operational host key controls the destination. Onward movement from the destination requires multi-party authorization, such as a multisig, an HSM with policy enforcement, or a custodial account with enforced withdrawal approval and an address allowlist.

O7.3

Hot account balances and sweep completion are monitored, with alerts when a balance exceeds its defined maximum or a scheduled sweep does not land.

O7.4(critical control)

Where an account names a withdraw authority separate from its operating key, that authority is held in multisig, HSM, or hardware-wallet custody. It is not present on any operational host, including sweep automation.