Squads (Solana multisig & smart accounts)

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 V4 program is deployed to Solana mainnet-beta and Devnet, and to the Eclipse SVM rollup, under AGPL-3.0 and audited by OtterSec, Neodyme, Certora, and Trail of Bits.

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.

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

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)

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.