Squads is the multisig and smart-account layer most Solana treasuries run on. Where Ethereum DAOs custody funds behind 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), and the current V4 program 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 decide how token holders vote on what those signers should do.
Squads V4 reframes a multisig as a programmable Smart Account rather than a bare signer set. The on-chain program (Squads-Protocol/v4) ships:
The same program ID – SQDS4ep65T869zMMBKyuUq6aD6EgTu8psMjkvj52pCf – serves Solana mainnet-beta and Devnet, and a separate build, eSQDSMLf3qxwHVHeTr9amVAGmZbRLY2rFdSURandt6f, is deployed to the Eclipse 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; the repository names 64af7330413d5c85cbbccfd8c27a05d45b6e666f as “the final and fully audited commit hash of the program.”
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). 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 and Marinade custody funds and privileged authorities behind multisig control rather than a lone signer.
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<Pubkey> flag set to zero, which is what the loader writes when an authority is deliberately dropped (Solana docs: deploying programs). 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. Re-read from mainnet-beta on 12 September 2026, the header still names that same slot and still carries the same zero authority flag, so the deployed code is unchanged since that 2024 deploy.
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 – the README's address list gives mainnet, Devnet and Eclipse as three consecutive lines and says nothing about mutability on any of them (re-read 12 September 2026).
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, 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 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.” The numbers it leads with are payment numbers rather than custody ones: over 450 teams, more than $15 billion secured and more than $5 billion in stablecoin transfers processed (read 12 September 2026). 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.
Squads is custody, not governance. It answers "which keys must sign," which is necessary but not sufficient for a DAO:
See the DAO tooling stack overview for how custody, voting, membership, and analytics layers fit together.
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 pick up.
Squads answers "who can move the treasury." 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).
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.
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.