Escape Hatches - Censorship.wtf

Hypothesis (0:35)

The hypothesis : immediate full decentralization may not be feasible or desirable for all businesses right away.

It's okay if some businesses want to take a more gradual approach to decentralization.

There may be alternative pathways besides full decentralization that still allow for some self-custody and anti-censorship properties initially.

"Escape hatches" are proposed as one such alternative : they could allow businesses to legally claim they provide some self-custody to clients.

Case study (2:10)

The priority for a non-crypto business is profitability, not necessarily full decentralization right away.

Self-custody could be an added value proposition to clients, especially after high-profile centralized exchange failures like FTX.

The business wants to reassure clients their funds are withdrawable on demand, unlike FTX. For the business, "non-censorship" would mean users can withdraw funds independently without permission.

Escape hatches are proposed as a way to enable some self-custody and non-censorship properties initially. They need to be precisely defined and minimal, like only enabling uncensorable withdrawals and trading.

The two key transactions that need to be uncensorable for basic self-custody are :

1. Full withdrawal of funds
2. Forced trade execution

This provides some self-custody and non-censorship while still allowing the business to focus on profitability in a transitional stage before full decentralization.

Moral of the story (4:25)

For businesses, profitability is the priority. Self-custody is an additional feature. Legally, businesses can claim to be self-custodial if they can prove users can withdraw funds on demand.

Businesses may just want to offer some self-custody, even without full decentralization. This is positive and should be encouraged.

Decentralization is very difficult, as evidenced by challenges even for Layer 2s. So we need to allow some flexibility.

Escape hatches' role is to create tools and bridges to make self-custody easy for entrepreneurs building services.

The trading fintech example (6:15)

The trading company wants immediate self-custody for users, but not full decentralization yet. If a centralized business implements escape hatches well, it can boost profits and user satisfaction through self-custody.

This is a win for the crypto industry too, helping bring security and autonomy to more users.

Escape hatches are one way to enable self-custody without full decentralization initially. We should consider how to make self-custody easy for entrepreneurs building services used by millions.

The Appchain example (8:05)

Decentralization is ideal for blockchain transactions, as it makes them censorship-resistant and gives users control over their own funds (self-custody).

An "appchain" is a blockchain dedicated to a specific application, rather than being a general-purpose blockchain. Appchains are like layer 3 solutions tailored for particular use cases.

Many existing appchains are focused on exchanges, NFTs, DEXs etc. Examples are Dydx, Immutable X, Loopring etc.

These appchain-based exchanges and NFT platforms already successfully use escape hatches today. The escape hatches allow them centralized control over funds when needed, while still maintaining a high degree of decentralization and user control for normal transactions.

The dYdX case (10:20)

dYdX has already used escape hatches successfully. Over 150 users have already forced transactions and withdrew funds from dYdX, including amounts worth millions of dollars.

This shows the escape hatch is working as intended : to let people get their money out if they want.

Escape hatch architecture :

1. L1 queue contract
2. L2 app chain notified
3. User calls escape tool
4. Sequencer processes
5. App approves/rejects
6. User gets L1 withdrawal if valid

If app doesn't respond in 7-14 days, app is frozen as penalty. Users can then withdraw funds via balance calculator.

This protects against app censorship or failure while allowing transitional non-full decentralization.

Risks (16:40)

The main issue is denial of service (DoS) risk, as users can be spammed with force transactions : An attacker could send many force transactions to overwhelm the app and trigger a freeze if even one is not processed in time.

In Starknet, force transactions are made expensive (e.g. 1 million gas) to deter spamming attacks.

No major spam attacks have occurred yet, so the high cost seems to be working as a deterrent. However, other anti-spam measures may still need to be considered.

Another issue is contract upgradability : if contracts can be easily updated, the app could bypass the freeze.

In StarkEx, upgrading contracts to bypass freezes seems harder. But this needs to be considered when implementing escape hatches in Starknet app chains.

Next steps (18:55)

Escape hatches will be implemented for app chains in Starknet. They will likely be used for DeFi apps like exchanges, gaming, etc...

It's an open question whether escape hatches should be implemented for the public Starknet layer 2. This would pose big technical challenges, because escape hatches must be minimal for security.

Escape hatches make self-custody easy to legally claim for businesses. Without these bridges, businesses may not bother with decentralization or self-custody.

Implementing escape hatches, even transitional ones, helps bring key elements of decentralization to mainstream apps. This can help prevent major centralized failures like FTX in the future.