A Multichain Strategy and Roadmap for Maker

Right, good ole’ ADRs. @krzkaczor I meant someone can spin-up an AMM on BSC and create a liquidity pool with BUSD/SyntheticUnauthorizedDAI – would be easy to fool newbies on BSC. But I get your drift–TY for the input

EDIT: By no means am I only picking on BSC–I’m seeing a lot odd things being spun-up on Solana as well. Some are hilarious like Degen Banana

Such a bridge with one operator would probably be considered a Money Service Business and would require KYC/AML from Alice and Bob (or violate U.S. law) and FinCEN registration. We have a legal opinion on the topic

… and creating opportunities for services like Component or Curve or Uni v3 or Balancer with low slippage between bridged stable tokens.

Well, there are federated bridges managed by broad and decentralized governance, which are audited, with years of track record without major security incidents. The ranging of models is actually stressing on showing tails of normal distribution of different designs which are not used in production. Most bridges are federated and upgradable, and minority are scammy or to be permissionless. What’s your point?

agree till you see fractioned Dai. e.g. Dai mintable by a third party bridge without 100% reserves. or Dai compounded (rehypothecatated) on the Ethereum side which will create more Dai supply than locked in the bridge. We did it once with DSR by converting Sai to Chai on xDai bridge till DSR went to 0. Now we are working on compounding of locked Dai (~20mm Dai locked in xDai bridge)

1 Like

It’s kind of like the good old days of Wildcat Money (mid-1800s), when American banks could mint their own currencies. Some were sound, others not so much. Any dollar issued that was backed by gold that could actually be redeemed would have been worth the same. But some banks weren’t so reliable… (ringing any bells?)

So long as you can get your hands on the L1 Dai backing the Wildcat Dai, you’re good.

6 Likes

:joy: :joy: Such a great analysis!!

1 Like

such method is used in science and known as retrospective study which is a research method that is used when the outcome of an event is already known. E.g. if you know that Dai can be redeemed from some bridges for a long time while being locked in a hostile and also open environment than most likely it can be redeemed during the same constrains in the future.

1 Like

Btw, many have asked how much Dai is already bridged over to other chains and here are the numbers.

3 Likes

Most bridges are federated and upgradable, and minority are scammy or to be permissionless. What’s your point?

The point is that if anybody is allowed to deploy a bridge easily (this will be the case with e.g. Optimism or Arbitrum using their generic L1<–>L2 message passing infrastructure), we will undoubtedly see many bridges allowing users to deposit DAI into them. Some will mint wDAI on L2s, some may only pretend to do so. Others will mint wDAI but they will allow their owners to steal all deposit DAI. These bridges will be alike ATM Cash Deposit Machines. Some will be legit, some will be scams.

1 Like

Fantastic post. Thank you.

On the two proposed areas of focus:

Where does this:

fit? Actually I think I don’t get what that describes exactly.

On having canonical, Maker-blessed DAIs for each L2: that seems very important and worthy of early focus. I can easily picture many users going for a non-confusing L2 stablecoin rather than expending the mental energy necessary to choose among 4 versions of DAI.

1 Like

Optimistic rollups suffer from 7-day withdrawal period. You can alleviate this through so-called LP-assisted exit, but that requires liquidity. MakerDAO, given that it can mint DAI, can provide unlimited liquidity to support fast withdrawals as described here.

If you mint DAI directly on L2 and want to withdraw it to L1 (which, IMO, you should be able to do), protocol also needs to ensure that there is enough DAI in the bridge

Finally if you mint DAI on L1, you may want to bridge it to L2 to enjoy cheap and fast transactions

These are three very different use cases

5 Likes

Thank you! That sounds important on any L2s with DAI, whether L1 or L2 DAI.

@Derek First of all, this is awesome! It’s great to see deep engineering thinking going on behind the scenes. This topic brings up a huge number of technical, security, existential and risk (both technical and financial) questions, which you exposed with mastery. I am totally with you on the analogy of Ethereum as a base financial layer, which will someday transform DeFi in simply Fi. I’ve made a few comments or questions below. Some of them, I have some ideas on options to consider others it’s purely to help with the thought process designing the analytical framework to move forward.

This development of L2, sidechains and rollups is mind-bending. For end-users it may cause confusion in the early days while exploratory, but I think it will be eventually more of an engineering issue. I think we may need to consider reflecting on it based on a parallel like the evolution of Linux distros and how frameworks were developed by engineers to make choices for their organisations. The majority of end-users have no-idea what servers their apps run on. But the engineering challenges working across platform infra & OS can be daunting. Same will happen in DeFi imho.

This brings some challenging risks, technical and financial. A new collateral type on another bridge / rolloup inherits its own L2 native implementation risk on that chain and that of the brigde / rollup itself. We never consider those on L1 because we assume it secure. We just look at some sc audits. Security stamps will need to be way more rigorous for those L2 implementations to give similar level of confidence. Not all security houses will be up for that task. In my view, Risk teams also would have to become very very security conscious to talk a similar language of engineers and security folks. From a financial risk pov, L2 collaterals will likely not have same level of liquidity, or liquidity will be unequal depending on stage of evolution of projects wrt L2 implementations. Also risk framework may have to assume a greater level of “technology debt” risk. Let us assume in the future a new shiny L2 may cause users to migrate collateral to another chain with subsequent dry up of liquidity in the original L2 one where Maker may have allowed DAI minting at some point.

This will be a technical challenge, particularly in zk ones. From a risk and analytics pov, this may be even more challenging to assess risks, as it all data dependent. It would require projects like theGraph or others to be playing catch up indexing L2 sc data for it to be readily available for risk management. And even then data engineering will need to quickly reconcile that L1 and several L2 data for flow of funds to make analytical sense. Composability/Cross protocol risk might be another to consider. With greater inter-protocol integrations like MIP50: Direct Deposit Module, how will we manage these across to L2.

Growth of DAI liquidity will be a plus. Are we assuming then to “port” all MCD smart contracts over to those L2 and have a similar MCD-2, MCD-3, MCD-n across them?

Reconciliation and fungibility of all that DAI will get complex.

Currently, these scenarios are not fully baked in the existing financial models and the implications of these to end-users, both individuals and institutions. This brings serious financial risk imho, which we’ll need to model. It will most likely be theoretical at the start. Our L1 balance sheet of assets could shrink significantly should this move of collateral out of L1 happen fast. We’ll need monitoring of these migrations to cater for that risk, which we currently do not have. From the end user and institutional side of things, this may cause disruptions for DAI liquidity in DEXes and CEXes linked to L1. For crypto educated counterparties the risk is mitigated, but for RWA ones that are largely new to this space, the liquidity risk can be considerable, scaring deals away. And eventually delaying the realisation of the “from DeFi to simply Fi” narrative.

I would recommend to add on this one a “composability” factor to the thought framework. Explore solutions in-line with protocols where Maker has the most integration and shared liquidity with. For example, where are Aave, Uniswap etc likely to be “playing”.

@Derek More than happy to put my Risk/IT BA/SC Auditing hat to assist with work-shopping some of the risks pointed above.

4 Likes

Great article!

Just the opportunity to see the immense amount of work which Maker and its core units do to address fundamental issues of DeFi, is amazing!. I’m very excited to see what the future of crypto holds and, upon reading this article, I’m sure Maker will be a part of it!

p.s.: someone should contact Ethereum community and tell them to change their motto to “Ethereum - Manhattan of Crypto”.

3 Likes

You make an interesting point Igor, I personally had not dived into it from this angle. I’d be interested to see/learn more about the implications from a legal perspective and how to best mitigate. We’ll need to add this to the technical and financial risk framework that @williamr expanded upon above as well.


Cool, thanks @Doo_Nam . I’ll also point the community to a tool built by @krzkaczor called https://www.l2beat.com/ which shows a number of current L2 projects, value locked, market share and their underlying tech - an awesome tool for a quick overview!


Thank you @williamr , much of the credit must go to @bartek , who has spent many hours conceptualising the theory above and throwing ideas back and forth with the team.

Indeed, as we see more end-customer frontends such as nexo etc, the technical challenges of understanding L1 and L2 will be abstracted away. Services that target the pain points of customers (security, speed, gas costs etc) will come out in front - this is great for the end customer but emphasises the importance for us to conduct technical and risk analysis ensuring that the reputation and security of DAI in whichever L1/L2 environment is maintained and upheld.

100%. We are at the beginning of a scaling journey here - not only are auditors in high demand for existing L1 projects, experience with L2 implementations is limited in this new and complex environment. A good takeaway from your statement is the need for a risk framework/checklist - we need to connect the technical, financial, legal analysis together so we have a holistic view accounting for risks over time.

I would like to engage with a data core unit - there is a wealth of knowledge that can be surfaced in this space not only for protocol engineering but also for Oracles as we reveal where liquidity is flowing and why there is demand.

Pursuing the theme that there is not going to be one solution to meet all needs, I expect there to be multiple implementations - however as we know, MCD core contracts are not something that can be simply copy pasted. I’m hoping we can be proactive, not reactionary by using data to determine where liquidity is going (seeking long-term flows - not short-term cycles) and use that to determine the optimal pattern/replication where needed.

Yeah, it’s pretty theoretical at the moment, I’d definitely like to work with you on what this financial risk could entail - and likewise how we scale these concepts as they relate to real world assets.

Similarly, we have @sctannr leading research into math and computational modelling (currently just for L1) but in time I could see this expand to include L2 variables, thereby giving us a parameter suite to conduct montecarlo-like simulations through computer aided governance to understand the implications of new environments - that’s a little further into the distance but we’re getting there.

All in all, we have a lot of work to do here :slight_smile: The immediate steps with Optimism and Arbitrum are our first foray into this space with much more to follow.

4 Likes

Thanks Milan, welcome to the Maker community and the L2 journey!!

3 Likes

@Derek
100%. As the ecosystem becomes more complex I can only see data engineering becoming a core function of everything we do. In my view, this should be a top priority in the Maker roadmap and one of the biggest gaps within Maker atm.

Sounds great. I’ve been doing some R&D for the RWA team to embed those risks into the multi-tranche securitisation model. I think a wider framework may have to be thought to encompass RWA and crypto-native for these risks in a multi-chain environment.

Absolutely. We don’t have to reinvent the wheel for everything here. There are some strong maths/analytics communities already doing solid work in this space (multi-agent computations etc). I know some guys in these communities and have been “playing” with some maths models.

1 Like

Have you considered the “Rainbow Bridge” architecture that NEAR protocol uses to bridge to Ethereum? I looked into it a bit few weeks back.
I believe its more decentralized and does not require custody like most bridges.
They use smart contracts to lock up a certain amount of tokens on both sides of the bridge. Kind of like a vault on each side of the bridge.
This accommodates for each L1’s own attributes. As in, NEAR can still use their own primitives.
My viz attached.

1 Like

I think there’s already Dai on NEAR using this Rainbow bridge

Hi Derek,

I would love to speak to you about this proposal,

I come from an ecosystem that is EVM compatible and has a ‘L2’ solution that is about to be released.

Personally, I am interested in forking Makerdao to grow the ecosystem there, however, I see no point in creating yet another stable coin which is not vastly adopted, i.e. it is better to just issue DAI…

The project would mostly target coins not supported by makerdao and has a very secure way in doing so.

Overall, it will follow the philosophy and methods of Makerdao, but not necessisarily to the fullest, this is because for example, makerdao aims to only integrate coins which are:

  • Uncorrelated with major cryptocurrencies
  • Large marketcap
  • Lots of demand for credit using that collateral.
  • As decentralized as possible

Therefore, I wouldn’t expect it to be a move of makerdao? but the allowance through cooperation of issuing DAI’s through this project?

We have the devs and resources to make this happen, but the preference is to work with makerdao to issue DAI.

Would also like to talk directly too, if possible.

Out of curiosity; what’s the name of this “EVM compatible ecosystem”?

Sounds good Sir–but what do I do with my DAI once I get to NEAR? Any apps, Farms, AMM, etc.? Also, what wallets are y’all using over there?–last one I look at was a browser based “pain in the arse” wallet.