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

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.

6 Likes

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.

5 Likes

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.

2 Likes

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

10 Likes

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.

A:
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

6 Likes

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.

2 Likes

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

2 Likes

@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?

2 Likes

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

2 Likes

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.

4 Likes

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.

2 Likes

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

3 Likes

Hi @MadShills , you can find the risk framework for Starknet at the top of the MIP

1 Like

Circling-back to a question you answered above:

Can you please highlight what StarkWare/StarkNet has done in the way of supporting other protocols and integrations? For the delegates and MKR token holders to do their due diligence–IMO they will need to understand how the 50:50 arrangement stacks up with what you have done with dYdX, Immutable X, Sorare, DeversiFI, etc.

Also, would it be possible for you to make the personal consulting agreements with the CU team members public? I ask because knowing our @GovAlpha-Core-Unit team, they will ask for such as they did with this RWA document.

As I mentioned, StarkWare’s StarkEx deployments include a commercial agreement with our partners. In terms of work, StarkEx’s architecture demands technical contribution from both parties. StarkWare is of course the sole developer of StarkEx, but each one of our existing clients had a dedicated product+engineering team devoted to the integration of their platforms with the StarkEx API.These integration efforts took months of work by both parties.

This shared product/engineering effort is common. Indeed - this is what the DAO itself is doing with Optimism and Arbitrum - where Optimism and Arbitrum are sharing their base classes, framework, etc but it’s the Maker protocol CU who migrate the Maker protocol to these L2 environments.

Since we see a unique value in the development team being external to StarkWare (due to reasons of independence, transparency, etc.) - the shared effort suggests that joint funding is the sensible approach for this project.

Sure, they will be shared shortly.

2 Likes

@ElProgreso you will find my agreement here. We will share the other agreements as they will be signed by the other team members. Please keep in mind that those agreements do not reflect the 50/50 split in order to make it easy for team members to deal with their taxes.

2 Likes

Thank you Loui Vuitton :wink: and @Ohad_Barta_StarkWare for the presentation this evening. Very helpful in understanding your CU MIP39 application.

As @juan ask during the call–with regards to how much phase II will cost MakerDAO, can you please provide some rough figures? This way MKR token holders can understand what they’re getting into. During the call you mentioned that you would Add a couple of engineers (can be costly) to the team. Hence, to get a grasp of the phase II costs/estimate–that would be so appreciated. And if you can also provide terms–can you please provide us with such?

This way Phase II cost does not give MKR token holders “sticker shock” if the costs 100x.

Also, I forgot to ask these question during the call:

  1. I believe there already is a native bridge on StarkEx for Dai and ERC assets, correct?
  2. Is the ultimate goal here to rebuild Maker on StarkEx? I ask because if the native bridge is already active on StarkEx, then I think the community needs to grasp that this can be similar to an R&D project with $_______ amount in expenditures, and such and such should be the expectations.

Again, much appreciated for the time and energy you have taken to answer all of our questions, and thank you in advance!

3 Likes

Q: Thank you Loui Vuitton :wink: and @Ohad_Barta_StarkWare for the presentation this evening. Very helpful in understanding your CU MIP39 application. You’re welcome @ElProgreso , trying to answer your questions below the best we can. They all make total sense. Hope this will help understand our process and bring further fruitful discussions.

As @juan ask during the call–with regards to how much phase II will cost MakerDAO, can you please provide some rough figures? This way MKR token holders can understand what they’re getting into. During the call you mentioned that you would Add a couple of engineers (can be costly) to the team. Hence, to get a grasp of the phase II costs/estimate–that would be so appreciated. And if you can also provide terms–can you please provide us with such?

This way Phase II cost does not give MKR token holders “sticker shock” if the costs 100x.

I believe there already is a native bridge on StarkEx for Dai and ERC assets, correct?

A: The question of narrowing Phase II costs is an important one, we are collectively working on it with other CUs, and we have no doubt it will be far (far) less than 100X. It’s not just in this CU’s hands and we wish we could confidently give a very precise answer at this stage. The reality is that Maker has an ambitious multi-chain strategy and developed a risk framework to assess what chains/L2s to expand to. However, we have not generated yet guidelines on the scope and the phasing of those expansions, which would dramatically reduce implementation and operational risk. To be more concrete, when you look at the three high-level functionalities of minting, oracles, and liquidations, there are dozens of ways you could implement those on different L2s (in different orders, with a different architecture etc…). Not providing guidelines for consistency across L2s induces implementation and operational risk, and will reduce the ability of CUs make technical recommendations and decisions in the future (which is really not a future we want to be in). Hence we think there is a strong need to harmonize the approach and provide both scope and development sequencing guidelines to L2s (not just for Starknet). This will be determined by work this CU will conduct with other Maker CUs, including the PE CU. We are confident that even under this uncertainty, a gradual path within Phase II, which gives the DAO the ability to control expenses as it deems fit, can be set.

Of course, ERC-20 tokens, including DAI, are bridged to StarkEx (which is very different from StarkNet). As for StarkNet - StarkNet is yet to hit mainnet (this is expected soon). A “default” ERC-20 bridge is currently implemented at StarkWare for the launch. However, we see a unique value in a DAI bridge that is controlled by the DAO and being developed in a close relationship with it - this is the only kind of bridge that would allow us to claim that this is “official DAI” and that can be used to implement liquidations, etc. later on.

Q: Is the ultimate goal here to rebuild Maker on StarkEx? I ask because if the native bridge is already active on StarkEx, then I think the community needs to grasp that this can be similar to an R&D project with $_______ amount in expenditures, and such and such should be the expectations.

A: The ambition is to port over the Maker functionalities on L2s to rip the benefits of scalability which will translate into a stronger value proposition to users, and hence MKR appreciation. To simplify, the high-level functionalities impacting the most the user experience are: the bridge, minting, oracles, liquidation.

As mentioned in the answer to your previous question, given the multi-chain strategy that Maker is developing, Maker PE CU along with other CU is working on formulating a consistent approach for L2s that is focused on implementation guidelines to ultimately reduce complexity. Those recommendations will address the sequencing and the architecture of the functionalities mentioned above. This foundational work is not a Starknet-specific work, rather it’s a necessary work to assure that operational and implementation risk of L2/sidechain expansions is under control for the Maker protocol as a whole. In other words, we created a risk framework for each individual L2s, but have not generated yet recommendations on how to best manage the implementation/complexity of multiple L2s that have passed the risk assessment.

This phasing and architecture recommendation work is not a small task. It requires the involvement of multiple CUs, and particularly the PE CU. The PE CU is currently working on guidelines for the bridge. The guidelines for minting will be developed during phase I conditionally on PE CU having the mandate to focus on L2 expansion.

2 Likes