In September, before the MIP got approved, we were focused on getting familiar with Cairo, devising a strategy for the testing environment, and organizing design sessions with members of the PECU.
In October, we have been focused on:
- Developing an ERC20 contract on Starknet which we have been getting feedback on from the Starkware team as well as the Open Zeppelin team
- Developing and testing the L1 bridge contract
- Developing and testing the L2 bridge contract
- Designing an escape hatch mechanism that can ensure self-custody until Starknet is decentralized
What is self-custody?
We define self-custody as the ability for a user to withdraw their funds on L1 in the event where L1 stops functioning (permanently or temporarily), or the sequencer is censoring the user.
Why an escape hatch?
Optimistic rollups (OR) allow some transactions to bypass the sequencer and be directly inserted in the Canonical Transaction Chain (L1 contract). Those transactions bypassing the sequencer allow OR to enable forced transactions, hence ensuring the self-custodial nature of the bridge even if the L2 is not yet decentralized.
Starknet decentralization will start in Q2 2022, which is arguably one of the most aggressive decentralization timeline for a L2. Once sufficiently decentralized, self-custody will become a characteristic of the bridge by design. However, in the meantime, just like OR did, we had to find a process that does not introduce new trust assumptions while ensuring self-custody.
We could not replicate the same design as with ORs because Starknet currently cannot have transactions bypassing the sequencer and hence an ad hoc process called escape hatch was required to ensure self-custody.
How did we converge to an escape hatch design?
The escape hatch is composed of an emergency detection mechanism and an exit process. We had a number of options available for each and had a number of discussions with the Starkware team and the PECU to converge to a short-term solution. You will find here a document highlighting those mechanisms and the options we considered.
We decided to implement a DAO-assisted escape hatch because:
- Of the temporary nature of the process. When Starknet will be sufficiently decentralized, such a mechanism should not be needed
- Such a design does not require additional trust assumptions. The DAO is in charge of distributing funds to users on L1 in case a transaction is censored for more than 7 days (plus a grace period). The DAO distributes the funds using a publicly available script that anyone can run to challenge the funds redistribution
- The DAO-assisted design does not require additional features that don’t exist yet on Starknet, hence allowing us to hit our November 12 audit deadline
The end of phase I is planned for the end of December. Our audit is coming up mid-November. We are currently focused on developing the escape hatch mechanism (emergency detection + exit mechanism) for it to be ready for the audit.
Once our code will be frozen for the audit, we will focus on phase II planning, and specifically the design of the fast withdrawal as well as a first implementation (optimistic deliverable).
Preliminary deliverables envisioned for phase II
- Advanced self-custody mechanism: Automated resolution of failed deposits. Potentially a dead-man switch emergency detection mechanism.
- Fast withdrawal mechanism: See here for current planning doc.
- Starknet-specific minting planning
- First implementation of DAI minting on Starknet (against collateral)
About fast withdrawals
Similarly to forced withdrawals, the fast withdrawals on OR are using the ability for users to insert transactions into the canonical transaction chain and bypass the sequencer. Hence fast withdrawal requires a different design than OR which we will design between mid-November and the end of December.
We originally planned for a naive design where liquidity providers to receive funds on L2 from users, and release funds to users on L1 within short timeframes (see naive design here). However, after discussions with the Oracle and Protocol Engineering CU. this week in Lisbon, we decided to make the fast withdrawal design closer to that of OR, with the DAO minting DAI on L1. Given the DAO-assisted escape hatch design, this fast withdrawal design would not introduce additional risk to MKR holders compared to the OR design. We will share a design document and seek for sign-off from the PECU and Oracles CU.
About minting on L2
Minting on L2 requires a cross CU effort, and particularly from the PECU (@Derek) , Oracle Core Unit (@NikKunkel ), and the Starknet Engineering Core Unit. @Davidutro the facilitator of GovComms CU has been working with the facilitators of those CUs to organize a L2 workstream which purpose is to synchronize cross-CU efforts for design and implementation. The goal is also to make it easy to involve other stakeholders for feedback and brainstorms. We will be particularly excited to work with the growth team (@Nadia ) to think through how to best use L2 implementation for user acquisition and retention.
About a dozen of members from Oracle CU, PECU, and SECU met in Lisbon this week to go through the main challenges of minting directly on L2. It was a great opportunity to kick-off the discussion and identify areas that require more work from individual CUs. The main topics we covered and we will define next steps for are:
- Global debt ceiling and debt ceiling per ilk
- Bad debt management
- Minting on multiples L2 and accounting implications