Starknet Engineering Core Unit, October 2021 Update

Work done so far

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

Design considerations for self-custody

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

Next steps in phase I

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).

Phase II

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
  • Pre-minting
  • Oracles
  • Liquidation
  • Bad debt management
  • Minting on multiples L2 and accounting implications

cc: @maciejka , @nulven , @Ohad_Barta_StarkWare


Hello Louis! I ran into a Dev. at Liscon who works for one of the protocols built on Starkex, and he said the tooling for Devs learning & building with Cairo has gotten easier, recently. Can you please provide some color on this? I’m wondering how much easier it will be for PECU team members to learn & build w/Cairo with the recent StarkWare tooling.

1 Like

Hi @ElProgreso!

There is a saying that “good software, like wine, takes time”. That applies to Cairo. StarkWare takes iterative approach, they release frequent updates (already 9 this year) to the language. With every iteration it is getting more features which make it more easy to use. Documentation is also getting better.

Having said that, one has to remember that it is a very different execution environment than EVM. It is optimized for zk proof generation. With that come fundamental differences like: field elements, nondeterministic computation model, read-only memory. What is more at its current state the language is relatively low level. All of that makes it more difficult programming environment than EVM.

There is an effort to provide EVM compatibility layer. It is too early to say whether it will be successful.


Hello @maciejka thank you for posting a response and welcome to the Maker Community. When it comes to dealing with StarkWare, has it being your experience that this iterative approach hampers their ability to meet deadlines? If so, what is your opinion on the deadline to decentralize by Q2 2022? It feels like the idea to have an escape hatch is a good one.


I would say rather the opposite. They are able to execute very agresive roadmap because of iterative approach.

As for decentralization it is too early to say. Up to know they prooved to be able to meet the deadlines.

Decentralization is what they are working on right now or will be working on in near future. As far as I know, no designs were published so far.

1 Like