Advanced Security Best Practices
Advanced best practices to safeguard your assets.
This guide provides comprehensive security recommendations for organizations using Squads to manage digital assets. Following these best practices will help protect your treasury and program upgrades from both external and internal threats.
Table of Contents
General Overview
An important element of Squads' security is its transparent, sequential transaction process. This sequential structure comes from Squads Protocol's architecture, where each transaction follows a verifiable, onchain lifecycle:
Initiate: A transaction is proposed and recorded onchain. This creates both a transaction account (containing the actual transaction data to be executed) and a proposal account (for tracking approvals). Transaction details include a unique transaction ID that all members can cross-reference to ensure they're approving the same transaction.
Approve: Signers review and provide onchain signatures to approve the transaction. Each signature modifies the proposal account's state rather than changing the transaction account. This approach preserves the original transaction while tracking approval progress.
Execute: Once the multisig threshold is met (minimum required approvals), the transaction is executed onchain. The system verifies the proposal account's status before processing the unchanged transaction account.
This sequential, fully onchain approach creates an immutable audit trail that enables users to self-verify transactions and eliminates opportunities for manipulation between approval and execution stages. Squads never sends the same transaction to multiple signers - it only updates the proposal state with each approval.
Core Security Practices
Squads Multisig Configuration
Higher approval threshold: Implement a threshold of 4/6 or higher to ensure multiple signers are required for transaction approval, adding layers of security against individual compromises.
Time Locks: Enable time locks to defer execution of approved transactions for a set period. This creates a safety window to respond to potentially unauthorized transactions even after approval. Choose appropriate durations—shorter intervals (e.g. 10-15 minutes) for program upgrades that may require quick responses, longer intervals for treasury transfers where additional review time enhances security.
Key Rotation: Rotate keys that have been potentially exposed to unauthorized parties or not properly isolated from external systems.
Separate Approval and Execution: Always approve and execute transactions in separate steps. Avoid using the "Approve + Execute" feature for maximum security.
Diversify signing interfaces and devices: Employ signers using both mobile and desktop with hardware wallets to enhance security through diversity.
Transaction Verification
Live communication: Maintain live communication with other signers during transaction approval, ensuring each signer's approval has been properly registered before proceeding.
Transaction simulation and inspection: Simulate transactions and check the results using Solana Explorer Inspector to ensure expected behavior before execution.
Guidelines on Simulating Transactions:
When reviewing a simulated transaction, check the simulation details in the Explorer Inspector. This step ensures that the transaction will perform as intended before executing it. Ideally also ensure the programs your transaction is calling are known to you, as malicious programs have the ability to change execution behavior between when you simulate and when you execute.
Here are specific elements to watch out for and how to handle them:
BPFLoaderUpgradeab1e11111111111111111111111:
"New authority Some(XXX)": When you see this message, it means you are changing the buffer/program authority to a different wallet. Confirm that changing the authority is your intended action, and verify that the new wallet address (XXX) is correct.
"Upgraded program XXX": This message indicates that program XXX is being upgraded. Review the transaction details to ensure that this upgrade is expected and intended as part of the transaction.
Token Program (TokenkegQfeZyiNwAJbNbGKPFXCWuBvf9Ss623VQ5DA):
"Instruction: Approve": This means that you are delegating funds to another wallet. Confirm that this delegation is intended, as any misconfiguration can lead to a loss of funds. If delegation is not intended, take immediate action to correct it.
In addition, double-check the tokens and amounts that will be moved by any transaction. In cases where swaps are involved, be aware that other tokens may be moved as part of the swap, but the total USD value should still align with what you intended.
Treasury Segmentation
While transaction controls like time locks protect individual transactions, treasury segmentation provides an additional layer of security at the organizational level. This strategy involves creating a "cold", advanced security Reserve Treasury account where your business secures the majority of your assets and one or more operations accounts for everyday use that require a lower level of security.
Reserve Treasury
Contains 85-95% of your total assets
Employs stringent security: higher thresholds, extended time locks
Reserved for infrequent transactions and long-term asset storage
Advanced key management practices (e.g. only use dedicated devices/hardware wallets) for maximum protection
Operations Account
Holds 5-15% of funds for routine transactions
Uses more accessible security: lower thresholds, accessible key management
Handles payroll, vendor payments, and daily operations
Receives periodic replenishment from the Reserve Treasury
Program Upgrade Account
Dedicated account with specialized security for program upgrades
Separate from both reserve and operations to isolate upgrade permissions
Employs stringent security: higher thresholds, time locks
Advanced key management practices (e.g. only use dedicated devices/hardware wallets) for maximum protection
This structure compartmentalizes risk—if your operations account is compromised, most assets remain protected in your more secure reserve treasury. Meanwhile, your team maintains the operational flexibility needed for day-to-day activities without navigating excessive security hurdles for routine transactions.
Program Upgrades: Double Verification and Verifiable Builds
Understanding Buffer Accounts
A buffer account is a temporary onchain storage location that holds program code before it's deployed to its final program address. This intermediary step allows for verification before execution of the upgrade.
Key Functions:
Stores the compiled program binary data onchain
Enables verification before the actual upgrade occurs
Provides a checkpoint for security review
Verifiable Builds
Verifiable builds ensure the integrity of program code throughout the upgrade process by generating a cryptographic hash that can be independently verified by all team members.
Implementation Process:
Build your program locally, generating a unique cryptographic hash
Deploy the program to a buffer account
Share the expected hash with all team members
Team members independently verify the buffer content matches this hash
Execute the upgrade from buffer to program account
Post-upgrade, verify the deployed program hash matches the verified buffer
This process confirms deployed code matches the audited version, prevents unauthorized modifications, creates an audit trail through git commit references, and enables external verification of deployed programs against audit reports.
Squads Frontend Verification
Accounts with high-value operations - such as Reserve Treasury and Program Upgrade accounts - should ensure transaction integration and the validity of the Squads frontend using multiple interfaces.
Explorers
Explorers provide basic transaction verification but have limitations:
Current Capabilities:
View transaction metadata, status, IDs, and associated accounts
Confirm transaction creation time
Limitations:
Limited parsing of complex transactions and inner instructions
We are currently working with Solana Foundation on parsing Squads transactions in the Solana Explorer and implementing Squads transaction parsing in the Range interface.
CLI Tools
Direct Interaction:
Users can interact directly with the Squads CLI for core transaction operations. The CLI enables programmatic control of Squads multisig accounts without relying on web interfaces
Links to our CLI tools: Squads v3 CLI and Squads v4 CLI
Transaction Verification (coming soon):
No dedicated verification tool exists yet for Squads transactions
A comprehensive CLI tool is under development to automate transaction parsing and verification
Run UI Locally There are two lightweight backup front-ends designed for easy verification, decentralization, and security. These clients are just five files each, making them simple to hash against a commit, deploy to IPFS, or self-host—ensuring complete transparency:
Download and run the Squads lightweight front-ends from GitHub:
Range Integration (coming soon)
Range will provide enhanced verification through automated notifications, human-readable transaction parsing, risk assessment, and detailed verification interfaces.
Cold IPFS Frontend & Onchain Verification (coming soon) Squads will deploy a minimalist “cold” frontend on IPFS that operates completely independent of Squads’ infrastructure, reducing dependency on Squads’ servers and web interface. This approach enhances security by removing exposure to potential Squads infrastructure compromises and dependencies on local environment security. This “cold” frontend is ideal for large-value accounts (e.g., Reserve Treasury and Program Upgrades). Additionally, builds will be hashed accordingly by release and have the hash published on Solana, IPFS, and other relevant channels. Users can then verify the authenticity of the client themselves, regardless of origin (IPFS, self-hosting, etc).
Mitigating Signer Attacks
Protecting individual signers is fundamental to maintaining the integrity of your multisig operations. By implementing these security measures, your team can significantly strengthen your overall security:
Dedicated Hardware Security
Dedicated Devices
Use dedicated hardware wallets exclusively for Squads transactions
Never use these devices for other applications, especially for keys with initiate permissions
Diversify Hardware Vendors
Use hardware wallets from different manufacturers (Ledger, Trezor, Keystone)
Hardware diversification prevents single-vendor vulnerabilities
Initiator Security
Transaction initiators pose the highest security risk since they define what gets recorded onchain:
Transaction content becomes immutable once initiated
Apply strictest security measures to devices used for initiation
Restrict initiation rights using Squads Permissions
Role-Based Permissions Squads Permissions offers three distinct roles:
Proposer - Can only create transactions
Voter - Can only vote on proposed transactions
Executor - Can only execute approved transactions
Limiting who can initiate transactions creates a critical security barrier at the most vulnerable point in the workflow.
The Two-Minute Rule
The sequential nature of Squads transactions, combined with Solana's blockhash expiration, creates a powerful security mechanism:
When multiple signers need to approve a transaction:
After initiation, each signer should wait 2 minutes before the next person proceeds
This waiting period allows the blockhash to expire
If no suspicious transactions appears during this 2-minute window, the next signer can safely proceed
Why This Works:
Solana signatures are linked to specific blockhashes
These blockhashes automatically expire after 2 minutes
If your device is compromised and someone captures your signature, they only have a 2-minute window to misuse it
After 2 minutes, the captured signature becomes useless for malicious transactions
Because the transaction content is fixed onchain at initiation, signers can verify they're approving the intended transaction through multiple independent sources
Durable Nonce Exception
The two-minute rule depends on blockhash expiration, but durable nonces bypass this protection:
Durable nonces allow transactions to remain valid indefinitely
If the initiator has a durable nonce account, the two-minute rule is ineffective
To ensure a durable nonce transaction is not involved:
Verify the initiator has no durable nonce accounts using getProgramAccounts calls
Ensure the displayed fee-payer for transactions matches the initiators public key (if your Squads Fee Relayer is turned on, then the fee-payer should be the Fee Relayer key address of which you can find in Settings)
Last updated