Understanding ERC-4626 and ERC-7540 Tokenized Vaults in DeFi

[00:00:02]So my topic of presentation is tokenized vault and here we would basically see uh why do we need uh vaults and what are the basically standards for the vaults and how we can scale them.

[00:00:16]If you look at the agenda for for the complete talk so it is going to be like this basically first would be uh the need of the RC standards for WS. Then we have two different ERC's over here. uh first is ERC 4626 which is very much popular a lot of protocols are using it so uh a lot of you might already be familiar familiar with it and the second one is the RCN 540 which is basically uh scaled version of ERC 4626 for a specific reason and we'll look into that and uh then we'll look into the methods of these ERC's and we will have one case studies uh for both of these CRC's basically Okay. So first thing first like why do we need ERC standards right? So when defy bmed right we had different protocols unis swap a compound right and uh those are protocols were basically uh giving the users receip tokens or LP tokens as a proof of deposit right or or lending. So and we have different protocols which basically integrate these protocols in their own protocol right. So when we have different protocols and uh they don't follow some kind of a standard right integration becomes very difficult. So one of the main purpose of having ERC standards for vaults is like having a integration mechanism available or in integration interface available for for different protocols so that the integration effort is much lower and we can also develop uh more consistent and robust e-wearing vaults basically so that uh because unis swap aren compound they have very different implementations and each and every protocol which basically integrated with these protocols has to go through different interfaces and work according to them right but since the arrival of let's say RC 4626 uh it's pretty much standard so something similar to RC20 that we have right now so the first uh question why we need it it's basically to have a lower integration effort from the world side okay so first we start with the RC 4626 right so it's um as as you already talked about it like it's a standard for tokenized w And it's mainly used for lending markets um aggregators and we can like for example eat bearing tokens right we can use it for all these uh different kind of protocols and this particular ERC inherits ERC20 so it's uh ERC20 token but it has some different methods added to it which makes it different from the ERC20 and ERC20 tokens basically here they represent shares shares are the vault right and the methods that are added on top of it are like deposit, mint, max mint, withdraw and some other matches which we'll talk about later.

[00:03:06]And why do we basically uh like uh have this way of of like for for the standard. So for example, let's talk about a scenario uh like we have a vault and 10 different people deposit uh USDC to it like 10 USDC every person, right?

[00:03:23]And those 100 USDC uh is being you know deposited to some other platform to earn some yield or some rewards something like that right and when those rewards are returned back to the wallet uh we need we have to distribute that reward to each and every user right who participated or deposited in this particular wallet. Now to manage the um you know the how how do we redistribute the yield that we earned we can do it uh like in two different ways. One way would be like we can keep separate record for each and every user. Okay, this user deposited this much and earned this much. So we'll give them back this much. Right? This can go on for like 10 users. Okay, but what if what if they are like 100 users, thousands users, right? Then it will be very expensive gas wise, right? So to basically mitigate this situation of you know not having such gas uh expensive operations uh ERC 4626 basically makes it easy for us to just update two or two or three values right what is the total deposit what is the total asset what is the total shares minted right these two or three things makes it very easy for us to calculate okay what is the share worth and how much is in every user is going to get from the yield that has been accumulated over the time right So yeah, ERC 4626 basically make it really gas efficient for everyone's uh shares and uh yeah it is one of the advantage of having this particular uh ERC.

[00:04:49]So there are different uh implementation for this ERC and we have one from open zeppin and we have one from um solidity we have from strollmate. uh they have few differences like uh in terms of gas optimization and stuff like that but basically the standard is going to be same they will have uh the same methods uh yeah and if we talk about the highle uh workflow of the RC 462 6 vault so it it will be like this so there will be user who will deposit and they will get some shares right those shares will be minted to them and the same user can basically later on redeem their shares and they will get back the assets that they deposited plus some yield and from where they're getting these yield. The vault basically deposited those asset to some yield strategy. For example, uh let say we developed a vault and that wa deposited all those funds or lend all those funds to a right and after some time we will uh like uh have some rewards at a right we can claim it back to our world and reward our users. So e is written and that is what's written back to users uh upon redeem assets plus yield. So this is the highle uh workflow of vault. But how does that happen? Uh this basically uh two there basically two different methods for that like uh which we use. First is like deposit flow and the second would be the withdraw for this.

[00:06:21]So yeah so if we let's say have a contract which says that it implemented ERC 4626. So how would we know like which particular asset is being deposited over here or which asset is being uh redeemed. So we simply have a method called asset and we can check it from there. Right? And how will I use a deposit? There will be two different methods deposit and mint. So you can either go for the deposit method or the mint. The difference is like if you go for deposit you basically choose how many asset you are going to deposit and the shares are minted uh basically calculated or depending upon the amount that you have deposited and sent to you right if you'll go for mint you basically um choose how many shares you want to mint right and then on on based on that uh the assets will be calculated and that many assets with vault so um I mean you have some methods um preview methods basically to calculate the share shares and the assets beforehand to you know before you can deposit or a mint.

[00:07:20]So we have the preview deposit and preview mint basically for that and finally we have convert to shares. Uh the conver is the underlying method which basically helps preview deposit and preview mint to you know calculate shares or calculate assets whatever user wants to uh deposit in this case. So next we have the withdraw flow and method. So in here okay so let's say a user deposit right now how will the user know how many shares they got so they have the simple method of m balance of right they can use this method and check okay these many shares they got or the total shares that they have at the moment right and if they want to redeem those shares or withdraw some amount they can basically use two methods um method withdraw where they will specify how many amounts of assets they wants to withdraw and the shares will be calculated on basis of that and burned or they can go for the redium method where they can specify the shares like okay I want to burn these many shares and they can get assets based on that.

[00:08:15]Similar to deposit we have two different preview methods where uh we can basically you know uh beforehand check okay how many shares will have to burn or how many assets will I get if I burn these many shares. These methods are preview withdraw and preview redeem and uh the method which basically help these methods to calculate is convert to assets. It is the underlying method.

[00:08:37]So we talked about two different methods deposit uh two different flows in I would say deposit and withdraw in RC 426 and this is the highle view of the RC 4626.

[00:08:49]So if you like there are different methods many more methods in here u but we like saw most of them and we can see okay how many methods how many of these methods will change the state and how many of these methods are just few methods. So moving on we have the case study for the ER 4626 max API. Okay. So what is max API? Uh basically a vault. I mean we just discussed like one standard for vault right. So this particular protocol uh uses that ERC 4626 um standard to implement the world. But uh they have like uh different yield strategies integrations like many E strategies integrations which uh basically boost the uh yield or the rewards for the users right. So they have two different vaults uh one with ETH and one with USDC. So basically in one of the vault user will deposit ETH and those ETH will be further deposited to some uh 10 or 20 different uh protocols and from all those protocols uh the this particular maxipy vault will get the yield and redistribute to user.

[00:10:00]Similarly for the USBC they're deployed on multiple chain and uh if I if you look at one of their particular strategy over here so if you see over here like uh can you identify um what is the world what is the asset and what are the strategies over here right so yeah uh I think you might have already guessed it but yeah uh here w USDC these are the assets for that particular vault and uh we have the first wa is Ethereum ETH that is one W and Ethereum USDC I mean deployed this particular wault is deployed on Ethereum and the asset is USDC and these are the strategies convex similar yarn right these are the different strategies where um the uses deposited asset is further distributed for yields so we have you know four different balls over here on two different chains and uh I mean right now we only see convex right But uh if I remember correctly they have like four or five different uh sub subs basically in convex itself right so it's it's not just one yield strategy it's like four or five inside convex and similarly for similar so yeah it was a lot of um strategies to manage but uh yeah basically ERC 4626 allows it very easily for users to uh you know uh integrate with different protocols u and yeah and manage the yield and redistribute to redistribute to users very easily.

[00:11:34]So I think that is it uh for ERC 4626 and uh yeah now ERC 7540. So Yassi 4626 was uh the basic one right quite popular everyone knows it uh and being used around a lot right the next one ERC 57540 here is basically for one reason that ERC 4626 doesn't right it is atomic deposit and redemption so what do I mean by that so ERC 4626 basically forces a user to deposit some assets and get some shares and that's it Right? And when they want to withdraw or redeem, burn their shares and get back the assets.

[00:12:19]That's it. But what if there's a scenario where user deposits but doesn't want to wait for the share that is maintained, right? Uh I mean the share can be maintained later on or based on some other uh situation, right? For example, crosschain lending, right? A user deposits some fund on Ethereum and uh those funds get transferred to base or polygon or arbitum and based on those you know uh depositions shares are minted and given back to users again on the Ethereum side. If what if what if like this is the flow that user I mean the protocol provides and user likes it right or user wants it. So in case of crosschain lending or let's say RW assets where uh finalization you know takes time or some kind of unculturized loans uh in these scenarios uh atomic deposit or redemption doesn't work you know uh we want a system where there could be some waiting period involved where uh the user deposits and when the shares are made right so for that systems we basically have ERC 7540 similar to like ERC 4626 is an extension of uh we can't say extension of basically it builds on top of ERC20 uh but in this case ERC 7540 is is an extension of ERC 4626 but what it does different is uh a synchronous deposit and redemptions and how does it do it uh it is done using something called request so what is a request right so uh a request is basically basically the start of a deposit or a start of a withdrawal. So a user is going on the platform or on the protocol and starts the deposit process by depositing some assets or starts the withdrawal process by burning some shares. Right? This is how a request starts. Whereas in ERC 4626 uh those shares are burned and the assets are returned to the user in the same transactions and or in case of deposit uh the depos the assets are deposited and shares are minted for the user in the same transaction. In case of 755 7540 when a request is made the state of you know the request is in pending so yet no shares are minted for the users or no shares are burnt for the user right. So the request is in pending state. Now the protocol process that state uh based upon the code logic or howsoever the protocol wants to process it. the state will go into claimable state, right? And when the state is in claimable request state, then the user can go back and basically claim it. And once the user has claimed it, it will be in claimed state and that will be the final of the you know either the deposit flow or the withdraw flow. So as we can see it already, it's not atomic, it's you know async in in case of deposit and withdraw flow.

[00:15:21]So if let's say a protocol has um implemented ERC number 40 it should have these things for sure. First thing like either deposit or retention has to be a synchronous. It's not like they have to they have to have both of them are synchronous. They can have either of them asynchronous but if none of them are asynchronous it's just basically ERC 4626 right we don't need ERC 7540 in that case. Okay. And if uh they have gone for async deposit what should happen like when the user deposits on mint. So in the deposit method it should not transfer the assets the transfer of assets should happen in the request only. So as we saw earlier like when a request starts the uh asset is deposited but shares are not meanted right.

[00:16:10]Similarly in the deposit method there will be no transfer of assets and similarly for withdraw like there will be no transfer of shares to revolt it will happen in the request itself now we'll look at the um deposit flow uh and and the methods related to it right so how would you create a deposit um I talked about it earlier we go with that request deposit method we mentioned how many assets we want to deposit who will be the controller of these assets and who is the owner, right? From where the asset is going to be deducted, right?

[00:16:43]So, anyone who calls this method, um the asset will be transferred from owner to the vault and the request will be in pending state, right? And this request will be in pending state until uh the vault somehow puts into you know claimable state. It will depend upon the logic of the vault. And once that is uh done the request is in claimable uh state the controller can finally come and call the deposit um or mint method and basically claim the shares that were minted for that particular controller and finally the request will be in claimed state. So anytime you want to check you know what is the uh pending deposit request amount or let's say what is the claimable deposit request amount we have these different methods for that particular reason. similar to deposit with the withdraw if you see um we have uh request redeem method. So when we have request redeem method what basically happens is like uh the user mentions the amount of shares that they want to burn uh the controller and the owner right and the shares are transferred from in in the request redeem method only the shares are you know transferred from the owner to the vault and again the vault process that particular request and make that into the clim and finally the controller can uh call the redeem or withdraw method to you know receive back the assets for the share that burn earlier and at any time we want to see uh you know the pending redeemed request how much is it how many shares are pending yet to be redeemed or or how many shares are in the clamable state we have these different methods to check it okay uh just in the diagram uh the same thing that I talked about uh user calls request deposit and sends asset and uh then deposit pending basically wall process that particular pending deposit puts it in claimable state and finally user can come and claim the shares. So in deposit requests are sent in the request deposit method and the shares are claimed in the deposit method and similar in in in the redeem process request withdraw basically logs the shares and finally in the redeem or withdraw atlet user gets back their assets and that's the two different methods and you know um there could be sufficient uh amount of time difference between these two methods and one cannot guarantee how many shares the user is going to get for uh depositing certain amount or how many uh amount they are going to get for burning a certain amount of shares right it depends upon the situation different situation the market is in so yeah um similar to maxi we have a different protocol called metaw and they uh they are built on ERC 7540 and what they do is basically they allow crosschain aggregation so maxpy uh that used ERC C4626 they were limited to one particular chain for the yield aggregation but ERC540 allows uh this particular protocol to aggregate yield over crosschain. So for example um someone can deposit uh USDC on base chain right but those USDC can later get uh later on get invested on polygon or optimism or ethereum right and uh rewards can be accumulated and finally they can be you know uh on base chain and given back to the users. So ERIC 7540 basically allows this to be done. So they are deployed on seven different chains. I mean the single protocol is on seven different chains. It's not like we have different contracts deployed on different chains.

[00:20:24]It's the same protocol managing on seven different chains. And again they have two different vaults ETH and USDC1 as the assets.

[00:20:33]And for the crosschain operations they use superform protocol. So superform is another yet very popular protocol which already allows crosschain operations.

[00:20:44]But uh this protocol basically uses their um investment and divestment and liquidation procedures to help uh ER540 to invest or diverse to liquidate uh crosschain.

[00:20:58]So if you look at the metaw deposit flow um as I as we talked earlier right over here like it um for a protocol which implements ERC40 they can have one or both uh as asynchronous either deposit or redemption right. So it's for metawwards follow something similar it has two different methods for request deposit and deposit but whenever a user deposits they basically use multi call and it seems like um a single transaction for for from the user's perspective and there is no nothing a sync from the user side so a user deposits to the meta vault and they get back their shares in the same transactions so for them it will seem like a ERC 4626 operation But uh the vault implements two different methods but not using it from from the perspective of ER7540 yet. But when we go to the withdraw flow uh this is where it becomes a bit tricky and this is where the you know proper use of ER7540 is here. Um so let's say if I I'm not sure if it's clear but we'll start from the first bar over here user right.

[00:22:10]So a user uh request for uh redeem for some particular shares. So those shares are logged in the metawart. It can either be logged or it can be burned. Uh the ERC basically recommends to burn it.

[00:22:25]And in case the request redeem fails, we have to remint it for the users, right?

[00:22:32]In case it fails. So it can be logged or burned. And uh once that is done the vault checks if the vault has enough funds to you know fulfill the uh predeem request for the user. If it has if it has enough assets it will put the request in plumbable and the user basically can call the DDM method and everything will be done there only.

[00:22:54]Right? But let's say the wall doesn't have enough assets. Right? User requested for $1,000. The vault has $400. So now Walt will have to request a redeem, a crosschain redeem basically in this case for $600.

[00:23:09]So how did that happen? Okay, so Walt will basically create a pending redeem request. Now uh this request will be in some kind of queue which a delayer will later on will you know check and process this redeem request. It will basically call the ER7540 engine and this engine will initiate the crosschain withdrawal. So it will basically call the superform gateway and this gateway uh will call the another chain and send all the withdrawal request and everything and crosschain vaults will basically return the assets to the superform gateway and from the superform gateway it will be returned to the meta. Now metawol will check again if it has enough assets to return to the user. Um and if there is enough assets then it will update the request from request to claimable. And now user upon seeing okay they can now uh redeem because there is request is inflammable they can go for it.

[00:24:14]And uh uh yeah on redeem they will get back the assets and their shares will be burnt. In case this fails, uh the users shares are minted again or given back to the users. Uh so the counting is not wrong. So this is how the complete withdraw flow works for the metaw and uh it is async in nature. Whereas the deposit which is implemented implemented in the async way but is not actually you know doing that because using multi call we can do it in one particular transaction but for the redeem in case not enough assets are present in the vault it has to be in the async way and it is it is happening because of the RC540 right ERC 4626 won't be able to do it won't allow it so if we basically check you know for the difference between ERC 4626 the major one is you know in RC 4626 there is instant deposit of withdrawal that we have to go for 75 40 we have the async one right there there are no states in RC 4626 here we go from pending to permeable to claimed and so some other difference that we have already talked about um yeah uh definitely 7540 is much more complex uh requires much more gas and uh this share calculation is not you know fixed in ERC 7540 so a user you know might get u less assets or less shares than they are expecting. Um still we we have um you know um slippage control over here so that users are not getting uh you know completely rugged in this particular scenario but uh the amount of shares or the amount of assets that they're going to get changes you know and it's basically decided the claim time. So, and uh yeah, uh these were the main differences between the RC4626 and the RC540.