Skip to content

pattern-forced-withdrawal.md

Latest commit

 

History

History
123 lines (94 loc) · 10.7 KB

pattern-forced-withdrawal.md

File metadata and controls

123 lines (94 loc) · 10.7 KB
Raw
title Pattern: Forced Withdrawal (L1 Escape Hatch)
status ready
maturity production
type standard
layer hybrid
last_reviewed 2026-06-17
works-best-when
Users need a guaranteed exit from L2 or shielded pools even if the operator is offline or hostile.
Institutional deployments must demonstrate non-custodial protections for regulatory acceptance.
Censorship resistance is a hard requirement in I2U contexts.
avoid-when
L1-native operations where no intermediary can censor (for example, direct shielding on L1).
The cost of L1 proof verification exceeds the value of the assets at stake.
context both
context_differentiation
i2i i2u
Between institutions, neither counterparty can lock the other's funds by withholding operator cooperation. Institutional deployments may accept upgrade risk under bilateral governance (both parties on the multisig), since legal recourse bounds the downside.
For end users, unilateral exit is non-optional. The CROPS rubric requires a concrete user-initiated escape path for anything above `cr: low`. The user must be able to reconstruct their position, build the required proof, and submit it without operator cooperation; any step that depends on the operator breaks the guarantee.
crops_profile
cr o p s
high
true
partial
high
crops_context
cr o p s
Reaches `high` only when the escape-hatch contract has meaningful upgrade delays (Stage 1 or higher, 7+ days). Instant upgrades let the operator remove the hatch, which invalidates the rating entirely. DA withholding and proving liveness are liveness constraints documented under Trade-offs; they do not change the CR score, which measures whether a single party can exclude a user at the protocol level.
Forced-withdrawal contracts are typically open-source and verifiable. Users can run their own prover and submit directly to L1. Proving-key hosting for Groth16 constructions is a soft dependency: if hosting goes offline, users may struggle to generate valid proofs.
For privacy systems, the zero-knowledge proof hides which commitment is withdrawn; no KYC disclosure or transaction history reveal is needed. The L1 withdrawal still reveals that an exit happened at a specific time for a specific amount.
Rides on the soundness of the proof system, correctness of the verifier, and honest state-root anchoring on L1. For optimistic constructions, a 7-day challenge window plus honest challengers are required. PQ exposure applies to ZK systems over BN254.
post_quantum
risk vector mitigation
high
ZK systems relying on elliptic-curve pairings (Groth16, PLONK over BN254) are broken by a CRQC. An attacker with quantum capability could forge withdrawal proofs once state roots anchored on L1 become historical.
STARKs with hash-based commitments are not affected. See [Post-Quantum Threats](../domains/post-quantum.md).
standards
EIP-4844
related_patterns
requires composes_with see_also
pattern-zk-proof-systems
pattern-shielding
pattern-privacy-l2s
pattern-plasma-stateless-privacy
pattern-modular-privacy-stack
pattern-permissionless-spend-auth

Intent

When an L2 sequencer, relayer, or operator becomes unavailable, users need a unilateral path back to L1. Three pillars must hold simultaneously: the user has enough data to reconstruct their position, an L1 contract accepts proof of that position and releases funds, and the user can build the required proof on hardware they control. If any one leg fails, the escape hatch is ineffective.

Components

  • Data availability source lets the user reconstruct their position. Can be L1 calldata, L1 blobs, an external DA layer, a validium DA committee, or client-side storage.
  • L1 state-root oracle stores the last verified L2 state root. Validity rollups anchor with a zero-knowledge proof; optimistic rollups anchor after a challenge period survives.
  • Proof verifier contract accepts Merkle proofs (transparent systems) or zero-knowledge proofs (privacy systems) and checks them against the anchored root.
  • Nullifier registry records completed withdrawals to prevent double-claims.
  • Bridge liquidity contract holds the locked deposits that forced exits draw from; no new funds are created.
  • Client-side prover with the required circuit, proving keys or SRS artifacts, and local compute.

Where the data lives determines the trust assumption:

DA strategy Trust assumption Failure mode
L1 calldata Ethereum consensus Nothing (permanent, expensive)
L1 blobs (EIP-4844) Ethereum plus archival within ~18 days Pruned if nobody archives
External DA layer DA layer liveness plus economic security DA layer offline or withholds
DA committee (validium) Honest committee majority Committee withholds; funds frozen
Client-side The user User loses data; funds gone

For privacy systems, even with perfect DA the user faces a five-step gap between "data exists" and "exit succeeds": raw byte access, data parsing (the rollup's compression format), state derivation, proof generation, and L1 submission. Each step can independently block the exit. DeFi positions (LP tokens, lending, vaults) require custom resolver contracts to map complex storage slots to withdrawable amounts; most protocols have none.

Protocol

  1. [user] Detect operator unresponsiveness or censorship (for example, withdrawal requests ignored past a threshold).
  2. [user] Retrieve the latest L1-anchored state root and your position data (note, Merkle path, nullifier secret for privacy systems; account state for transparent systems).
  3. [prover] Generate the required proof: a Merkle witness for transparent systems, a zero-knowledge proof for privacy systems.
  4. [user] Submit the proof and nullifier to the L1 escape-hatch contract, directly or via any willing relayer.
  5. [contract] Verify the proof against the anchored root, check the nullifier is unspent, and start the withdrawal.
  6. [contract] Enforce the construction-dependent delay before claim. Optimistic rollups wait a challenge period (typically 7 days); validity rollups wait an operator-liveness timeout (hours to days).
  7. [contract] Record the nullifier on L1 to prevent double-withdrawal; the operator must account for this forced exit upon resumption.

Guarantees & threat model

How strong the escape guarantee is depends on the construction class:

Validity rollup Optimistic rollup Privacy rollup L1-native privacy
State freshness Latest proven root Root must survive 7d challenge Latest proven root Real-time
Proof effort Merkle witness None (force-include tx) Full zero-knowledge proof Full zero-knowledge proof
DA risk Low if on-chain Low if on-chain High (encrypted state) None
Escape without operator Yes Yes Partial (may need bonded proposer) Not applicable (no operator)

Guarantees:

  • Bounded recovery time: funds recoverable within a protocol-defined window whether or not the operator comes back.
  • No operator cooperation required. The L1 contract enforces withdrawal autonomously.
  • For privacy systems, identity is not revealed at exit. The zero-knowledge proof hides which commitment is being withdrawn.

Threat model:

  • State-root honesty and correct challenge-window enforcement on L1.
  • Non-censoring L1 inclusion path. The escape transaction must be includable on L1 regardless of L2 operator status.
  • Upgrade governance on the escape-hatch contract. An operator that can instantly upgrade the contract can also remove the escape hatch.
  • Out of scope: positions that rely on custom DeFi resolver contracts where no resolver exists; those balances are effectively unescapable.

Trade-offs

  • Upgrade risk: 86% of 129 L2 projects allow instant contract upgrades without exit windows (Ethical Risk Analysis of L2 Rollups, 2025). An escape hatch the operator can remove via upgrade provides no meaningful guarantee. L2Beat Stages requires 7-day (Stage 1) or 30-day (Stage 2) upgrade delays, minus any withdrawal delay.
  • DA withholding: validium DA committees can freeze all funds by refusing to share state. External DA layers add a liveness dependency. On-chain calldata and blobs are immune but expensive. For privacy systems, data can sit on-chain yet be useless without decryption keys.
  • State freshness gap: users can prove only against the most recently anchored root. Any transactions after that root are lost. Anchoring intervals range from minutes (validity rollups) to hours.
  • Mass exit: everyone hits L1 at once. Gas prices spike, users with no L1 ETH cannot participate, and leveraged DeFi positions may create claims exceeding underlying bridge deposits.
  • Proving liveness: for privacy systems, the user must retain secrets and run a compatible prover. The prover code must be open-source, deterministically compilable, and match the L1 verifier's expected proof format. A version mismatch means funds are frozen until governance acts. Browser WASM proving works but is materially slower than native.

Example

A bank operates a private payment L2 for its clients. The sequencer goes offline. A client holds 500 000 USDC in shielded notes on the L2 and their withdrawal requests time out. The client retrieves the latest state root anchored on L1 and builds a Merkle inclusion proof for their commitment. They generate a ZK ownership proof and submit it to the L1 escape-hatch contract (~300 000 gas for a Groth16 verification). After the 7-day challenge period, the client claims 500 000 USDC on L1 to a fresh address. The L1 transaction reveals that someone withdrew 500 000 USDC, but not which client or which L2 transactions funded the balance.

See also