Scaling DeFi: The Case for Minimal Protocols.

Transcript

[Music] Is it good? Oh well, let's go. All right. Um, so today we'll talk about uh how we scale DeFi. Um, so I make the case for minimal D5 protocols. The reason why is so first we all want to

build uh fairer, open, more open, more transparent, more resilient, efficient, accessible uh financial systems. For that we need to bring the whole financial existing financial system on chain. It's 47 470 trillion. So it's massive. There's just like 200 billions something like that may maybe a bit more but this just a drop uh compared to this ocean of water that the the financial system represents.

the current system is not going to make it uh if we don't build like protocol the right way. As of now there there was like 6.5 billions of uh uh protocols being hacked or users being scams etc. It's not taking into account maybe the last year. So it should be higher. So it's a massive massive number if you compare to the size of DeFi. So obviously if we bring the whole financial system on chain we don't want that.

So we don't we don't want that and um we've been working three years on top of existing defy protocols at mofo. So we have realized we've at the same times providing a financial uh defy protocol uh lending uh lending protocol to users and also building on top of existing lending protocols as close as we can uh we can do. So sorry about the the slides they are changing from one slide to another. Anyway, um what we've realized over those three years is that a lot of those D5 protocols are not uh not really secure. Uh there's smart

contract risk and there's market risk. Um is this just because they are like not following any good security practices? Uh they are not efficient. There's huge spread between supply and borrow rates on on lending protocols but also uh huge leage on on on dexes uh low capital efficiency. And we spotted a third problem is it does not scale in a world where you have uh thousands or even even millions of tokenized assets um private stocks uh like being being tokenized and brought onchain and the thousands of meme coins

that we have. if you want to list them all of them into defy protocols especially landing protocols um the current way of do doing this is not scalable enough it's usually one size fits all model where like you pull everything together uh as a user I'm exposed to all those assets so if something bad happen on one asset I don't know x sushi or whatever the asset then I'm exposed to that and and can be drained and it requires a lot of m maintenance which is something that uh it has is at odds with uh defy promise.

So we've passed uh yeah the we spent the last two years like just defining how we solve all those problems in the defy space to make reliable and and and uh resilient defy protocols. So the real question is how do we scale safely uh the defy space? So I don't know if you've heard about the Swiss cheese model. Um so the Swiss cheese model of security is about having many layers. Um so like a Swiss cheese uh layer of um of security of obviously the Swiss cheese Swiss cheese have like hole in in those. So each layer has like

some uh some drawbacks but if you add them add enough of them at some point you don't have like any uh security problems or at least you have reduced them uh by a lot. This is a good good way to reduce uh smart contract risk risk uh economic risk etc. So of course you need to do it. We have a we have built a security framework at MOF that we've shared in our blog. So if it's interested for you, you can have a check. But this is not enough. Um the the the real problem is at the very very beginning which is about how do we design uh better protocols in general and this part is particularly underrated

into the space and why we think this is the the critical one. So we have built some sort of like a framework or design principles to build defy protocols that scale and reduce the security uh security risk. The f the third aspect is having uh governance minimize protocols. Uh so not trying to have everything that is uh powered by the governance that is decentralized etc. In fact, the the best governance that you can have is just no governance at all and just automated piece of code that is triggered and the logic uh cannot change. So reducing governance just uh lower the

the overhead uh maintenance reduce the attack surface. There were many hacks with like um governance that that were taken over by by your large wells. I think you have um heard about was it bumpy? No, I don't know. He he hacked like a compound uh compound fork and then try to to do it uh uh with compound uh and also minimizing governance just bring more productivity for users because they don't fear to have the governance changing risk parameters or upgrading contract for the anecdotes um because we were building on top of a compound there were a lot of um time where they they were changing the risk

parameters or upgrading the uh the smart contract and changing parameters was like very challenging as an integrator of those protocols because that what that was changing the behavior of the underlying protocol and and thus affecting ours and even sometimes like blocking it uh which was proved to be um challenging. So good example of those uh protocol that are like following that uh that design principle uh liquidity uh unis swap I mean unis swap you just just can change the fee and that's it uh mofo v1 is the same um you just need to I mean uh for the mofo governance v1 you can only uh

uh change the fee and add interest rate model to the protocol but you can't change uh the behavior of a specific speific specific markets. So first point minimize governance as much as possible. The second one which is a bit related is immutability. If your smart contract is fully immutable that means that you have uh that it's completely trustless uh you have more predictability as an integrator. So if I integrate a smart contract and it's fully immutable I know that the logic won't change anytime soon. I mean it will never change. And um again I have an anecdote on that at some point once uh smart contract uh that we were like on top of it. They

upgraded the smart contract and it changed the interface. Changing the interface of a smart contract is basically the worst thing that you can do because it it just breaks the whole integration. So people were locked in. I mean integrators not just us but all other integrators using those function that I had changed they were locked in and they could not withdraw their funds. So I mean upgradability is like an anti pattern. I mean if if one layer is upgradeable every layer on top must be upgradable.

So having immutable smart contract is a great way to have to bring more interoperability in the space and more predictability. Good example again, liquidity, unis swap, mofo, they all immutable, so easy to integrate. You know the logic um and that you won't be surprised at midnight on a Saturday uh that uh someone has upgraded the smart contracts. A third point is risk isolation. So this is an important topic especially if you want to have like a scalable protocols. Um at Mofo we have bring that we've coined that term which is uh the creator term.

Uh many protocols before MOO were kind of like a one sizefits-all model where every asset were pulled into one place and as a user I was exposed to that uh to all those assets. So you have basically you targeting just one risk profile while risk is a continuum. you have low risk to very high risk and so low rewards, low yield to very high yield, but it's continuum. So if you have like one one point one target, you're just missing all the others. And it's es especially critical in in in if you're bullish defy as I said earlier I mean there will be million millions of assets million millions of users even

billions and they all are like different uh in in in shape and like behavior and so they want uh different uh access to different risk profile uh service and isolating risk is a good way to provide that to end user because That mean that if some some happens on very high-risk uh assets, risky assets, it won't affect the one that are just searching for low risk, low rewards asset. So I mean separating the the the uh the risk uh isolating the risk and separating the risk management from the accounting allows you to bring like more competition uh more uh target more ris

uh on top of your protocol. Good example are Melo, Symbiotic, Mofo. You have a just an example of Melo um with their LRTs. Um so you have like some sort of uh LTS that are targeting different networks and those networks may may have like different risk proise. Um so you can have like a very maybe the the one LT1 is super risky but the LT3 is is low risk. So as an investor or user I might choose u el one or three depending on my prof profile.

A very important topic is minimalism. Uh this one is super super important. Uh we see many builders trying to build everything into them to their protocol like a deex plus a landing plus I don't know fixed rate plus viable plus whatever. And at the end of the day, it's just like increasing the number of lines and increasing the the the attack surface and you end up with thousands of lines of code that are totally open source and deploy on smart contra deploy on chain and with billions and of assets. Of course, it's creating a big honey pot for hackers and it's very very risky. So on our side what we our core uh thinking about is is you do

just one thing but you do it perfectly and then I mean you have few example unis swap v2 is super simple super simple not it has not been hacked it's still it's still used today and then morpho v1 650 lines of code 7 billions of t total deposit on it it's I mean it you can read the it's like reading an article if you read the code and the thing that you can't do in your protocol because you have removed all the uh unnecessary features that you don't don't care about then all the rest you externalize and uh you let other people to build on top what uh on top the missing uh the missing pieces. So

for instance dexes uh you can like on top of like dex primitive you could create limit orders oracles you swam etc. But it's just like a simpler protocol on top of it that is reusing the infrastructure layer. Um this way you isolate the risk and also you can the builders can concentrate on doing the the the just the thing that they want to to build. Um for lending you can have like a leverage or um like some strategy of fixed rate on top of variable rate on top of it. Uh so and um and and and this way also you bring more competition, you bring more uh creativity into your protocol because

you are not the one deciding on what should be built but people on top of it and builders and users will decide organically of what what works and uh what makes sense. Good example as well unis swap on top of it. Um I mean unis swap is not building all the hooks but Benv2 I aris they are the one building those hooks and uh are the one building on top the of that dex infrastructure layer and they are really really focused on their core business and unis swap has not does not have to worry about like building all the those hooks inside the unis swap protocol

uh and for mofo at is the v1 uh we we didn't have fixed rate but you had delve tenor pone that were proposing uh fixed rate on top of m so that's basically the the uh the design principle that we recommend for any builders in the space uh to create safe and scalable D5 protocols which is I think something that builders and uh should come back and should focus on if we really want to uh bring the whole financial system on chain. So, but obviously you don't have to trust me. Uh you can just check what other protocol that works and the one

that will last for years and then and ver verify by yourself what I've said. Any questions? How do you think about um 10 years down the line with some with the the immutability? So, you know, how do you take into consideration use cases um that may not necessarily be obvious to you right now?

Yeah, sure. I I said that protocol should be immutable. That does not mean you stop innovating. So, you can still deploy another another protocol. It's just that I think it should be more optin. I mean you you shouldn't force people to um use the new logic and it it should rather being um people migrating from one instance of an immutable protocol to another instance. Then comes the complexity of how do you migrate those users? And I think uh this is where you need to think about like how do I migrate those users and and and build the missing blocks that ease that um that transition from the previous

protocol to the new one and and make it as seamless as possible or like abstract it as uh as much as possible. Um but I don't think you should p uh push users to to use the and force users to use the new instance. Hello, thank you for the presentation. I had a question. Um, smart contracts for DeFi are often particularly complicated compared to other use cases. And I guess that's one of the reasons protocols often leave them upgradeable because they're just afraid something might

happen one day. Do you have like um um how do you say uh tips on um of rules that might give protocols confidence like now we are ready to make our protocols? It's exactly the point of minimalism is there's too much things in the the smart contract. If you deploy that you're not comfortable like uh uh about the the safety of your protocol that means that there's something that you've missed and and you need either to do some more security audits or uh stuff like that or just remove features because um I mean many protocol builders are putting a lot of features into their protocol that end

up not being used and I think this is a mistake and they ra they rather do less and maybe incorporate that into the next version than trying to put everything. I mean, we're not talking about a software uh we're not Airbnb or uh where you can ship features every day whenever user wants. I mean, it's like just like financial infrastructure uh that where billions or even like trillions will flow at some point. So, it's very different. People should have like a very different mindset when they build that.

Thank you. Thank you very much. Hi, thank you very much for the presentation was really nice. Um, still on the same topic I would say like our vision here of uh immutability is that it is kind of a tradeoff between uh risk and efficiency. You quickly mentioned that um that people need to find solution to uh migrate you know liquidity whatsoever but you know upgradability allows this to do

it like seamlessly. So it's like a risk but at the same time it's helping for yeah migration of liquidity you know if there's an incident you mean um not only like imagine you want to add a new feature for instance let's take uh unisoft v4 hooks if you want to create a new feature uh you currently have to deploy a new hook um attach it to a new pool and uh yeah this creates two pools for the for the same token pair Whereas if you had an upgradeable hook, uh you could just uh you know combine those two features.

That's true. This this is a trade-off. Um, also I agree that some uh from time to time like it's not possible to have everything immutable and sometimes you're forced to have upgradeable smart contract and I agree we we do have the token that is upgradeable uh because we want it to to be future proof and migrating user in that case is super annoying. Um but uh but in general I think we're doing too many upgradable smart contract than u immutable ones. So I think we have like a not the wrong bias u not the right bias right now.

[Applause]