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.
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
@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.
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”.
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 The immediate steps with Optimism and Arbitrum are our first foray into this space with much more to follow.
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.
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.
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
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.
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.
Representing Ren here (we work on Multichain infrastructure): the concerns and opportunities raised here are spot on.
The multichain future is a given. Even if Ethereum remains the core crypto platform and is able to scale, there will always be users and projects drawn to other chains for any number of reasons (speculative yield activities, crypto-cultural differences, national influences), and there is a clear opportunity for MakerDAO to serve users on these other chains and benefit from that. And it certainly isn’t clear how a complex system like MakerDAO should tackle all the security and UX issues around serving multiple chains/shards/layers.
Relevant to the topics brought up here, we at Ren are wondering whether we should adapt to MakerDAO’s needs, because very soon we’ll allow arbitrary token movement across smart contract chains we support, and we will obviously be promoting that functionality to crypto users. Which includes allowing folks to bridge DAI to those chains.
We are currently expanding the number of smart contract chains we support, currently have Ethereum, BSC, Polygon, Fantom, and Avalanche up, and adding support for Solana, Arbitrum, and a few Polkadot parachains in the next weeks. Arbitrary token movement for us will come sometime this summer. (And RenVM will become substantially more decentralized over the summer and following months, if anyone is worried about that).
Then we can:
move DAI wherever
move collateral assets to whichever chain Maker is possibly deployed on for DAI minting
(additionally we’re working on adding support for developers to deploy contracts on top of RenVM directly, so you can for example have a contract that listens for events on one chain and then executes an action on another chain, which perhaps is useful)
We’re super keen on hearing what kind of needs MakerDAO has, even if you don’t want to specifically use Ren for something, because that helps calibrate us to devs’ needs in general.
Hey @MaxRoszko , thank you for commenting. We are following Ren with excitement and we will be glad to discuss in details with your team how we can all support Multichain World. Right now the main concern for us is fungibility (or lack of thereof) of bridged tokens. For example, if I move my BTC through Ren bridge to Ethereum, I get renBTC. I can then move it to Polygon through their PoS bridge - I will get renBTC on Polygon. However this is not the same renBTC that I would get if I moved BTC directly to Polygon. Ideally we would like to work towards the solution when natively minted DAI and bridged DAI are fully fungible. This is possibile if we, as MakerDAO community, work with bridge providers but we do need standards and shared understanding of the problem.
Completely agree on fungibility being a core issue. We faced this ourselves recently:
We let users bridge to chains like Ethereum and Polygon, but before we put up our bridge to Polygon, people started moving ETH-renDOGE over to Polygon using the PoS bridge.
That PoS-renDOGE version is not compatible with our bridge, you can’t redeem it on Polygon to native DOGE, you have to exit back to Ethereum and then use RenBridge on Ethereum. That’s extremely bad and confusing UX. And then the PoS-renDOGE got liquidity incentives by Sushi and we had to contact them to get things sorted, but even when that is switched over to the proper renDOGE version, there is a bunch of ‘bad’ renDOGE on Polygon and we can’t force users to exit, the only thing we can do now is educate.
We need standards that most crypto projects can agree on, to prevent these mishaps that will only be more frequent I suspect. Even if that coordination will be hard. We at Ren are definitely onboard for discussions on that and want to help out any way we can.
Not from the NEAR community. You’ll have to ask someone who is from there about farms etc. I’m just an enthusiast about the tech, eco & inner workings. The suggestion was to use a similar architecture as the Rainbow bridge on other EVM compatible chains as it is non-custodial, quicker to snip up and reduces SPOFs with custodial bridges.
I think deploying Maker protocol on their chains is a high priority. Solona, for example, will likely see an explosion of real world assets tokenized to it’s base chain, with FTX already having custody of Fortune 500 shares in offshore subsidiaries and trading on FTX.com. SBF already signaled plans to launch these assets to Solona. Maker has a big competitive advantage with DAI being go-to decentralized stablecoin, but a Solona competitor could easily start taking share when real world assets issue there. If Maker pre-emptively deploys in this and other chains, we have a good chance of remaining the preferred credit facility.