What a security council is

Token voting is deliberately slow. A proposal is drafted, debated, put to a vote for several days, and then held in a timelock before it executes. That latency is a feature for routine decisions and a liability during an active exploit, when an attacker is draining a contract in minutes. A security council is the standard answer: a small set of named, elected signers who hold a multisig with the authority to upgrade or pause the protocol's contracts on a compressed timeline, so that a live incident can be contained before a week-long vote could ever conclude.

The council is not a separate legal body or a foundation board; it is a set of on-chain keys with scoped powers, granted by the DAO and answerable to it. It sits alongside token governance rather than replacing it – the DAO still owns the protocol, and in a mature design the council's remit is narrow and shrinking. Understanding where that line sits is the whole subject of this page.

Why they exist: the incident-response gap

Every credibly decentralized protocol faces the same dilemma. If upgrades require a full token vote plus a timelock, the protocol cannot respond to a zero-day fast enough to save user funds. If upgrades can be pushed instantly by a small group, that group is a single point of failure – a compromised or coerced signer set can rewrite the protocol at will. The security council is the industry's compromise: keep the fast path, but put it behind a threshold of independent, publicly-known, DAO-elected signers rather than an anonymous developer key.

This is why councils are inseparable from progressive decentralization. A protocol launches with heavy privileged control, and over time it narrows what the council can do and lengthens the delay on anything the council touches. L2BEAT formalised exactly this trajectory for rollups in its Stages framework, where the presence and power of a security council is one of the primary axes that separates an immature system from a trust-minimised one.

How a council is designed: the Arbitrum template

The Arbitrum DAO Security Council is the most-copied reference design, and its parameters show what the levers are:

• Threshold. Twelve members act through a 9-of-12 multisig. A supermajority signing requirement is the point – no minority of signers, and no single compromised key, can move the protocol.
• Two speeds. The council has an emergency path that can execute immediately to stop a live threat, and a non-emergency path for routine maintenance that runs through the normal timelock so token holders can see and react to it. Keeping most actions on the slow path is what stops "emergency" powers from becoming ordinary powers.
• Elected, rotating seats. Members are elected by the DAO, with the twelve seats split into two cohorts of six that face election every six months, so half the council turns over on a rolling basis. Candidates must clear a support threshold (0.2% of votable tokens), and no single organisation may hold more than three seats – a deliberate check on capture.
• Removability. The DAO can remove a member either through a high-participation token vote or by a vote of the council itself, so a signer who goes rogue or dark is not permanent.

Other large protocols run the same pattern under different names – Optimism's Superchain and most Ethereum rollups maintain an equivalent guardian or security-council multisig – but Arbitrum's published specification is the clearest primary source for how the knobs are set.

Emergency powers in practice – and their risk

The power is real and it gets used. Arbitrum's council has acted on live incidents, and in 2026 the DAO's security apparatus was central to a high-profile dispute over roughly $71M of ETH linked to the Kelp exploit – a case that put the question of who may move frozen funds, and on whose authority squarely in front of token holders (The Defiant). That is the double edge in one example: the machinery that can freeze stolen funds is also machinery that decides where they go next.

A security council is therefore best read as an explicit, bounded trust assumption rather than a safety feature with no downside. The failure modes are well understood: signer collusion, key compromise, legal coercion of named individuals, or simple scope creep where "emergency" upgrades quietly become the normal way things ship. Every one of these is a governance attack surface, which is why the design emphasis is always on shrinking what the council can do rather than trusting it more.

The walkaway test and Stage 2: designing the council out

The clearest articulation of "how much power is too much" comes from L2BEAT's security-council requirements. A properly constituted council must have at least eight members and a signing threshold above 75%, so that it is genuinely a distributed body rather than a rubber stamp. But the real bar is the walkaway test (L2BEAT forum): users must be able to exit the system even if the entire council disappears. If your safety depends on the council showing up, you have not decentralised – you have outsourced trust to twelve people.

From there the ladder is explicit. Stage 1 tolerates a council with meaningful emergency reach, provided users retain an independent exit and any permissioned upgrade carries a multi-day delay. Stage 2 – the end state – permits a council to intervene only for provable, on-chain bugs, with a 30-day exit window on everything else. The destination of a well-designed council is a narrower and narrower mandate, approaching the point where it can no longer act against users at all. This is governance minimisation applied to the emergency path itself.

How Caper approaches this

A caper has no security council, no guardian, and no emergency multisig with a fast path over its balances. Verified against the on-ledger contract, a caper's state component holds no business logic and exposes no pause, freeze, or emergency-override method; its state-changing entry points are gated to a single admin authority held by the immortal registry and exercised only through the caper's own proposal and execution rules. There is no standing set of human signers who can step outside those rules to move member funds or fast-track a change.

That is a different trade-off, not a claim of superiority: a caper leans on a fixed, minimal core and rule-bound execution rather than a trusted council standing by for incidents. It is closer to the Stage-2 end of the ladder by construction – the price is that there is no nine-of-twelve to phone if something goes wrong, so correctness has to live in the rules and the immutable core, not in an emergency backstop. For teams weighing the two, the honest question is the one this whole page turns on: whether you would rather trust a small group to act fast, or design so that no small group needs to.