Escape Hatch

Escape Hatch

Providing emergency exits in case of layer 2 censorship.

The problem Escape Hatch solves

The year is 2025… and almost all TVL is held on Rollups. The government takes an autocratic turn and sees an opening against the still centralized sequencers of Ethereum’s layer 2s. Anyone not KYC’d can’t get their transactions into the blocks. Now that the L2’s front end has been taken down, the only way to get back to the safety of main-net Ethereum is… the Escape Hatch!

Meanwhile, in the present…
L2s/Rollups provide a great scaling solution. They promise that the users retain control of their funds and inherit the full security of Ethereum. However, the complexity and the technical knowledge needed leaves many users without the ability to do so.

Escape Hatch provides a simple, decentralized, IPFS hosted front-end interface that anyone can use to rescue their funds in case of censorship. Rollups are at their core contracts on L1 which hold the state of the separately running blockchain. Escape Hatch utilizes the built-in rollup smart contract functions to ‘force exit’.

The user needs to only connect their wallet on main-net Ethereum, choose their L2, and select which positions they want to exit. Escape Hatch then sends a transaction on L1, which the L2 sequencer must fill within a set time period (usually 7 days) and release the funds. If the transaction is not included in time, the L2 becomes ‘frozen’ and is unable to update state changes on L1. In such case, the user can then provide proof of token ownership to the L1 contract and release their funds.

Challenges we ran into

  • Poor/lacking docs on force exit functions, particularly on the testnets
    • We basically read through the smart contracts and utilized the etherscan write functions to test solutions before building them
    • Tenderly and etherscan’s transaction decoder were also very helpful in figuring out the function calls and flows
  • The complexity of different L2 operation flows
    • zkSync really helped explain the flow of escape hatching which we could then extrapolate to other projects
  • Finding the account ids
    • For all L2’s we looked at, the escape function requires the user id linked to the ethereum account
    • This is not an easy thing to find publicly available
    • We are currently using the sdk/api to determine this number, but users need to be educated to save their account id in order to escape. We could also keep a database mapping account ids to ethereum addresses in case of api/sdk censorship.
  • Next steps:
    • Bring the same service to Starkware (dYdX,IMX,Rino,etc), Aztec, and the incoming zkevms
    • Build a tool to allow users to generate the merkle proofs needed to prove ownership
      • These proof generation techniques are either open source, or have been promised to be made opensource
    • Create a continuously updating account ID database for the L2s linked to Ethereum Addresses to help users exit without the help of the L2 centralization at all
    • Allow users to optionally send a percentage of the escaped tokens to a public goods fund for censorship defense

Discussion