---
title: "Security councils and emergency powers"
url: "https://caper.network/wiki/dao-governance/concepts/fundamentals/security-councils"
updated: 2026-08-26
license: CC-BY-4.0
license_url: "https://creativecommons.org/licenses/by/4.0/"
---

# Security councils and emergency powers

|  |  |
| --- | --- |
| **Concept** | A security council is a small, elected multisig of named signers that a DAO empowers to act on the protocol quickly when normal token voting would be too slow – upgrading or pausing contracts to contain an active exploit |
| **Also called** | Guardian multisig, emergency multisig, "training wheels" (the term [L2BEAT](https://l2beat.com/stages) uses for a council that a rollup has not yet outgrown) |
| **Canonical design** | The [Arbitrum DAO Security Council](https://docs.arbitrum.foundation/concepts/security-council): 12 members, DAO-elected, acting through a 9-of-12 [multisig](https://docs.arbitrum.foundation/state-of-progressive-decentralization) |
| **Core tension** | The same fast path that lets nine people stop a hack also lets nine people move funds or push an upgrade over holders. A security council is a trust assumption, not the removal of one |
| **Related** | [Progressive decentralization](/wiki/dao-governance/concepts/fundamentals/progressive-decentralization) · [Governance timelocks](/wiki/dao-governance/concepts/voting/governance-timelocks) · [DAO security & governance attacks](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks) |
| **Two shapes** | **Positive** – a council that can execute an upgrade or pause (the [Arbitrum](https://docs.arbitrum.foundation/concepts/security-council) template) · **negative** – a council whose only power is to cancel a proposal already in the timelock (the [ENS](https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145) template) |

## 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](/wiki/dao-governance/concepts/voting/governance-timelocks) 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](/wiki/dao-governance/concepts/voting/token-weighted-voting) 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](/wiki/dao-governance/concepts/fundamentals/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](https://l2beat.com/stages) formalised exactly this trajectory for rollups in its [Stages framework](https://medium.com/l2beat/introducing-stages-a-framework-to-evaluate-rollups-maturity-d290bb22befe), 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](/wiki/dao-governance/concepts/analysis/council-dissolution).

## How a council is designed: the Arbitrum template

The [Arbitrum DAO Security Council](https://docs.arbitrum.foundation/concepts/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](https://docs.arbitrum.foundation/state-of-progressive-decentralization). 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](/wiki/dao-governance/concepts/voting/governance-timelocks) 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](https://thedefiant.io/news/security/arbitrum-security-council-elections)). 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](/wiki/dao-governance/concepts/analysis/dao-security-and-governance-attacks), which is why the design emphasis is always on _shrinking_ what the council can do rather than trusting it more.

## The other shape: cancel-only councils

Not every council can act. The [ENS DAO Security Council](https://docs.ens.domains/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](https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145)). 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](https://etherscan.io/address/0xFe89cc7aBB2C4183683ab71653C4cdc9B02D44b7) – 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](https://etherscan.io/address/0xb8fa0ce3f91f41c5292d07475b445c35ddf63ee0) 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.

## The 2026 ENS renewal, and what the abstain block was hiding

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.

- **The renewal was proposed as routine.** [EP 6.45](https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145) kept the 4-of-8 multisig and the cancel-only mandate unchanged, rotating a single inactive signer out, and deployed a fresh contract adding an `extend()` function so future renewals would be one vote rather than a redeployment. The contract was audited by [Nethermind (NM-0945, zero findings)](https://github.com/blockful/security-council-ens/tree/main/audits) and deployed before the vote.
- **The argument was not about security.** It was about whether a cancel-only council may block a proposal it merely disagrees with. A council member had said publicly he would veto a live ENS Foundation proposal if it passed without wide non-Labs delegate support. [nick.eth argued](https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145/5) that the mandate is the specific trigger conditions ratified in EP 5.7 – constitutional breach, exploit, capture by financially adverse actors – and that “disagreement with a policy choice is not on that list”. [MicahZoltu answered](https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145/8) that the DAO's own documentation frames those triggers as judgement calls, and that protecting against a wrong majority is the entire point of the body. [bcvfinance.eth](https://discuss.ens.domains/t/6-45-renewal-of-the-security-council/22145/10) pushed a third line: the test should be actor-neutral, because insider capture is harder to challenge than the outside kind, not easier.
- **The advisory vote read as consent.** The [Snapshot social vote](https://snapshot.box/#/s:ens.eth/proposal/0x9ed89cf79760eb92d220fee2da08896bf027317f394aab87863011f964e19453) (23–28 June 2026, 73 voters) closed 1,274,195 ENS _For_ to 85,204 _Against_ – a fifteen-to-one margin. It also carried 3,386,139 ENS _Abstain_, 71% of everything cast and larger than For and Against combined – and 3,261,042 of that came from one address, ENS lead developer [nick.eth](https://api.ensdata.net/0xb8c2C29ee19D8307cb7255e1Cd9CbDE883A267d5). The abstain column was not a diffuse shrug; it was the largest voter declining to answer the question in the instrument that was asking it.
- **The binding vote inverted it.** The on-chain executable that would have granted `PROPOSER_ROLE` to the renewed contract was [defeated](https://www.tally.xyz/gov/ens/proposal/45402179622316441394139979097514597399865468312011562941203078514615705423505): 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.
- **The DAO re-founded the council instead of renewing it.** A [new framework](https://discuss.ens.domains/t/draft-social-proposal-for-a-new-security-council/22219) added a written charter, a binding appointment agreement with the ENS Foundation, an explicit removal mechanism for members who act outside the mandate, and a 5-of-8 threshold in place of 4-of-8 – with the scope of authority deliberately unchanged: “cancellation of timelocked proposals, nothing more”. Eight members were elected from an open nomination round in a [Copeland-method vote](https://snapshot.box/#/s:ens.eth/proposal/0x3e7acd4a47b246382bf9a3aeb71d0fd1562d38dbb9f7b7760445cf9731229b9d) (7–12 July 2026, 50 voters, 15 candidates), and the [executable grant](https://discuss.ens.domains/t/executable-establishing-a-new-security-council/22272) passed with 4,228,716 ENS for to 94,526 against.

Read from the deployed contracts on 8 August 2026 (Ethereum block 25,710,457): the [new council contract](https://etherscan.io/address/0x2acBf518b3759f6e1fA163294eda55bF1d0ae051) holds `PROPOSER_ROLE` on the ENS timelock; its owner [Safe](https://etherscan.io/address/0x7101B78638e34444F0a5AdE9e1149fbEeC029931) 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.

## Cancellation as a library primitive – and who should hold it

Since April 2025 the cancel power has been a standard part of the industry's most-used governance library. [GovernorProposalGuardian](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/governance/extensions/GovernorProposalGuardian.sol) shipped in [OpenZeppelin Contracts v5.3.0](https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/CHANGELOG.md) ([PR #5303](https://github.com/OpenZeppelin/openzeppelin-contracts/pull/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](/wiki/dao-governance/tooling/voting/openzeppelin-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](https://forum.arbitrum.foundation/t/change-to-new-governance-contracts-that-allow-proposal-cancellation/27531) 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:

- [karpatkey asked](https://forum.arbitrum.foundation/t/change-to-new-governance-contracts-that-allow-proposal-cancellation/27531/40) whether an emergency moderator such as the Arbitrum Foundation should also be able to cancel a malicious proposal before it becomes votable – the argument for widening the guardian.
- [dzack23 pointed out](https://forum.arbitrum.foundation/t/change-to-new-governance-contracts-that-allow-proposal-cancellation/27531/50) that the Security Council could already cancel proposals via a proxy upgrade of the governance contract, so the upgrade does not grant a new power – it makes an existing one technically simpler and easier to audit after the fact. A power that already exists informally is better made explicit and traceable.
- [Narik raised](https://forum.arbitrum.foundation/t/change-to-new-governance-contracts-that-allow-proposal-cancellation/27531/52) whether formalising a standing body's authority to halt governance outcomes bears on decentralisation assessments under the EU's MiCA framework, where “identifiable managerial control” is a live test. Writing the veto down makes it legible to regulators as well as to delegates.

The upgrade was bundled into a constitutional AIP and [executed](https://www.tally.xyz/gov/arbitrum/proposal/112177996398925212273579485756315626637025938627124330171390356044681347897430) 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 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](https://medium.com/l2beat/stages-update-security-council-requirements-4c79cea8ef52). 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](https://forum.l2beat.com/t/stage-1-requirements-update-security-council-walkaway-test/412)): 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](/wiki/dao-governance/concepts/fundamentals/governance-minimization) applied to the emergency path itself.

## How Caper approaches this

A [caper](/wiki/foundations/what-is-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](/wiki/governance/proposals) and [execution](/wiki/governance/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: every state-mutating entry point on a caper's state component is declared `restrict_to: [admin]`, with the admin badge held by the immortal registry, and 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`, initialised to zero and rewritten only by `set_upgrade_delay`, which is itself `restrict_to: [admin]`. So the swap routes through a $CAPER [proposal](/wiki/governance/proposals), but the length of the window guarding it is not governed at all.

On the live deployment that field reads zero. The [registry component](https://stokenet-dashboard.radixdlt.com/component/component_tdx_2_1crd7wmgsa465q4ceqnlcwh9pc8pmsxhdthat86379axx74cse5ml4d) carries `upgrade_delay_seconds: 0` – 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](https://stokenet-dashboard.radixdlt.com/transaction/txid_tdx_2_1gyn66jhux2qcx7qgrfyt4e7m0pkq8yhymauqn6sgh3ghuk7culasxshjz3) 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 the field is one admin call away from being non-zero, but a team weighing this design against a council-plus-timelock should weigh the configured value rather than the mechanism.

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.