Advanced security guide

Squads Protocol is audited, formally verified, and immutable. But your operational habits determine whether your assets stay safe. Most losses come from compromised keys or procedural failures, not smart contract exploits.

​

How Squads enforces security

Every action in a Squad follows a sequential, fully onchain lifecycle: a signer creates a transaction, other signers approve it, and once the threshold is met, any signer with execute permission submits it to the network. Each step is recorded onchain independently. This architecture creates an immutable audit trail. The transaction content is fixed at creation and cannot be modified during the approval process. Each approval updates the transaction’s status without changing the underlying action. Squads never sends the same transaction to multiple signers - it only updates the state with each signature. This sequential structure is what makes the practices below effective. Verification works because transaction content is immutable. The two-minute rule works because each approval is a separate onchain event. Treasury segmentation works because sub-accounts are isolated at the protocol level.

​

Treasury segmentation

Separate assets across sub-accounts based on risk profile. If your operations account is compromised, most assets remain protected in your reserve. Replenish the operations account from the reserve periodically rather than keeping large balances in your most-accessed account. Choose time lock durations based on the account type: longer intervals for treasury transfers where additional review time helps, shorter intervals for program upgrades that may require faster responses.

​

Device security

• Use dedicated hardware wallets. Reserve specific devices exclusively for Squad operations. Do not use them for browsing, email, or other applications.
• Prioritize initiator devices. Apply the strictest security to devices used for creating transactions, as initiated content becomes immutable onchain.
• Diversify hardware vendors. Use wallets from different manufacturers across signers to prevent single-vendor vulnerabilities.
• Diversify platforms. Use a mix of mobile and desktop devices with hardware wallets across signers to reduce the impact of a platform-specific vulnerability.
• Avoid daily-use devices for signing. Devices used for general browsing have a larger attack surface than dedicated hardware.
• Rotate keys when needed. Replace any key that has been exposed to unauthorized parties or used on a device that was not properly isolated.

​

Role separation

Split permissions across signers so that no single person can initiate and execute a transaction alone. Restrict Proposer permissions to reduce the risk of malicious transactions. The initiator defines what gets recorded onchain, making it the highest-risk action.

​

Signing practices

Before approving any transaction:

1. Check the recipient address matches what you expect
2. Verify the token and amount are correct
3. Confirm with other signers through a live channel (call, video, in-person) and verify each approval has been registered before the next signer proceeds
4. For program upgrades, verify the buffer hash matches what was shared
5. Approve and execute in separate steps. Avoid “Approve + Execute” for high-value transactions, as it combines two security checkpoints into one

​

Verify transactions before executing

Use the Solana Explorer Inspector to simulate transactions and inspect results before execution. Confirm the programs your transaction is calling are ones you recognize, as malicious programs can change execution behavior between simulation and execution.

​

What to look for

BPFLoaderUpgradeab1e11111111111111111111111:

• “New authority Some(XXX)”: This changes the buffer or program authority to a different wallet. Confirm this is your intended action and verify the new wallet address is correct.
• “Upgraded program XXX”: This upgrades the specified program. Verify this upgrade is expected and matches what was reviewed.

Token Program (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA):

• “Instruction: Approve”: This delegates funds to another wallet. Confirm the delegation is intended, as misconfiguration can lead to loss of funds.

Double-check the tokens and amounts that will move. For swaps, other tokens may move as part of the transaction, but the total value should align with what you intended.

​

Use multiple verification interfaces

For high-value accounts, verify transactions through more than one source. A compromised frontend could display incorrect details. The backup UI and CLI tool provide alternative interfaces for independent verification.

​

The two-minute rule

When multiple signers approve a transaction sequentially, each signer should wait at least 2 minutes before the next proceeds. Why this works: Solana signatures are linked to blockhashes that expire after 150 blocks, which is well under a minute at current block times. If an attacker captures a signature during one step, it becomes useless after the blockhash expires. Each signer can verify that no unexpected transactions appeared during the wait.

​

Verifiable builds for program upgrades

When upgrading onchain programs through your Squad, verify the deployed code matches what was reviewed.