--- title: "Squads (Solana multisig & smart accounts)" url: "https://caper.network/wiki/dao-governance/tooling/treasury/squads" updated: 2026-08-26 license: CC-BY-4.0 license_url: "https://creativecommons.org/licenses/by/4.0/" --- # Squads (Solana multisig & smart accounts) | What it is | An open-source Solana program for multisig custody and account abstraction — the standard way Solana teams hold treasuries and control program upgrade authority. | | --- | --- | | Current program | Squads V4 (“Smart Account” standard). Solana mainnet-beta and Devnet: `SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf`; Eclipse mainnet: `eSQDSMLf3qxwHVHeTr9amVAGmZbRLY2rFdSURandt6f` ([Squads-Protocol/v4](https://github.com/Squads-Protocol/v4)) | | Upgrade authority | **None on Solana mainnet** — the program is immutable, frozen at the last deploy on 20 November 2024. Devnet and Eclipse are still upgradeable (read from chain, 26 August 2026) | | Category | Multisig / treasury custody / account abstraction | | Chain | Solana (also deployed on Eclipse SVM) | | License | AGPL-3.0 (some files Apache-2.0 / MIT) | | Audits | OtterSec, Neodyme, Certora, Trail of Bits ([audit reports in-repo](https://github.com/Squads-Protocol/v4)) | | Self-reported scale | 450+ teams, $15B+ in assets secured ([squads.xyz](https://squads.xyz/protocol)) | | Ethereum analog | [Safe](/wiki/dao-governance/tooling/treasury/safe) | **Squads** is the multisig and smart-account layer most Solana treasuries run on. Where Ethereum DAOs custody funds behind [Safe](/wiki/dao-governance/tooling/treasury/safe), Solana teams reach for Squads: an audited on-chain program that turns a single-key account into an _m-of-n_ account with roles, spending limits, and time locks. Squads Labs describes the protocol as "the autonomous finance layer built on Solana" ([squads.xyz](https://squads.xyz/protocol)), and the current [V4 program](https://github.com/Squads-Protocol/v4) is designed to "make it easier for developers to leverage multisig consensus and account abstraction on Solana." It solves the first thing every DAO has to get right — _who can move the money_ — without a custodian and without trusting a hosted dashboard. That makes it a piece of treasury infrastructure rather than a governance framework: Squads decides who signs, while systems like [SPL Governance / Realms](/wiki/dao-governance/tooling/frameworks/spl-governance) decide how token holders _vote_ on what those signers should do. ## From V3 to V4: multisig as a smart account Squads V4 reframes a multisig as a programmable **Smart Account** rather than a bare signer set. The on-chain program ([Squads-Protocol/v4](https://github.com/Squads-Protocol/v4)) ships: - **Roles & permissions** — members can be granted distinct rights (propose, vote, execute) instead of a flat "all signers are equal" model. - **Spending limits** — recurring caps that let day-to-day payments flow without a full multisig ceremony, while large moves still need the full threshold. - **Time locks** — an enforced delay between approval and execution, the same [execution-delay safety primitive](/wiki/dao-governance/concepts/voting/governance-timelocks) used across DAO governance to create a window to react before a transaction lands. - **Sub-accounts (vaults)** — multiple isolated vaults under one multisig, so a treasury, an ops float, and a grants budget can share governance without sharing a balance. The same program ID – `SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf` – serves Solana mainnet-beta and Devnet, and a separate build, `eSQDSMLf3qxwHVHeTr9amVAGmZbRLY2rFdSURandt6f`, is deployed to the [Eclipse](https://github.com/Squads-Protocol/v4#program-smart-contract-addresses) SVM rollup. It is licensed AGPL-3.0 and carries ten published audit reports from [OtterSec, Neodyme, Certora (with formal verification) and Trail of Bits](https://github.com/Squads-Protocol/v4/tree/main/audits); the repository names `64af7330413d5c85cbbccfd8c27a05d45b6e666f` as “the final and fully audited commit hash of the program.” ## Securing program upgrade authority A Solana program is deployed with a single **upgrade authority** — one key that can replace the program's code at will ([Solana docs: deploying programs](https://solana.com/docs/programs/deploying)). For a protocol holding user funds, that key _is_ the protocol: whoever controls it can ship a malicious upgrade in one transaction. Leaving it on a single hot key is the Solana equivalent of an unguarded proxy admin. The standard fix is to hand upgrade authority to a Squads multisig, so a code change requires _m-of-n_ approval (and, with a time lock, a public delay before it takes effect). This is why Squads shows up in the risk footprint of most serious Solana protocols — treasuries like [Jito](/wiki/daos/staking/jito) and [Marinade](/wiki/daos/staking/marinade) custody funds and privileged authorities behind multisig control rather than a lone signer. ## Who can upgrade Squads itself The section above is the case Squads makes for itself: never leave a privileged authority on one key. The obvious question is what Squads does with its own, and the answer is readable on chain. It is **not the same answer on every network it runs on**. On **Solana mainnet-beta** the program has **no upgrade authority at all**. Its `ProgramData` account, `Fy3YMJCvwbAXUgUM5b91ucUVA3jYzwWLHL3MwBqKsh8n`, carries the upgradeable loader's `Option` flag set to zero, which is what the loader writes when an authority is deliberately dropped ([Solana docs: deploying programs](https://solana.com/docs/programs/deploying)). Nobody – not Squads Labs, not a multisig, not a council – can replace the code that custodies those treasuries. The header also records when it was frozen: last deployed at slot **302,582,236**, **20 November 2024, 18:36:48 UTC**, one day after the commit the repository names as its final audited build. The deployed program has not changed in the twenty-one months since. The other two deployments are not frozen. **Devnet**, which shares the mainnet program ID, was last redeployed on **6 March 2026** and still names an upgrade authority – expected for a test network, and a reminder that a program ID alone tells you nothing about mutability. **Eclipse mainnet** is the one that matters: `eSQDSMLf3qxwHVHeTr9amVAGmZbRLY2rFdSURandt6f` retains an upgrade authority at `E6PSaQPXCCr2Tu27z1wZmKhAHWGcSNiegoWByX17iGab`. That address is off the ed25519 curve, so it is a program-derived address with no private key behind it rather than a loose wallet; which program derives it cannot be settled from Eclipse's public RPC, whose history no longer reaches the deploy. A DAO custodying on Eclipse is therefore taking a materially different assurance from one custodying on Solana, and Squads' own documentation lists all three deployments side by side without distinguishing them. Immutability is a strong guarantee and a hard constraint at once. A frozen program cannot be rug-pulled by an upgrade, and it also cannot be patched: a bug is fixed by publishing a new program ID and asking every treasury to migrate to it – which is exactly the V3-to-V4 move described above, not a hypothetical. It is the opposite design choice to [SPL Governance](/wiki/dao-governance/tooling/frameworks/spl-governance), whose kernel stays upgradeable and routes its own upgrades through a seven-seat Realms council; both are defensible, and the difference is the thing a Solana DAO is choosing between when it picks a custody layer. Worth reading alongside the code: the company around it has moved. [squads.xyz](https://squads.xyz) now fronts four products – Altitude, Fuse, Grid and Multisig – under the line “Squads Labs is a financial technology company, not a bank or a digital asset custodian,” and the protocol page is titled [“The Autonomous Finance Layer for Stablecoin Banking.”](https://squads.xyz/protocol) The DAO multisig is one line of business among several. Because the mainnet program is immutable, that shift cannot reach the deployed code – a case where freezing the contract also froze the product away from its vendor's roadmap. ## Where it sits in the DAO stack Squads is _custody_, not _governance_. It answers "which keys must sign," which is necessary but not sufficient for a DAO: - It pairs with [SPL Governance / Realms](/wiki/dao-governance/tooling/frameworks/spl-governance), which supplies token-weighted voting on top — the vote decides _what_ to do, the multisig _executes_ it. - It is the Solana counterpart to [Safe](/wiki/dao-governance/tooling/treasury/safe) on Ethereum; much of the tooling ecosystem (payments, streaming, analytics) plugs into one or the other. - For small DAOs and working groups it is often the _whole_ governance stack — a signer set with roles and limits, no token vote at all, which keeps things simple but concentrates trust in the signers. See the [DAO tooling stack overview](/wiki/dao-governance/tooling/dao-tooling-overview) for how custody, voting, membership, and analytics layers fit together. ## Limits and considerations A multisig is a custody control, not a legitimacy mechanism. A 3-of-5 Squads account is exactly as decentralized as its five signers — if they are one team's laptops, the "DAO" is a company with extra steps. Multisig custody says nothing about whether the broader membership consented to a spend, only that the threshold of signers did. It also inherits the classic multisig failure modes: lost or compromised keys, signer collusion at the threshold, and the coordination cost of getting _m_ humans to sign in time during an incident. Spending limits and time locks soften the day-to-day friction and the blast radius, but the trust still rests on _who holds the keys_ — a question multisig custody organizes rather than dissolves. That gap is exactly where on-chain governance and [exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights) pick up. ## How Caper approaches this Squads answers "who can move the treasury." [Caper](/wiki/foundations/what-is-a-caper) is built around the harder question underneath it: _can a holder who disagrees leave with their share of the treasury_, without asking a signer set for permission? In a caper the treasury and each holder's claim on it are enforced by the protocol contract, so redeeming your share is a right you exercise on-chain — not a payment a multisig has to choose to send you ([rage-quit and exit rights](/wiki/dao-governance/concepts/membership/rage-quit-and-exit-rights)). The two are complementary, not competing: a Solana team might still hold operating funds in a Squads multisig, but Caper's design assumes the strongest guarantee for members is one custody arrangements can't offer on their own — a contract-enforced exit, so control never comes down to trusting whoever holds the keys. ## References The upgrade-authority, deploy-slot and program-address figures on this page were read directly from Solana mainnet-beta, Solana Devnet and Eclipse mainnet on 26 August 2026 via `getAccountInfo`, `getBlockTime` and `getSignaturesForAddress` against the public RPCs, decoding the upgradeable loader's `ProgramData` header, and the deploy date was cross-checked against the audited commit's date in the repository. - [Squads](https://squads.xyz) — official site - [Squads Protocol](https://squads.xyz/protocol) — protocol overview and adoption figures - [Squads-Protocol/v4](https://github.com/Squads-Protocol/v4) — the V4 program source, features, deployments, license, and audit reports - [Squads documentation](https://docs.squads.so) - [Solana docs — deploying programs](https://solana.com/docs/programs/deploying) (program upgrade authority)