Skip to content

pattern-forced-withdrawal.md

Latest commit

 

History

History
139 lines (101 loc) · 11.8 KB

pattern-forced-withdrawal.md

File metadata and controls

139 lines (101 loc) · 11.8 KB
title Pattern: Forced Withdrawal (L1 Escape Hatch)
status draft
maturity PoC
layer hybrid
privacy_goal Let end users recover assets on L1 without operator cooperation, within bounded time
assumptions L1 escape hatch contract deployed, user retains note data and Merkle path, state roots anchored periodically on L1
last_reviewed 2026-04-08
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 (e.g., direct shielding on L1)
The cost of L1 proof verification exceeds the value of the assets at stake
dependencies
L1 anchor contract
zero-knowledge proof system
Merkle commitment tree
context both
crops_profile
cr os privacy security
high
true
partial
high

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 (DA), an L1 contract accepts proof of that position and releases funds (verifier + liquidity), and the user can build the required proof on hardware they control (proving infra). If any one leg fails, the escape hatch is ineffective.

Ingredients

Data availability

The user needs enough state to prove "I own X" against the last L1-anchored root.

  • Account-model rollups: Merkle proof of account balance. If transaction data is posted to L1 (calldata or blobs), anyone can reconstruct any account's state.
  • UTXO/note-model privacy systems: note preimage, nullifier secret, Merkle path. The on-chain data is encrypted; "available" does not mean "usable" without the user's decryption keys.
  • Client-side architectures (Plasma): the user is responsible for storing data locally. Some implementations offer backup storage servers (e.g., INTMAX), but these are convenience layers, not protocol guarantees. If local data is lost and no backup is reachable, funds are unrecoverable.

Where the data lives determines the trust assumption:

Strategy Trust assumption What breaks
L1 calldata Ethereum consensus Nothing (permanent, expensive)
L1 blobs (EIP-4844) Ethereum + archival within ~18 days Pruned if nobody archives
External DA Layer DA Layer liveness + 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, L1 submission. Each step can independently block the exit.

See L2Beat DA Risk Framework.

L1 verifier contract

Three components on the L1 side:

  • State root oracle: stores the last verified L2 state root. For validity rollups, this root was accompanied by a zero-knowledge proof. For optimistic rollups, it survived a challenge period (typically 7 days).
  • Proof verification: 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.

Liquidity comes from the bridge contract's locked deposits. No new funds are created. Pending transactions after the last anchored root are unprovable and effectively lost. DeFi positions (LP tokens, lending, vaults) require custom "resolver" contracts to map complex storage slots to withdrawable amounts; most protocols have none, meaning those positions may be unescapable (Zircuit, 2025).

Proving infrastructure

What the user must produce depends on the construction:

Construction Proof required User-side effort
Optimistic rollup None: sign an L2 tx, submit to L1 inbox Trivial
Validity rollup (transparent) Merkle inclusion proof Low
Privacy rollup / shielded pool Full zero-knowledge proof of commitment ownership High (seconds to minutes of compute)

For privacy escapes, users need circuit source code, access to proving keys or SRS artifacts (which can be large for Groth16), and sufficient local compute (roughly 0.5–3s native or 20–30s in browser WASM on current hardware). STARKs with transparent setup remove ceremony artifact dependencies. If Groth16 proving-key hosting goes offline, users may be unable to generate valid proofs.

Protocol (concise)

  1. User detects operator unresponsiveness or censorship (withdrawal requests ignored past a threshold)
  2. User retrieves the latest L1-anchored state root and their position data (note, Merkle path, nullifier secret for privacy systems; account state for transparent)
  3. User generates the required proof. Merkle witness for transparent systems, zero-knowledge proof for privacy systems
  4. User submits the proof and nullifier to the L1 escape hatch contract (directly or via any willing relayer)
  5. The contract verifies the proof against the anchored root, checks the nullifier is unspent, and starts the withdrawal
  6. A construction-dependent delay follows before the user can claim funds on L1. For optimistic rollups: a challenge period (typically 7 days) during which fraud proofs can invalidate the state root. For validity rollups: the state root is already proven, so the delay is an operator liveness timeout (hours to days, protocol-configurable) plus any safety buffer
  7. The nullifier is recorded on L1 to prevent double-withdrawal; the operator must account for this forced exit upon resumption

Guarantees

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 (always)
DA risk Low if on-chain Low if on-chain High (encrypted state) None
Escape without operator Yes Yes Partial (may need bonded proposer) N/A: no operator

When all three pillars hold:

  • Bounded recovery time: funds recoverable within a protocol-defined window, whether or not the operator comes back
  • No operator cooperation: the L1 contract enforces withdrawal autonomously
  • Identity not required to exit: for privacy systems, the zero-knowledge proof hides which commitment is being withdrawn. No KYC disclosure or transaction history reveal needed
  • I2I: neither counterparty can lock the other's funds by withholding operator cooperation
  • I2U: end users can exit on their own without institutional cooperation

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.

CROPS context (cr: high): the rating holds only when the escape hatch contract has meaningful upgrade delays (Stage 1+ / 7 days minimum); instant upgrades let the operator remove the hatch, which invalidates cr: high entirely. In I2U, unilateral exit is non-optional: the CR rubric requires a concrete user escape path for anything above low. In I2I, institutional deployments may accept upgrade risk under bilateral governance (both parties on the multisig). DA withholding and proving liveness, documented as separate trade-offs below, are operational/liveness constraints, not censorship: they do not change the CR score, which measures whether a single party can exclude a user at the protocol level.

DA withholding: validium DA committees can freeze all funds by refusing to share state. External DA Layers add a liveness dependency. On-chain calldata/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 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 their 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 = funds frozen until governance acts. Browser WASM proving works but is 5-15x slower than native.

PQ exposure: ZK systems relying on elliptic-curve pairings (Groth16/PLONK over BN254) are vulnerable to CRQC; see Post-Quantum Threats. STARKs using hash-based commitments are not affected.

Example

Bank X operates a private payment L2 for its clients. The sequencer goes offline.

  1. Client C holds 500 000 USDC in shielded notes on the L2; withdrawal requests to the sequencer time out
  2. Client C retrieves the latest state root anchored on L1 and builds a Merkle inclusion proof for their commitment
  3. Client C generates a ZK ownership proof and submits it to the L1 escape hatch contract (~300 000 gas)
  4. After the 7-day challenge period, Client C claims 500 000 USDC on L1 to a fresh address
  5. The L1 transaction reveals that someone withdrew 500 000 USDC, but not which client or which L2 transactions funded the balance

See also