MIP39c2-SP19: Adding the StarkNet Engineering Core Unit (SNE-001)

MIP39c2-SP19: Adding the StarkNet Engineering Core Unit, SNE-001


MIP39c2-SP#: 19
Author(s): Louis Baudoin (@louismerkle), Ohad Barta
Contributors: Derek Flossman, Maciek Kaminsky, Kris Kaczor, Marc-Andre Dumas, Ohad Barta, Louis Baudoind
Tags: core-unit, cu-sne-001, mandate
Status: Formal Submission
Date Applied: <2021-08-09>
Date Ratified: NA

Sentence Summary

In a volatile, high gas cost environment, DeFi protocols are attempting to build bridges to L2 protocols to access liquidity and remain competitive. This proposal is a plan to build a DAI bridge over Starknet within 3 months (phase I) with a total budget of $420,750, of which $210,325 is requested to Maker in this proposal. A detailed plan and budget to enable minting DAI (phase II) will be the subject of another proposal and governance vote. This project opens the door to leveraging StarkNet to keep the Maker protocol attractive to users in the ZK-rollup, Layer 2 domain.

This document assesses the risk in onboarding StarkNet’s L2 solution using this proposed L2 Risk Framework.


Why do we want to expand the Maker Protocol beyond Ethereum?

  • Defi activity has diverged—Ethereum is still the “Capital” of the DeFi activity, but a growing number of other solutions offer their own unique package of security, scale and functionality. As users are expected to use Ethereum competitors more and more, its crucial for Maker to establish footholds on these platforms - in order to keep DAI highly usable and interchangeable among them
    Derek’s post highlighted the multi-chain strategy for Maker and was widely discussed amongst community members
  • Furthermore, operating on a scaled and fast environment comes with its own set of unique opportunities:
    1. This gives the opportunity to inspect improvements to the protocol, which are just too expensive for L1. The ability to mint, trade, liquidate faster brings opportunities for the users and for the protocol itself.
    2. Increasing transaction speed would be very attractive for some categories of users (e.g., short-term borrowers, shorter-term traders) who can now mint DAI intrablock and hence open use cases that were not possible before. As other Defi protocols are building bridges to L2, not doing so as well would erode the competitiveness of Maker as a protocol.

What does it mean to expand maker?

  • Build a bridge from L1 (scope of this phase I proposal) to the said new environment. Building a bridge requires a flow of funds adapted to the new environment and a governance process around the upgradability of the bridge.
  • In later phases, allow the new environment to mint DAI in order to make it easily available.
    • Such minting requires trust in the system, as unregulated minted DAI is devastating to the protocol.
    • Strategically port over the L2 key functions, contracts, or modules that will enable minting
    • Address key risks in adding minting functionality. Both from a security standpoint and a system-level risk standpoint
  • In later phases, explore protocol improvements leveraging lower gas feed and transaction speed
  • In the future, open official bridges between the new platform and other platforms in order to make the trading experience more seamless for users. We need fast finality and a high level of trust for such bridges to be worth it

Where is it worthwhile to expand to?

Why L2?

L2 solutions are the best place to start from since their state can’t be corrupted unless Ethereum is hacked (plus liveness assumptions in the case of Optimistic Rollups - OR). However, the consensus algorithm of a sidechain doesn’t depend on Ethereum. This introduces a new (and in most cases - larger) risk to the Maker protocol (that currently assumes only Ethereum is well-functioning), making the process of minting DAI there much less appealing.

Why validity proofs?

Maker is already considering such expansion to Optimism. So why bother with Validity proof based systems as well?

  • Capital inefficiency: OR have a high finality time (1-2 weeks) which may impose liquidity constraints to users. A solution put forward to the community for fast-withdrawals from optimistic L2 (or similar design) is for the Maker protocol to provide liquidity with locked DAI as collateral. However, this approach puts an implementation risk either on the users (DAI holders) or on the MKR holders (depending on exact design).
  • Different security model: OR assumes there is a live, honest observer that would submit fraud proofs if needed. This adds game-theory arguments to their security analysis, and again makes it non-equivalent to Ethereum - exposing Maker to new (even if minor) additional risk. This limits the trust in the system, and thus expected to limit the will to mind large quantities of DAI on it.

Why StarkNet and not any other validity proof?

  • StarkEx is one of the leading L2 solutions offered today, with many projects and DeFi activities expected to move to StarkNet soon.
  • STARK Cairo verifier has been operational for a while. It is the same verifier for all Dapps running on Cairo so trust is built across all deployments.
  • StarkWare has the experience of taking liquidation-based L1 protocols, namely dYdX, and turning it into a successful L2 protocol: for example, when dYdX’s system migrated to L2 they added cross-margin logic which was too expensive on L1, and still enjoyed a x200 scale factor in their gas consumptions.
  • StarkNet would be highly interoperable with other platforms. The value of enabling trustless applications to build onto the Maker protocol while leveraging cross-chain interoperability is increasing the volume of DAI minted through scaling partners without compromising on security.

What benefits can we expect from Maker on StarkNet?

Projects like Uniswap and Aave have tripled their number of users by moving to L2. Most of this increase can be attributed to lower gas fees and faster transactions, which provides a better user experience for existing users, and attracts new categories of shorter-term traders trading with a higher turnover, and leveraging cross-protocol trading opportunities.

Those types of benefits will not be ripped before phase II. Building the bridge in phase I is the foundation for benefiting from those advantages which will require minting, and potentially later liquidation and oracles to be on L2. By phase II, Starknet is expected to have onboarded other major protocols, hence creating arbitrage opportunities and synergies between the protocols. The intent of the points below is to communicate to the community the value of the Maker over Starknet project beyond phase I.

Protocol improvement through cheaper transactions

The vat since launch has cost 5,697 ETH equivalent in gas fees, 60% of which is due to calls performed for minting. Most calls made to the vat are made by the users who are paying those fees.

As a point of comparison, complex perpetual trading transactions cost 1100 gas in ZK-Rollup mode on Starkex, which is 200x cheaper than an L1 implementation of the same logic.

Protocol improvements through speed

The avenues for protocol improvement that translate into an organic appreciation of the MKR token are about being attractive for new users, and improving the value proposition for current users.

Better value proposition, or new value proposition in the Maker context will have to do with improving the DSR, reducing the collateral ratio, improving the liquidation experience, reducing minting time, while allowing fast withdrawals.

None of those levers are achievable through a L2 alone. They would require multiple governance votes and the implication of relevant CUs to assess the risk related to those improvements. However, none of those potential improvements would be possible without a solution that would bring increased speed and lower fees.

For example, the dYdX protocol increased its leverage ratio from 10 to 20x after transitioning to Starknet.

Bridging to other solutions/platform such as sidechains

While StarkNet is definitely an interesting DeFi platform, it by all means won’t be the only one. Sidechains such as Polygon or Binance Smart Chain are extremely popular, yet they might not be secure enough to mint DAI on. On StarkNet, we can cheaply mint DAI and then have fast, inexpensive and trustless bridges that would move this DAI to other platforms. This is paving the way to cheaper “importing” of DAI to sidechains that is not currently possible.

Why use a new core team

  • The Protocol Engineering Core Unit (PECU) already handles expanding the Maker protocol to other environments, including Optimism and Arbitrum.
  • Having a new core unit handling expansions to StarkNet has the main advantage of specializing in Cairo programming language, which arguably requires undivided attention to assure the expansion is successful. It will also make it easier for the Starkware team to support the core team as they are developing Cairo development skills.
  • Other advantages of an independent core team include:
    • Decentralize the power of other teams and reduce bus factor
    • Promoting parallel development and faster delivery
    • Eliminate single points of failure

StarkNet Engineering Core Unit (SECU) Mandate

Security and Safety

  • Testing, including code reviews to align with Maker testnet-to-mainnet deployment practices.
  • Work with PECU and Oracles CU to ensure the implementation correctness.
  • Assess StarkNet security risks: including an analysis of different risk metrics and modules. This is to include an assessment from a security standpoint alongside stress-test scenarios that align with Maker’s Risk Framework.

Proposed roadmap

The scope for the budget in this proposal is only for phase I as described below in the chart.

Phase 1 deliverable and timelines: DAI bridge to Starknet (3 months)

  • Product

    • DAI bridge (month 2):
      • Solidity contract with annotated code
      • Annotated Cairo code
    • Governance
      • Upgradability mechanism (month 3): allows governance to vote on structural or logic changes to the bridge
      • Bridge limit (month 2): during phase I and II, the bridge will be subject to a DAI limit.
  • Governance of the project. We will have a DAI amount threshold for the bridge, set by governance. Updating this threshold will require governance approval. The intent is to gradually increase the limit to reduce the potential liability on Maker users. We suggest 1000 DAI as an initial limit for the bridge.Testing (month 2-3)

  • Planning ahead (month 3). Phase II planning including value proposition to MKR holders, roadmap, governance proposal, and budget.

  • Knowledge transfer: Cairo documentation is already available. The team will make sure that the entire products are thoroughly documented, in a way that is self-contained given knowledge of basic solidity and the existing Cairo documentation. This is crucial to ensure that the DAO receives the input for inspecting the products and decide on their future.

Phase II ambition: Minting on Starknet

Phase II budget is not in the scope of this proposal. Phase II will be focused on enabling minting DAI on Starknet. In order to converge to a consensus on the design for phase II, the community and CUs will be involved in discussions on design principles (inspired by the risk framework) as well as concrete design alternatives. The output of those discussions will be a phase II proposal.

Community involvement

  • The Maker community will be involved in deciding the DAI limit on the bridge. We suggest to start with a low amount of DAI (e.g., 100 to 1000).
  • The Maker community will be involved in discussions around phase II. Those discussions will also require inputs from the different CUs. The output of those discussions will be a proposal submission for phase II.
  • The Maker community will be involved in the elaboration of the L2 risk framework. Our team will do its best to contribute to this framework to assure future L2 bridges and developments are successful and risk-controlled.


StarkWare, the developer of the core StarkNet protocol, is proposing to co-fund this effort alongside the DAO on a 50/50 basis.


Hi @louismerkle, exciting proposal this

I have some questions, mostly regarding StarkWare

  1. According to the website, since 2018 there have been three rounds of financing of StarkWare totaling USD 111 million. At some point, I must assume the investors want their money back, but at the StarkWare website, I cannot find any trace of any monetization plan. How does Maker fit into this?

  2. What is the assumed duration of the engagement? Are you planning to be a permanent Maker CU or are you in it for the above-mentioned three phases or something in between?

  3. Are you guys a StarkNet-only team or are you planning to eventually become a generalist engineering team?

  4. This one is as much for @derek as for you. As far as I know, Maker is still committed to building bridges to Optimism and Arbitrum. With now possibly StarkNet as well, how is the PE team planning to juggle all three of these L2s without a) wasting too many resources or b) not having too much internal friction or competition? I mean, nobody wants to work on Optimism if it is going to be an Oldsmobile upon launch.

  5. This brings me to my last question which has to do with the approximate timing of this. Is it possible to stamp at least a year on the various stages? Is user interaction with Stage 1 a 2021 or a 2022 thing? And stage 2 and 3?


Hey, Louis. Just sent you a message with a couple of suggestions :slight_smile:

1 Like

Thanks @louismerkle for pulling this all together, great work!

Good questions @Planet_X , responding to question 4;

The Protocol Engineering Core Unit is committed to building bridges and promoting the notion of fungible DAI across various chains (including Optimism and Arbitrum). With regards to individual Layer2’s, we do not know who the long term winner will be and as a result, our Multi-Chain Strategy is to support a broad number of solutions (along with the necessary technical and security weighted reasoning).

In the context of the StarkNet proposal, I see the PE team’s main role as advising on the Maker ecosystem - namely core contract technical functionality, engaging on risk, integration and audit activities.

Regarding resourcing - aside from consulting (weekly or bi-weekly as needed) and conducting reviews and potentially collaborating on audit activities, the StarkNet team will be responsible for the ongoing work detailed above, allowing us to focus on the reminder of the smart contract development at Maker.

Regarding internal competition - I do not see the addition of StarkWare as being zero-sum in relation to e.g. Optimism/Arbitrum - this work needs to continue and will remain a key focus for our team, which will continue unless the L2 landscape changes due to risks/shifting liquidity etc,


Thank you @Planet_X . Some answers to your other questions below:

  1. Starkware’s monetization plan on Starknet is to charge a fee that will be magnitudes lower than Ethereum gas fees, even considering the expected increase in transaction volumes on L2. The timeline for the fees to be activated has not been discussed, the fees will be zero for the foreseeable future and for the entirety of the development phase. Starkware currently monetizes through business agreements with projects, yet there is no such agreement with Maker and there is no plan to have one.

2-3. We are planning on a 6 months assignment to start with. We envision that we might extend the project as we explore protocol improvement levers on Starknet, similarly to what happened with dYdX. Cairo being a necessary and core skill for this, the same team would be a great fit to keep working on it. Hence it’s likely that the CU will be active for more than six months, but as of now it is not proposed for it to be a permanent CU.

  1. @Derek just gave a good answer above

  2. We are looking to kick-off the project soon. We have already secured some team members and will be training them on Cairo in the next weeks. Phase 1 should be finished by end of 2021 and will include governance for the bridge. Given the recent Poly hack, the community should appreciate the need of a rigorous governance for the bridge.


Hey @louismerkle , let me introduce you to @juan who heads up the Sustainable Ecosystem Scaling Core Unit and leads a number of Pod sessions, where new proposals and teams can come to talk about their vision with the community. It would be great if you guys could sync to get community feedback on this proposal.


I would agree that it is very vague. I would like to see Starknet put up half the capital and MakerDAO put up the other half as a kind of joint venture. Both risks and rewards should be shared equally to ensure shareholder alignment.


Thank you @ejbarraza. We are currently refining the budget and will submit an updated version. I can however already confirm that 50/50 budget split is how it will be done.

@MadShills We are not forgetting your post. We are working on a structured response we will post soon. Thank you again for the great points you brought up.


I agree with you, the less risk for both parties the better for both.

I think it lacks some structure to make this proposal convincing.


@Saludiego_201 we are working on a proposal solely focused on phase I value prop/deliverables/ timelines/budget

1 Like

For transparency and context, having been personally involved in a lot of L2 scaling work done in PE CU, let me briefly say that I am personally a big supporter of this proposal. At the PE we are trying to look holistically at scaling Maker protocol according to the previously announced MultiChain Strategy and L2 Risk Framework.

As you can see on l2beat.com there are already a lot of L2 solutions out there and we expect many more to come in the future. We want users of each of these rollups to be able to at least use DAI, with the possibility of minting DAI using L2 collateral on some of these rollups.

Rollups differ from sidechains in that they do provide permissionless bridges - MakerDAO will not need to operate a bridge, but it will need to maintain control over the right to mint DAI on L2 (similarly to how DAI minting is controlled on L1 through the management of collateral risk parameters).

With PE focused right now on Optimistic Rollups and overall strategy, a separate CU focused exclusively on StarkNet, given that it has a potential to be one of the leading zkRollups in the future, is, IMO, the right and responsible way to scale our efforts.


Thank you @MadShills for taking the time to write your concerns about the first version of the proposal. We just edited the proposal to focus on phase I with clearer deliverables, timelines, and budget. We will be sharing the risk framework proposed for L2 assessment in the next few days. You will find our answers to your questions and comments in-line below.


Q: For transparency, what is the relationship of this project to PE, Oracles, other CU and teams?

A: This project is proposed as a new Core Unit for bringing Maker over Starknet. This team will independently work through phase I but it will syndicate an engineering and governance plan with the community and other CUs for phase II.


Q: Who are the proposed headcount

A: Headcount is 1 facilitator, 2 Senior Engineers, and 1 part-time Data Scientist. You will find more details in the budget. The facilitator is myself (see proposal), and one of the Senior Software Engineer is Maciek (@maciejka , Linkedin). Maciek has worked on multiple projects with Maker over the past 3.5 years. We are still working on recruiting a second Software Engineer and a part-time Data Scientist.


Q: What is the background of these individuals that leads us to believe they are capable of being able to execute on a project of this scale?

A: We will be combining on the team a mix of knowledge and skills to assure the success of this project. We realize that phase I is foundational for the future of Maker-over-Starknet and we understand what is at stake.

  • Validity proof and Cairo language. We are supported by the Starknet team and will recruit a Senior Software Engineer who is familiar with both validity proof and solidity.
  • Solidity development. Mandatory for all Engineering team members.
  • Security and security testing. We will be recruiting only Senior Engineers with experience securing decentralized protocol, we will be helped by the Starkware Engineers as well.
  • Software Engineering. We will be recruiting Engineers with a strong track-record of rigorous collaborative development of complex systems. For phase I, we are looking for team members who also have a strong appetite for planning phase II (i.e., work on design alternatives and the Risk Framework).
  • Oracles price definition. This does not matter for phase II, but is needed to plan for phase II.
  • Data Science. The improvements proposed in phase II require a data-driven approach in order to guide community discussions.


Q: I am not familiar with you as a poster, could you please introduce yourself, your team and your background? How familiar are you with Maker?

A: You can find more about me on the proposal for me to be the facilitator. The reason why I have been proposed as a Facilitator and why I am both qualified and interested about this project is that I am familiar with validity proofs, DeFi trade execution, Oracle price definition, and tight Product Management.

With regards to my knowledge of Maker. I have never contributed to the protocol in the past. However, I read the Maker documentation dozens of times in the past year, and arguably a hundred times in the past weeks.

I have been working for the past couple of weeks on better understanding the dynamics protocol and making a plan to communicate with the community and CUs to converge to a solution for phase I and II. I have learned so far with my relatively fresh eyes that:

  • The protocol being a complex state-machine, thinking through how to port parts of the protocols over L2 requires a time-dependent view of the protocol in order to adequately manage interdependencies and reduce execution risk. I believe such a document has not been produced recently. I am working on it to help guide the phase II design discussions with CUs and the community. I believe it will also be very helpful for any L2 work that Maker will do in the future. This document should be coupled with a gas fees analysis in order to prioritize and discuss the tradeoffs of different design alternatives.

  • Better data access would improve data-driven community discussions when it comes to assessing the improvements that L2 can bring (e.g., by minting on L2, liquidating, or having an oracle service on L2). Examples of data that would need to be readily available: gas fees per function, raw exchange trade data, median price, price at liquidation vs. price one hour prior would need to be readily available to discuss further improvements to the protocol with the community.


Q: I appreciate the general sentiment and desire to expand but there is no clear commitment to deliverables in this proposal. The open community comment phase does not obfuscate the experimental nature of the project.

A: You will find a more precise deliverable description in the updated proposal. We do appreciate the opportunity to expand the Maker protocol as well.


Q: It would be more appropriate to open the discussion prior before bringing a MIP post forward.

A: As per the updated proposal, we are targeting a bridge in phase I, which is the smaller step we can do, and which is what has been done with Optimism. The scope of further developments on Starknet will be subject to future proposals and governance vots. Taking your feedback, we will assure that those future phases are more extensively discussed within the community upfront.


Q: I do not see any clear timeline for any of this outside of 6 months? The proposal does not appear to be yet thoroughly composed;

A: See the updated proposal (link). Phase I is a three months project.


Q: I also do not see you note the risks to the DAO.

A: We are working on filling the Risk Assessment Framework suggested by Bartek. We will share it before the end of the week.

During the development phase, the maximum bridge DAI amount will be controlled by governance. We suggest starting with a small initial amount (e.g., 100 to 1000 DAI). Funds might be lost due to:

  • Bug Risk: We will mitigate this risk through extensive tests and audits.
  • L2 Availability Risk: either because StarkNet is unavailable, or because its operators censor withdrawal requests.
    • Self-Custodial Phase: Circa the completion of Phase II, StarkNet will be fully self-custodial, allowing users to withdraw their funds…
    • Insurance Phase: Prior to the Self-Custodial Phase, StarkWare will provide on-chain insurance, and the DAO will be able to reclaim it if needed.
    • The transition between these two Phases will be performed based on an explicit DAO vote.


Q: I am not familiar with starknet

A: StarkNet is StarkWare’s permissionless decentralized ZK-Rollup. StarkNet Planets Alpha 1 is already live on Ropsten, and its abilities are growing rapidly. We expect to be on Mainnet by the end of 2021 with a scaled down version of StarkNet. In 2022 we expect StarkNet to be fully decentralized, and contain a rich ecosystem, including (but not limited to) current StarkEx customers (dYdX, Sorare, Immutable, DeversiFi). You can learn more about StarkNet features here.


How does the bridge operate? What are the risks to the DAO?

The bridge is operated through a L1 contract that will lock funds while they are being exchanged on layer 2. The governance of the bridge will mostly be about upgradeability and bridge threshold amount as per the updated proposal.

You will find more details in the updated proposal and in the Risk Assessment Framework that will be shared in the next few days.


Q: Now looking at your budget, quite a serious commitment. It looks like you are defining this project as a work of first impression—meaning that it is an unknown outcome with unknown challenges. This first phase then is R&D on a fixed term.

A: Plase see the updated budget focused on phase I.


Q: The budget has no breakdown in any meaningful way or general rates for each headcount, a standard budget format for CU to date.

A: Please see the updated budget focused on phase I. We made clear in the first version of the proposal we submitted that the budget would be refined within the next couple of weeks based on community discussions like the onee we are having.


Q: The Pie chart is cute but uninformative. I am skeptical because you only have salary line items, literally nothing else in your budget?

A: See updated budget focused on phase I.


Q: It is unclear from this what the DAO will receive after giving you a 1.5mm annual burn rate for 6 months, plus a possible future MKR commitment. The closest thing to a breakdown is noting what isn’t covered, suggesting the actual budget is higher. I do not want to offend but this budget is inchoate without any justification or rationale. This leads me to make assumptions about the CU operational competence.

A: You will find a clearer list of deliverables and timelines in the updated proposal. Your feedback will be appreciated.


Q: You suggest the MKR/performance bonuses will be performance based. I do not see any performance milestones. This needs to be established upfront before any vote. Other core units asked for MKR in the future because they were necessary to ongoing operations and needed to be imminently voted in. This practice should be deprecated. I assume you intended to add that proposal prior to a vote.

A: This proposal focuses on phase I. No bonus will be paid in phase I. Bonus proposals will be made for phase II and be subject to a community vote.


Q: “….who will learn to master Cairo and be able to transfer knowledge.”

A: The team will produce documents if necessary to help the on-boarding of additional Engineers working with Cairo. During phase I, we will start a compilation of case studies to help Engineers on-board faster. The Engineers who will be confirmed for the team will go through a Cairo training financed by Starkware.


Q: When I read this, this project looks like you are asking the DAO to pay for professional development and education. The DAO does have R&D grants but nothing at this scale. If you currently do not program on Starknet or have a Cairo skillset, that needs to be clear, as it represents risk to project execution.

A: We are specifically recruiting Engineers with prior knowledge of validity proofs and willingness to learn Cairo. Starkware will pay for Cairo training prior to starting the project.


Q: What gaps are there in your team’s knowledge and what is the expectation of ramp up time? How do you intend to capture and transfer knowledge so the DAO isn’t simply paying to make you more valuable professionally under a sunk cost fallacy. E.g. what guides, reports, etc will you produce.

A: We are specifically recruiting Engineers with prior knowledge of validity proofs and willingness to learn Cairo. Starkware will pay for Cairo training.

We will ensure knowledge transfer through case studies, and also assuring those new Engineers willing to learn Cairo are on-boarded at phase II.


Q: StarkWare, the developer of the core StarkNet protocol, is proposing to co-fund this effort alongside the DAO What is Starknet paying you and what are they offering you?

A: Starkware will pay for half of the development costs, hence they will be paying part of the team’s salaries, yet the team remains independent.

What’s in for the team besides salaries? Working on an ambitious project that could bring significant growth of the Maker protocol.


Q: You have not noted that in your budget breakdown. You mention it is co-funded in the main post but the posted budget is one-sided. The absence of their contribution makes it look like you are possibly double dipping, not good. What is your arrangement and relationship with Starknet, if any? What are your past technical or financial relationships with Starknet, if any? What are your current relationships with PE and other core units?

A: Starkware will pay for half of the development costs. See updated budget for the MakerDAO budget. The team will only receive the compensation indicated in the budget for each phase. None of the team members are affiliated to Starknet and won’t be affiliated to Starknet during their assignment.


Q: The DAO Core Unit format appears like a round hole and a square peg in this scenario. It feels like you are asking for an experimental 6 month R&D contract where you want to research and take a shot at building a starknet bridge prototype?

A: The rationale for a core unit is that the value of L2 for the Maker protocol and MKR holders will be unleashed once minting along with other core functions will be achievable on Starknet. This will not be achieved by a bridge only (which is the focus of phase I). However, the next phases will require careful planning and development taking inputs and feedback from the community and different CUs, as well as strong knowledge of Cairo.


Q: If this is correct, it would make sense to clearly lay out the ecosystem analysis, and how starknet will meaningfully add to maker’s bottom line, DAI supply, etc., rather than cite four bullet points unspecific to Maker. It would also help the even handedness of your proposal noting possible risks to the DAO to better inform MKR holders. If this goal is not correct, please help us understand concretely what you would do if the budget were granted.

A: The updated proposal lays out the value drivers for MKR holders for phase I and II. Note that most of the gas fees are incurred by minting and liquidation, which would be the subject of future proposals. In a scenario where minting and other functions can be executed on L2, we can expect additional volume coming onto Maker through a better user value proposition. Those users will typically be trading on shorter timelines, and they would be using other DeFi protocols on L2s.

Hence building the bridge in phase I is the very first step to concrete value creation for MKR holders.


Q: What happens after 6 months? Are you going to disband? Ask for more money? At the end of 6 months, once the pile of money is spent:

A: Phase I is a 3 months project. At the end of phase I, we will have discussions with the community about phase II. A concrete proposal will be put together to support those discussions.

The team will be ideally positioned to keep working on phase II. However, it will be recommended to onboard new talents to assure Maker has enough Engineers who can code in Cairo and avoid a skills bottleneck.


Q: Maker will have the following: ABCD.

A: Please see deliverables in the updated proposal


Q: Maker will have learned: EFG.

i. Maker Engineers will learn Cairo for future developments.
ii. Maker will learn from phase II planning how to approach L2 projects beyond bridges (e.g., minting, liquidations, oracles). We will provide documentation to help support those future efforts and guide community discussions.
iii. By doing phase II planning, the team will look into different and heterogeneous data sources, and work through analyses. Thoughts and recommendations on data availability and analytics for guiding future L2 work and community discussions will be provided.


Q: This will have the following effects for Maker:

A: See updated proposal. For phase I, the ability to transfer DAI on Starknet and transact for faster and cheaper.


Q: We will know we have succeeded because these effects will be objectively measured by: XYZ

A: See updated proposal roadmap, deliverables, and timelines. For phase I, the deliverables are: bridge + audit, bridge governance, phase II community discussion, knowledge transfer.


Q: Our MKR bonus of ZZZ will be paid contingent on delivery of ABCD upon meeting metrics X,Y, & Z.

A: See updated budget proposal. Phase I won’t yield bonuses for the team. Bonuses for phase II will be subject to a governance vote.


Q: KPIs and contingent rewards will give you a better case to MKR holders.

A: 100% with you


Hi everyone, I’m Ohad, a Product Manager and Blockchain Researcher at StarkWare. Let me shed some light on StarkWare’s perspective on this CU team and effort.

StarkWare is developing StarkNet, and projects will need in-house Cairo talent to develop for StarkNet, so StarkWare is helping to seed that throughout the ecosystem.
StarkWare is offering to co-fund this activity because it’s mutually beneficial to onboard STARK/Cairo talent to important projects in the ecosystem.
We just want more projects & developers to be familiar with this tech, and are eager to help with offsetting costs to help with this bootstrap phase.


Sir, I think its outlined in the budget–50-50 split for Phase I – Pricing in at 420,750 DAI

One thing I had ask in the weekly Governance and Risk call is how do you plan on incentivizing DeFi Users to use your product? If we take a look at the total TVL of dydx, Sorare, Immutable, DeversiFi–we are looking at a combine TVL of $269M as of 18-0-2021.

Today a new project by Alpha Finance released Beta Markets and the TVL has already reach $67M and counting in less than 12-hours. This is all based on incentives. So, I was wondering if you had any thoughts on how StarkNet will scale this product and help MakerDAO grab the #1 spot on the L2BEAT charts?

As of today–Approximately how many Devs in the world are able to code in Cairo ( per active Github Repositories) ?


@ElProgreso. Thank you for your questions, answers below.

One thing I had ask in the weekly Governance and Risk call is how do you plan on incentivizing DeFi Users to use your product? If we take a look at the total TVL of dydx, Sorare, Immutable, DeversiFi–we are looking at a combine TVL of $269M as of 18-0-2021. Today a new project by Alpha Finance released Beta Markets and the TVL has already reach $67M and counting in less than 12-hours. This is all based on incentives. So, I was wondering if you had any thoughts on how StarkNet will scale this product and help MakerDAO grab the #1 spot on the L2BEAT charts?

Beta markets’ quick success is due to a novel short-sell product, and the fact that Alpha is building an ecosystem of incentivized users who trade across their services and gain incentives. On the ecosystem side, projects like dYdX and DeversiFi are directly complementary to Maker. Starkware will keep onboarding new projects onto Starknet and they are preparing a decentralization plan. On the product side, Starknet and other L2s can help Maker protocol be more attractive for users by having an influence on collateral ratio, DSR, liquidation experience etc … a higher speed lower fees L2 is a necessary condition for this, but such improvements also require important governance decisions and risk assessment

As of today–Approximately how many Devs in the world are able to code in Cairo ( per active Github Repositories) ?
According to discord and website visitors, we have about 1000 Cairo enthusiasts

1 Like

Thank you for your reply Louis.

Circling back to dYdX–on a recent podcast–I heard the founder Antonio Juliano say that with regards to withdrawals back to layer 1 (Ethereum), “withdrawal providers” front end-user withdrawals and make a fee. (assume “front” means they put up the money–incase you don’t understand my American lingo :slight_smile: )

Assuming Maker and StarkNet use the same model, who will play the Role of “withdrawal provider” and who keeps the FEES charged to Users looking to get back quickly, in such scenario?


Good question @ElProgreso, I believe Antonio was referring to a mechanism used with optimistic rolllups to enable fast-withdrawals L2 → L1, similarly to what Maker announced in March (see Optimism Dai Bridge with Fast withdrawals post) where DAI needs to be “fronted” (against fDAI) in order for the user to access their funds on L1 faster. The intent of this design is to allow users to withdraw funds from L2 faster than the OR finality time.

This process of “fronting” funds should not be as necessary with zk rollups since finality time is much lower. zk-rollups bring by design the same level of performance ( ~ 3h to access funds on L1) as the design described above with optimistic rollups. However, if capital providers were needed to reduce further the withdrawal time, those capital providers would be the same as for other L2s.

Let me know if that does not answer your question


Q: Hi Ohad,

Thanks for posting and welcome to the Maker Forums! The proposition of Maker on Starknet is exciting and indeed would be of large benefit to Starknet as you try to establish yourselves as a venue for DeFi.

A: Thank you for welcoming me, happy to be here! And thanks for your questions. We’ll be happy to respond. We kindly ask that you leave your comments here for others to see (we couldn’t help noticing you’ve been deleting your previous comments…)

Q: Can you point us to your online resources for other comparable arrangements and your developer and partnership strategy in general? Co-funding the effort is valuable and a generous offer. Still, for due diligence, it would be appropriate to understand what you normally do in this regard and how Maker fits in.

A: StarkWare currently has multiple StarkEx deployments on Ethereum Mainnet. StarkEx is our scaling engine for trading (spot, derivatives, NFTs), NFT minting, and payments. Our current partnerships for StarkEx are dYdX, Sorare, Immutable, and DeversiFi. Celer will be coming online with their own deployment in a couple of months. StarkEx deployments include a commercial agreement with our partners.

Our proposal for the MakerDAO is to build over StarkNet.
StarkNet is a permissionless ZK-Rollup. It is currently in Alpha on a public Ethereum testnet. StarkWare is in discussions with other DeFi protocols to bring them too to StarkNet.

Q: I had someone suggest to me today Starknet could cover the whole integration at 1mm for no problem as they gain more benefit and are aptly funded and liquid thanks to VCs. This approach wouldn’t be out of the ordinary; Maker funded many of its integrations and borne the cost at 100% when it saw strategic benefit.

I would simply ask that you consider such an opportunity, funding Phase I outright, as a gesture of your belief in the value of Maker. This would also de-risk counterparty risk between the multi-party funding arrangement which is challenging for a DAO to structure in the first place.

The path of funding Phase I, with a phase two budget co-funded at 50% or greater by Starknet, seems to make the most sense here. Of course, I am simply most concerned about Maker and getting a fair deal here. It is unclear how these arrangements were negotiated and by whom.

A: This proposal will benefit both StarkNet and Maker. In the proposal above we detail why Deploying the Maker protocol on a Validity based L2 platform can be a stepping point for substantially improving the Maker protocol and user experience To point out some of the improvements StarkNet will bring to the Maker protocol, and therefore to MKR token holders:

  • Inexpensive transactions
  • Inexpensive and fast interoperability with other chains
  • Higher frequency Oracle updates, resulting in a safer and more capital efficient protocol

We are proposing a co-funding arrangement not for financial reasons, but rather because we think a joint buy-in from both StarkNet and the Maker DAO are important to ensure the project’s success.

StarkNet is a platform under rapid development. Many important network design decisions are being made these days. Our goal is that the StarkNet CU will be 100% independent. It will have StarkWare support, for sure - but is expected (and encouraged) to faithfully report to the DAO,and ensure that the Maker protocol’s interests are ensured. This level of involvement and scrutiny would be more difficult to maintain if this is an internal StarkWare project (or if it’s fully funded by StarkWare).

Q: @louismerkle It might make sense on your budget to delineate the half that Starknet intends to cover in addition to the half Maker intends to cover, maybe include a single explicit written line item saying “Starknet Contribution”?. That way the entire requested deal and funding arrangements are documented in one place. 6s is a good example you may look to with regards to deal structure, reporting, and transparency.

A: In the new budget proposal we added a line with “Maker contribution” that reflects the funds expected of the DAO. For clarity, we will add a line for StarkWare’s contribution that would cover the other half.

Q: How is the arrangement between Starknet and the proposed CU being documented and enforced? I assume using a legal agreement? Since those documents are material to this arrangement, I would suggest you consider disclosing them as you move this forward. The last thing Maker would want is for Starknet to change their mind and be stuck holding the bag or have a sunk project. Just some thoughts to help manage risk here and an opportunity for Maker to show what a properly structured and promising rollup arrangement can look like

A: The agreements for now will be personal consulting agreements with the CU team members, per the approved budget. StarkWare is making a very public commitment to this project, and will suffer a painful reputational cost - first and foremost with other protocols, which will be watching closely as they consider their L2 deployment plans.


Hello Ohad–thank you for the answers to some of the community’s questions.

Can you, or @louismerkle provide a clear write up here considering fee structure and envisioning the long term product?

Also, the MakerDAO community and Delegates should consider asking for the option where Maker’s financial contribution is offset by an equal dollar value of stark equity or tokens. @PaperImperium @MakerMan @monet-supply and the rest of the community/delegates–please provide your thoughts.


@ElProgreso , the fee structure will be zero during phase I. Afterwards, StarkNet will be a fully decentralized network, with builtin coordination mechanisms.

On the product side, independent of Maker, we can expect:
i. the applications on Starkex to be able to transition to Starknet
ii. Starknet to become fully decentralized with built-in coordination mechanisms
iii. Interoperability features to be added to Starknet. You can read more on this medium post

FYI - We are organizing a Q&A session next Wednesday with people both from the team and Starkware. I will share the exact timing as soon as it’s available.