> ## 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. # Best practices > Security fundamentals and setup recommendations for Squads Operating a multisig means shared responsibility. This page covers the security fundamentals and setup recommendations every Squad should follow. ## Key management Always keep backups of your private keys. If enough keys are lost that your Squad can no longer meet the threshold, your assets become permanently inaccessible. * Store keys with different team members in separate physical locations * Use hardware wallets for all members on high-value Squads * Distribute members geographically to reduce correlated risk (theft, natural disaster) * Never store multiple member keys on the same device or in the same location ### Compatible wallets Any Solana wallet can be added as a Squad member. Hardware wallets provide stronger security for high-value accounts. Below are examples of compatible wallets: | Type | Examples | Best for | | - | - | - | | **Hot wallets** | Phantom, Backpack, Solflare | Daily operations, lower-value accounts | | **Hardware wallets** | Ledger, Trezor, Keystone | High-value treasuries, program upgrades | Connect your Ledger through Phantom or Solflare. Enable Blind Signing and ensure firmware and the Solana app are up to date. The connect dialog also lists **WalletConnect** (Ledger Live and mobile wallets) and **Trezor**. ## Threshold configuration Your threshold determines how many members must approve before any action executes. See [How Squads works](/getting-started/how-squads-works) for a full explanation. | Configuration | Trade-off | | - | - | | **Too low** (e.g., 1-of-3) | Single point of failure. One compromised key can drain assets | | **Too high** (e.g., 5-of-5) | One lost key locks the Squad permanently | | **Recommended** (e.g., 2-of-3, 3-of-5) | Tolerates a lost key while still requiring multiple approvals | ## Two-person teams For Squads controlled by two members, we recommend the following setup: **Add 4 members to the Squad (2 keys per person) and set the threshold to 3 of 4.** **Why this works:** both people still need to sign every transaction - two keys alone cannot meet the threshold of 3. But if one key is lost, the remaining three keys still meet the threshold, so the Squad is never locked. And if one person is fully compromised, the attacker only controls 2 keys and cannot act alone. Keep your two keys on different devices. A daily wallet on your computer and a hardware wallet stored separately ensures that a single device compromise does not expose both keys. All four keys can have full permissions (Proposer, Voter, Executor). But for extra separation, give your primary key (daily wallet) Proposer and Voter permissions, and your secondary key (hardware wallet) Voter and Executor permissions. This ensures initiation and execution happen from different devices. If one person permanently loses access to both their keys, the remaining person holds only 2 keys and cannot meet the 3-of-4 threshold alone. Consider adding a trusted third party as a recovery key holder with Voter permissions only. This key can approve transactions but not initiate or execute them. The recovery key holder only steps in to help meet the threshold if one member becomes permanently unavailable. ## Member changes Team members leave, lose access to keys, or change roles. Plan for this before it happens. * Have a process for onboarding replacement members and removing departing ones * Periodically verify that all members still have access to their keys ## Organize with sub-accounts Every Squad starts with one default sub-account. Create additional sub-accounts to separate funds by purpose, such as isolating business lines, investor funds, or operational budgets. Each sub-account has its own Solana address and inherits the same members and approval threshold as the Squad. Common setups include: | Sub-account | Purpose | | - | - | | **Operations** | Payroll, vendor payments, daily expenses | | **Reserves** | Long-term holdings, stablecoins, runway | | **Grants** | Outbound funding, community programs | Sub-accounts within the same Squad are connected onchain. If you need fully isolated treasuries with no onchain connection between them, create separate Squads instead. See [Sub-accounts](/app-guide/treasury/sub-accounts) for setup instructions. ## Sending to the correct address Your Squad has two onchain addresses, visible on the **Settings** page. Always send funds to the **default sub-account** (labeled **Squads Vault** in Settings). This is the deposit address shown in your Squad's treasury. Never send funds or assign a program authority to the **Multisig account** address. The Multisig account stores your Squad's configuration and cannot hold or return assets. Funds sent to this address are not recoverable. Settings hides this address behind a security warning. Always verify you are using the **Squads Vault** address before every deposit. ## Spending limits If a team member needs to send funds on a recurring basis at amounts that don't require full threshold approval, set up a [spending limit](/app-guide/settings/spending-limits). Spending limits let specific members transfer up to a set amount per period without going through the full approval process. This is useful for payroll, vendor payments, or any routine transfer where requiring every member to approve each time slows things down. ## Fee Relayer By default, every member needs SOL in their personal wallet to create and approve transactions. The [Fee Relayer](/app-guide/members/fee-relayer) lets your Squad cover all transaction fees from the treasury, so members don't need to maintain a SOL balance. Fee Relayer and spending limits are available on the Pro plan. ## Security guardrails Squads includes built-in features to add layers of protection beyond threshold approvals. * [**Time locks**](/app-guide/settings/time-locks) add a mandatory delay between approval and execution, giving members time to review or reject a transaction before it takes effect. * [**Roles and permissions**](/app-guide/members/permissions) let you control what each member can do, so not everyone needs full access to every action. For teams managing high-value treasuries or onchain programs, see the [Advanced security guide](/security/best-practices) for additional practices. This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.