References The upgrade-author…s.squads.so) - Solana docs —– deploying programs (https://s…) (program upgrade authority)

What it is An open-source Sola…stody and account abstraction —– the standard way Solana teams…hority None on Solana mainnet —– the program is immutable, fro…ernance/tooling/treasury/safe)

Squads is the multisig and sma…ng every DAO has to get right —– who can move the money —– without a custodian and witho… what those signers should do.

From V3 to V4: multisig as a s…ships: - Roles & permissions —– members can be granted distin…al" model. - Spending limits —– recurring caps that let day-t…full threshold. - Time locks —– an enforced delay between app…nds. - Sub-accounts (vaults) —– multiple isolated vaults unde…d commit hash of the program.”

Securing program upgrade autho…th a single upgrade authority —– one key that can replace the …most serious Solana protocols —– treasuries like Jito (/wiki/…rol rather than a lone signer.

Where it sits in the DAO stack… token-weighted voting on top —– the vote decides what to do, …en the whole governance stack —– a signer set with roles and l…analytics layers fit together.

Limits and considerations A m…ntralized as its five signers —– if they are one team's laptop…l rests on who holds the keys —– a question multisig custody o…uit-and-exit-rights) pick up.

How Caper approaches this Squ…a right you exercise on-chain —– not a payment a multisig has …ents can't offer on their own —– a contract-enforced exit, so …usting whoever holds the keys.

References The upgrade-author… Squads (https://squads.xyz) —– official site - Squads Prot…https://squads.xyz/protocol) —– protocol overview and adoptio…thub.com/Squads-Protocol/v4) —– the V4 program source, featur…) (program upgrade authority)

Who can upgrade Squads itself …7z1wZmKhAHWGcSNiegoWByX17iGab.That address is off the ed2551…way from its vendor's roadmap.

What it is An open-source Sola…teams, $15B+ in assets secured, $5B+ in stablecoin transfers processed ( squads.xyz (https://squads.xyz/protocol) , read 12 September 2026) Ethereum analog Safe (/wik…ernance/tooling/treasury/safe)

Who can upgrade Squads itself …s as its final audited build. The deployed program has not changed in the twenty-one months sinceRe-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 a…de without distinguishing them – the README's address list (https://github.com/Squads-Protocol/v4#program-smart-contract-addresses) 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 gu…(https://squads.xyz/protocol) 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 …way from its vendor's roadmap.

What it is An open-source Sola…. Current program Squads V4 ("“Smart Account"” standard), deployed to. Solana mainnet-beta, and Devnet, and Eclipse ( Squads-Protocol/v4 (https://github.com/Squads-Protocol/v4) : 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 / treasur…ernance/tooling/treasury/safe)

From V3 to V4: multisig as a s…thout sharing a balance. The V4same program is deployed to Solana mainnet-beta and Devnet, and to the Eclipse (https://github.com/Squads-Protocol/v4) SVM rollup, under AGPL-3.0 and audited by OtterSec, Neodyme, Certora, and Trail of Bits.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 autho…suries like Jito (/wiki/daos/organizations/staking/jito) and Marinade (/wiki/daos/organizations/staking/marinade) custody fun…rol rather than a lone signer.

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)…) (program upgrade authority)

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

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), deployed to Solana mainnet-beta, Devnet, and Eclipse ( Squads-Protocol/v4 (https://github.com/Squads-Protocol/v4) ) 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 V4 program is deployed to Solana mainnet-beta and Devnet, and to the Eclipse (https://github.com/Squads-Protocol/v4) 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 (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/organizations/staking/jito) and Marinade (/wiki/daos/organizations/staking/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 (/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 - 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)