CircuitBreaker — Programmable panic layer

Proposals
1

TL;DR

  • It is proposed to replace GateSeals with CircuitBreaker, a permanent emergency pause contract. Unlike GateSeals, CircuitBreaker does not expire, does not require redeployment, and allows committees to extend their own authority via periodic heartbeats without a DAO vote.

  • The full design is specified in LIP-34. Source code: github.com/lidofinance/circuit-breaker.

Context

GateSeals were designed as temporary, disposable emergency brakes. Each was deployed with a fixed committee, pause duration, set of pausable contracts, and an expiry of up to one year. Once triggered, the GateSeal expired immediately. If never triggered, it expired naturally. Either way, a new one had to be deployed, verified, voted on via Snapshot, and enacted via an on-chain vote that revokes the pause role from the old instance and grants it to the new one (recent renewal). This recurring burden was intentional, an “inconvenience bomb” to push the DAO toward a permanent solution.

After three years without a single trigger, the tradeoff proved acceptable: a committee that can pause specific contracts once, for a limited duration, is worth having over no fast-response option at all. But the redeployment overhead remains, and with Lido V3, Triggerable Withdrawals, and Dual Governance increasing the number of pausable contracts, it is compounding. CircuitBreaker is proposed as the permanent replacement.

CircuitBreaker

CircuitBreaker is a single, permanent contract that manages all emergency pausing for the protocol. Like an electrical circuit breaker, it trips under fault conditions, protects the system, and is reset by an authorized party. It doesn’t self-destruct after tripping.

A circuit breaker is an electrical safety device designed to protect an electrical circuit from damage caused by current in excess of that which the equipment can safely carry (overcurrent). Its basic function is to interrupt current flow to protect equipment and to prevent fire. Unlike a fuse, which interrupts once and then must be replaced, a circuit breaker can be reset (either manually or automatically) to resume normal operation.

In this analogy, a GateSeal works much like a fuse and CircuitBreaker is, well, a circuit breaker for multiple circuits.

How it works

A single CircuitBreaker is deployed with the DAO Agent as admin, immutable bounds for pause duration and heartbeat interval, and initial values for both. The DAO registers pausable contracts by pairing each one with a committee.

  • Permanent address. The DAO grants the pause role on each pausable contract to the CircuitBreaker address once. Since the address never changes, this grant survives all pause cycles.

  • Single-use pause. In an emergency, the committee triggers a pause on a specific contract. CircuitBreaker verifies the caller, pauses the target, and clears the committee’s authority on that contract. The committee can still pause other contracts assigned to it. DAO can reassign the pauser again.

  • Liveness heartbeat. Committees must periodically send a heartbeat (a drill transaction) to prove they are operational. A committee whose heartbeat has expired cannot pause or refresh; the DAO must replace it with another live committee. Only one heartbeat is required to prove liveness regardless of the number of contracts assigned to the pauser.

See LIP-34 for the full design.

Proposed Pausable Contracts

It is proposed that CircuitBreaker replaces the following GateSeals as emergency pause mechanism for the pausable contracts:

GateSeal 0x8A854C4E750CDf24f138f34A9061b2f556066912:

GateSeal 0xA6BC802fAa064414AA62117B4a53D27fFfF741F1:

GateSeal 0x881dAd714679A6FeaA636446A0499101375A365c:

CS GateSeal 0xE1686C2E90eb41a48356c1cC7FaA17629af3ADB3:

And any new pausable contracts introduced with later upgrades.

Proposed Committees

It is proposed that the existing GateSeal committees remain as pausers for their respective pausable contracts in the CircuitBreaker. It is also proposed to rename the GateSeal committee to CircuitBreaker committee.

Proposed Parameters for Mainnet

Parameter Proposed value Notes
ADMIN Lido DAO Agent Immutable
MIN_PAUSE_DURATION 5 days Immutable lower bound
MAX_PAUSE_DURATION 60 days Immutable upper bound
MIN_HEARTBEAT_INTERVAL 30 days Immutable lower bound
MAX_HEARTBEAT_INTERVAL 3 years Immutable upper bound
pauseDuration 21 days Initial value, tunable by admin
heartbeatInterval 365 days Initial value, tunable by admin

Pause duration rationale: 21 days. An Aragon vote right now takes 5 days. If it fails to reach quorum, a second vote is needed which is another 5 days. The minimum Dual Governance timelock is 4 days. All that totals to 14 days. The remaining 7 days provide a buffer for the situation analysis, coordination, and vote preparation.

Tentative timeline

April 2026

  • LIP-34: CircuitBreaker is submitted for review

  • CircuitBreaker code is submitted for external audit

  • Hoodi testnet starts

May 2026

  • Snapshot vote

  • Prepare onchain vote

  • Prepare monitoring

June 2026

  • Onchain vote: full switch from GateSeals to CircuitBreaker

References

14 Likes
Nansen Delegate Thread
Pol Lanski Delegate Thread
2

We think the fundamental question this proposal raises is: “How long can a decentralized protocol justify relying on a centralized mechanism like an emergency shutdown?” If the circuit breaker is successfully implemented and adopted, it could serve as a valuable reference for governance design—not only for Lido, but also for other DeFi protocols facing similar dilemmas—by illustrating a path toward gradually reducing trust assumptions.

It’s an excellent proposal, and our research team had the chance to take a deep dive into it.

https://4pillars.io/en/issues/lido-circuit-breaker

Learned a lot :folded_hands:

5 Likes
3

Thank you! Great writeup!

How long can a decentralized protocol justify relying on a centralized mechanism like an emergency shutdown?

My short answer: as long as the protocol can fail faster than governance can respond.

So it’s important to consider how the protocol can fail. I see 3 ways:

  • bad implementation,
  • bad spec,
  • external factors.

Full formal verification can solve the bad implementation problem. It can prove that the code matches the spec. However, the spec can have holes or external factors can cause the protocol to fail regardless. And FV for a protocol as big as Lido is a massive multi-year effort.

Another solution is what skozin mentioned: a permissionless invariant-based pausing. So instead of proving at compile time like FV, you check and prove at runtime. But there is an issue where external factors can produce a technically valid state without breaking an invariant but still cause the protocol to fail.

So for now, this proposal offers a small next step after GateSeal. Like GateSeal, CircuitBreaker still relies on a multisig to pause with a limited impact. But it doesn’t wastefully burn DAO bandwidth that can be directed towards achieving those long-term goals faster.

5 Likes
4

Thanks @azat_s for putting this together!

IMO, CircuitBreaker reads as a natural evolution of the GateSeal pattern — keeping the same trust assumptions while removing the operational drag that’s been compounding with every renewal cycle and every new pausable contract (e.g., V3 and Triggerable Withdrawals add to the surface).

Two things I’d highlight in support:

  • First, Ethereum is becoming a fast-paced environment in ways we didn’t fully anticipate when GateSeals were introduced. The roadmap is accelerating (Pectra, L1 and blob scaling, post-quantum roadmap), and at the same time AI-driven tooling is reshaping both the development and the attack landscape (referring to: [Security Bulletin] Batched Immunefi-reported Weakness Disclosure — March 2026 (funds not at risk)). Code ships faster, exploits get cheaper to discover, and the window between vulnerability introduction and exploitation is shrinking. Permanent safety infrastructure that doesn’t expire or require annual governance ceremonies is the right response to that pace — especially when the alternative is a gap between GateSeal expiry and renewal where we’re effectively unprotected.

  • Second, it’s worth emphasizing that one-time limited-timeframe pausability is not a compromise on broader DeFi architectural principles and ethos. The committee can’t extract funds, can’t upgrade contracts, can’t do anything except trigger a bounded pause that the DAO must then decide how to resolve. The pause is strictly time-limited, authority is consumed on use, and the heartbeat mechanism adds on-chain liveness verification that GateSeals never had. If anything, this is more aligned with decentralized access control than the current model — you get the same safety guarantee with less governance overhead, less room for human error in role rotation, and an auditable proof that the emergency committee is actually operational.

Last but not least, the 21-day pause duration calibrated against worst-case DG execution timelines also looks well-considered. Support moving this to Snapshot.

5 Likes
6

To clarify: CircuitBreaker is not an automated system. There are no oracle inputs, no price feeds, and no on-chain trigger logic.

It is a manually operated pause mechanism: a designated multisig calls pause(targetContract) when needed. “Programmable” refers to configurable durations, per-contract pauser assignments, and heartbeat-based liveness. There is no automated detection.

Please, see LIP-34, linked in the proposal, for full design.

3 Likes
7

CircuitBreaker has been deployed to Ethereum Mainnet.

Constructor parameters (as proposed):

Parameter Value
admin 0x3e40D73EB977Dc6a537aF587D48316feE66E9C8c (DAO Agent)
minPauseDuration 432000 (5 days)
maxPauseDuration 5184000 (60 days)
minHeartbeatInterval 2592000 (30 days)
maxHeartbeatInterval 94608000 (3 years)
initialPauseDuration 1814400 (21 days)
initialHeartbeatInterval 31536000 (1 year)
5 Likes
8

Audit results

Security audits are complete with deployment verifications and published in lidofinance/audits. No critical, high, or medium severity issues were identified.

Cyfrin. 2 informational items (1 resolved, 1 acknowledged) and 3 gas optimizations (2 resolved, 1 acknowledged). The report is accompanied by a Certora Prover formal verification covering 41 properties: 38 verified by the Prover and 3 verified by manual analysis under known Prover limitations.

MixBytes. 1 low-severity issue, fixed.

5 Likes
9

Snapshot vote started

Please get your wallets ready to cast a vote :white_check_mark:, the Transition from GateSeals to CircuitBreaker Snapshot has started! The Snapshots ends on Mon, 18 May 2026 16:00:00 GMT.

1 Like