> ## Documentation Index
> Fetch the complete documentation index at: https://new-docs.squads.so/llms.txt
> Use this file to discover all available pages before exploring further.
# Advanced security guide
> Advanced security practices for high-value Squads accounts
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.
This guide is for teams managing high-value treasuries, onchain programs, or protocol infrastructure. Most teams are well covered by the fundamentals in [Best Practices](/resources/multisig-best-practices).
## 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.
| Sub-account | Assets | Security level |
| - | - | - |
| **Reserve** (85-95%) | Long-term holdings, runway | Higher threshold, extended time locks, hardware wallets only |
| **Operations** (5-15%) | Payroll, vendor payments, daily expenses | Standard threshold, accessible key management |
| **Program upgrades** | Dedicated to deployments | Isolated from both reserve and operations, highest threshold |
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.
| Role | Can do | Use for |
| - | - | - |
| **Proposer** | Create transactions | Operational staff who identify what needs to happen |
| **Voter** | Approve or reject transactions | Signers who review and authorize actions |
| **Executor** | Submit approved transactions onchain | Signers responsible for final execution |
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](https://explorer.solana.com/tx/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](https://github.com/Squads-Protocol/public-v4-client) and [CLI tool](/developers/cli/cli-install-and-commands) provide alternative interfaces for independent verification.
Using a V3 Squad? See the [V3 CLI](https://github.com/Squads-Protocol/squads-cli) and [V3 backup client](https://github.com/Squads-Protocol/public-v3-client) for verification tools.
## 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.
Durable nonces allow transactions to remain valid indefinitely, bypassing the two-minute rule. Before relying on this protection, verify the initiator has no durable nonce accounts using `getProgramAccounts` calls. Check that the displayed fee-payer matches the initiator's public key. If Fee Relayer is enabled, the fee-payer should match the Fee Relayer address in **Settings**.
## Verifiable builds for program upgrades
When upgrading onchain programs through your Squad, verify the deployed code matches what was reviewed.
Build the program on your machine to generate a unique cryptographic hash of the compiled binary.
Deploy the compiled program to a Solana buffer account without upgrading the live program.
Distribute the expected hash to all signers through a secure channel before anyone approves.
Each signer independently verifies the buffer content matches the expected hash. Use `solana program dump` to download the buffer contents and compare the hash.
Once verified, execute the upgrade transaction to deploy from the buffer to the program account.
After execution, verify the deployed program hash matches what was reviewed.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.