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.

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) 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 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 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.”

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). 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.

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<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. 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, 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 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, which supplies token-weighted voting on top — the vote decides what to do, the multisig executes it.
• It is the Solana counterpart to 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 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 pick up.

How Caper approaches this

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.

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 — official site
• Squads Protocol — protocol overview and adoption figures
• Squads-Protocol/v4 — the V4 program source, features, deployments, license, and audit reports
• Squads documentation
• Solana docs — deploying programs (program upgrade authority)