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.
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.
That narrowness is also what makes a security council survivable when other bodies are not. When Optimism wound down three elected councils in June 2026, it drew the line explicitly: the overhead of an elected body is worth paying only where an independent group “meaningfully increases decentralization where it matters most (ie. the Security Council.)” See council dissolution and governance unwinding.
The Arbitrum DAO Security Council is the most-copied reference design, and its parameters show what the levers are:
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.
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.
Not every council can act. The ENS DAO Security Council is the reference design for the opposite arrangement: a multisig whose only power is to cancel a proposal that has already passed and is sitting in the DAO's timelock. In the DAO's own words it “cannot propose, amend, or initiate any governance action” (EP 6.45). Where Arbitrum's council is a fast path to do something, ENS's is a brake on something the DAO has already decided.
The implementation is a detail worth knowing, because it is where the power actually lives. The council holds PROPOSER_ROLE on the DAO's TimelockController – on the OpenZeppelin timelock version ENS deployed, that is the role gating cancel. Granting the role is a single governance transaction, and it is the same lever that seats a council, replaces one, or ends one. Nothing about the arrangement requires a new contract system; a cancel-only council is a role grant.
ENS also bounded it in time. The council contract deployed in 2024 carries an expiry: two years plus a seven-day buffer after deployment, after which anyone may call renounceTimelockRoleByExpiration() to permanently disable the cancel power. That date was 24 July 2026. An expiring veto is the design choice this whole page has been circling – it makes the council re-argue its mandate on a schedule instead of accumulating one by default.
Taiko, an Ethereum rollup, launched its DAO with Aragon in January 2025 and reversed the ENS arrangement. Its Security Council of eight, drawn from inside and outside Taiko Labs, is where proposals start, and token holders hold the brake (Taiko Labs; Aragon). A standard proposal needs 3 of the 8 council members, then enters a community review period in which holders and their delegates can veto it; if the veto threshold is not reached, it executes after a seven-day timelock, which gives anyone who objects time to exit. An emergency proposal needs 6 of the 8, has no veto period, and is submitted encrypted, so the fix for a live vulnerability is not public before it is deployed; its contents are decrypted on execution.
Three of eight is a much lower bar than Arbitrum's 9 of 12, so the protection on Taiko's normal path rests on the veto and its threshold. It is the optimistic governance pattern with a council as the proposer. The vendor that built it now also sits on councils: Aragon said in January 2026 that it holds seats on Spark's and Taiko's security councils as part of a security service it sells (Aragon).
The expiry did its job in the most instructive way possible: the renewal failed. The sequence is worth reading in full, because it is the only fully-public record of a DAO re-litigating a standing veto with the clock running.
extend() function so future renewals would be one vote rather than a redeployment. The contract was audited by Nethermind (NM-0945, zero findings) and deployed before the vote.PROPOSER_ROLE to the renewed contract was defeated: 3,859,981 ENS against, 1,137,702 for, 1,761 abstaining. Read the two tallies together and the abstain block was not indifference. It was opposition that the advisory instrument had no way to record.Read from the deployed contracts on 8 August 2026 (Ethereum block 25,710,457): the new council contract holds PROPOSER_ROLE on the ENS timelock; its owner Safe returns a threshold of 5 over 8 owners; and neither the expired 2024 contract nor the one deployed for the defeated renewal holds the role. The term runs to 16 July 2028, at which point the same expiry logic fires again.
Two things generalise. First, an expiry is an accountability mechanism, not a technicality – nothing else would have forced ENS to state, in writing and under a deadline, what its council may and may not do. Second, an off-chain temperature check and a binding vote can point in opposite directions, and the abstain column is where the difference hides. A DAO reading only the social vote here would have concluded its delegates were comfortable.
Since April 2025 the cancel power has been a standard part of the industry's most-used governance library. GovernorProposalGuardian shipped in OpenZeppelin Contracts v5.3.0 (PR #5303) and defines “a proposal guardian who can cancel proposals at any stage in their lifecycle”. Its _validateCancel override is exactly that broad: the guardian can cancel any proposal at any point, and where no guardian is configured the power falls back to each proposal's own proposer. Adding one line of inheritance to a Governor gives a DAO an unbounded veto by default – unbounded in time, in scope, and in the stage at which it may be used.
Arbitrum, which had the same choice in front of it, deliberately took the narrowest version. Its proposal-cancellation upgrade ran for fifteen months of public design argument, and the shipped rule is that a proposal can be cancelled only by its author and only during the pending period before voting opens, both enforced at contract level. The debate around that narrowing is the useful part:
The upgrade was bundled into a constitutional AIP and executed with 247,894,294 ARB in favour against 362,597. Set the three designs side by side and the spread is the whole lesson: the library's default guardian can cancel anything at any time, ENS's council can cancel only what is already in the timelock and only until its term expires, and Arbitrum's cancel is reserved for the author of the proposal before anyone has voted. Same primitive, three very different trust assumptions.
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.
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.
Verified against the contract source rather than any description of it: a caper's state component restricts every state-mutating method to admin, a badge the immortal registry holds, with three exceptions. buy_apply and sell_apply, which settle a trade, are public but refuse every caller except the logic component the registry currently names as live; donate_collateral, which funds a curve whose reserve is empty, is open to anyone. There is no pause, freeze, or emergency-override method to hold in reserve. The one privileged lever at platform level is the upgrade path for the swappable logic component – propose, wait out a delay, then activate. The registry's own source comment calls that delay the thing that makes a hostile swap visible on-ledger for the whole window, and it is worth reading its length rather than its description.
The delay is a stored field, upgrade_delay_seconds, and until 11 September 2026 an admin-only set_upgrade_delay could rewrite it at any moment. That made the timelock a constraint on $CAPER governance and never on the operator, since the same key that armed a delay could set it back to zero, re-propose and activate inside one transaction – which is exactly what the protocol’s own pen-test demonstrated. The setter is gone.
The delay is now an argument of CaperRegistry::new, fixed at construction and immortal like the registry itself, and the field’s source comment states the reason in a line: a delay the operator key could shorten would only ever constrain governance. The deploy script arms 48 hours when the target is mainnet and zero on every other network. So the swap routes through a $CAPER proposal, while the length of the window guarding it is settled once at deployment – neither governed nor, any longer, adjustable.
On the live Stokenet deployment that field reads zero, which is what the deploy script passes off mainnet. The registry component published by the 11 October 2026 redeploy carries upgrade_delay_seconds: 0, read from its on-ledger state the same day, as did the registry of every deployment before it, and the one governed upgrade the platform has performed, on the deployment then live, shows what that means in practice: the 16 August 2026 swap called execute_proposal_upgrade and execute_proposal_upgrade_activate back to back in a single manifest, the MainProposed event it emitted carries a not_before of 1786872474 – the same second the transaction committed – and MainActivated fires immediately after it in the same transaction.
The timelock's own audit trail therefore records a window zero seconds wide. Nothing here is broken, and a mainnet deployment would arm 48 hours rather than this testnet’s zero, but a team weighing this design against a council-plus-timelock should weigh the configured value rather than the mechanism – and should note that the value is no longer one admin call away from anything. With the setter removed, changing it means constructing a new registry, which is to say a new platform.
One thing a caper does not have, corrected here against the same source: there is no per-caper opt-out from a logic swap. A caper's state component carries no logic pointer of its own – current_main lives once on the registry and every caper resolves through it – so an individual caper cannot be held on incumbent logic while an upgrade lands. The forward-compatibility store on a caper's state component (aux, empty at genesis, its writers gated to the admin badge) is a generic blob store, and the only key logic writes to it today holds that caper's ballot-vault address; it is not a veto. What a caper has is not a negative power over the platform tier, but the absence of anyone holding a positive one over its balances.