New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

Superform đź›  Tokenized Vault Standards

ETHGlobalWed, Oct 9, 2024, 12:00 AM

Join Vikram Arun from Superform, for a workshop titled, “Tokenized Vault Standards.” Come learn about the next evolution in DeFi being propelled by usage of vault standards, notably synchronous vaults (ERC-4626) and asynchronous vaults (ERC-7540). This workshop is part of Superhack 2024, an online virtual hackathon taking place Aug. 2 -16, 2024 with over $200,000 in prizes! For more information: ---------------- Follow us: x.com/ethglobal Website: https://ethglobal.com Email us at: hello@ethglobal.com

Transcript

[Music] uh hey everyone and welcome to Super a workshop titled tokenized wall standards joining us today is Vikram who will be taking us through this session and with that I'll pass it over to viam to get the workshop start over to you vam thanks Calvin um yeah excited to do this with you guys um lots of interesting developments in defi over the last few years and I think tokenized vaults are one of the cooler things there um so excited to talk about that with you guys and uh yeah any point during this it's meant to be interactive Workshop so feel free to just drop questions in the chat and I'll like be reading it um try to read it and 'll see how it goes okay cool um let me share so I have a deck that I put together this will be maybe more on the technical side but hopefully it's helpful for people who have been uh really getting into it um let me make sure this is like shared properly okay uh can you guys see just the screen just the slides yeah yeah good I can see everything okay great um so yeah I'm I'm I'm vicrum I'm uh one of the co-founders of super form and I've been contributing at the ERC 4626 Alliance um and recently uh we've had a lot of tokenized Vault standards that have that have been approved and just kind of wanted to talk to you guys about those and uh you know what they are and how to actually build on top of them and um some useful tips that we've gained from our from my experiences um at superform and just generally with working with protocols in the defi space um so yeah what we'll talk about in this Workshop is first off you guys have probably heard the name like tokenized vaults 100 times now like first we'll cover like what those refer to um and then we'll talk about two of the most popular um tokenized vaults out there right now 4626 and then one which was approved um last month for called 7540 and then we'll run into some development tips and considerations and then we'll open it up for Q&A but as I said feel free to drop things in the chat and I'll try and and take a look if there are any questions that come up in the meantime all right so if we think back to what defi is trying to do it's really allowing people to make money efficient I can use Smart contracts to be able to put money in and get money out uh and before blockchains would really only be able to be used for actually like storing and and moving value but with defi whenever defi came around a few years ago we pretty much said that's actually storing and moving it is only one tiny bit of what money is let's figure out how we can make money permissionless and that idea of putting money into something having it make money and then returning more money out is pretty much what these tokenized vaults are trying to tackle is we're trying to standardize this arbitrary money-making logic um and in doing so it's I think it's solving some of the the biggest issues that def5 faces right now and in scaling which is that uh dii generally has a lot of ways to improve on the security side for the amount of tvl it has for sure you know we can we can be doing a better job there and increasing composability and also once we solve those first two things that makes a lot easier for us to safely and fast and be fast with uh how we're innovating so that's kind of why it's important um but a little bit more on exactly where tokenized vaults fit into this is it pretty much makes it standardizes that arbitrary money-making logic into a tokenized vault and I'm actually not sure if I like start moving my cursor around can you guys see that on the screen yeah yeah I can from here you can see um so yeah uh tokenized vaults there's really two flavors of them one is a synchronous Vault and one's an asynchronous Vault um synchronous vaults is RC 4626 and there's now over9 billion of TBL in it um we have yield aggregators lenders um automated strategies now that that are built on top of 4626 very basically how a tokenized vault would work is that money comes into the Vault through deposit or mint and then it leaves the Vault through redeem or withdraw and these are you know totally synchronous actions um users would be able to transfer assets to get shares and then shares to get assets all that stuff is you know you can see all that stuff happen on chain now ERC 462 is particularly relevant for your typical D5 Vault right things that um can exist totally on chain but as we you know as dii grows up and it matures and we're trying to bring a bunch of assets that have never been able to be on chain on chain we have to be able to provide some sort of asynchronous support um so that you know I actually might need to do kyc before I can enter a vault or I you know maybe the asset that I'm investing in is in the real world and to actually get my money out I have to like go to custodian and then like go to a bank and and then like it gets transferred on chain and there's a whole process right around how I actually like would get my my money back um so 7540 pretty much takes what 4626 built that core infrastructure and it just adds this request life cycle on top where pretty much to get money into a vault you first have to request a deposit and then once your once your request is approved then your money goes into the Vault and then to get money out you have to request a Redemption and then the The Vault will fulfill it and then you'll get money back um so very basically these are like the two things that are going to serve the backbone of like any sort of tokenized Vault strategy or anything in defi really can be um can be put on either of these two standards at at this point and there are a couple other like supplementary things that we'll talk about later that that help but um these are really the the two building blocks that we have for being able to support all kinds of uh yield on chain so we'll talk a little bit about USC 466 first and then we'll jump into like the new stuff on Sony 540 um but just to like cover the barebones of how vaults generally work um is I mentioned this before but money comes in through deposit mint leave through redeema draw we'll talk about how money comes into vaults and then we'll talk about how money leaves vaults and then just like some other important functions that uh that you should know are present in the standard so getting money into vaults always starts with the underlying asset that the Vault accepts so you can think of that that's just you know whatever usgc die um if you want to use native asset you can also use that um but we take a look at there's another standard 7530 35 which which does that but an asset can be anything really um and there's two ways that you can get money in the first is a market order which is just normal deposit so I'm pretty much coming up to the Vault and I'm saying hey hey I have 100 usdc and I'm looking to get however many assets however many shares that you can possibly get me market order um and then there's a condition here where I want to make sure that the amount of assets that I'm depositing it can't be greater than what the vault is set to be the max deposit vaults will want to implement Max deposit for multiple reasons maybe there's a vault cap whatever else they want to make sure that you know their yields don't get diluted whatever uh so vault's can Implement Max deposit on a per user actually so like they could Implement that hey every user can only deposit 100,000 usdc or whatever um preview deposit is something that's used to figure out how many shares should be received for assets that are being deposited um so these two conditions first the amount of assets that you're depositing has to be less than Max deposit and the amount that you're of shares that you're going to get back should be the bare minimum of shares that you've actually received so this is really just like the preview deposit is a lower bound so the users know front ends everything um what the execution expectation is for for a given action and then assuming that condition passes then we have effectively swapped assets for shares and then we emit the deposit event um on the flip side we have another way to get shares which is uh a limit order where we just say hey I have um I have this usdc in my wallet but I just want to get 100 shares now you know how many assets do I need to actually do that that so um really like this is like a fixed order this is um variable and the two conditions here are I want to make sure that the Vault that the amount of shares that I'm asking for is lower than what I'm uh than the maximum amount that the user is allowed to Mint and then similarly to the preview deposit and share check we have an asset check compared to preview mint where um I just want to make sure that the amount of assets that I'm minting for that the amount of assets taken out of my wallet is less than what was indicated through preview mint so it's just like the lower Bound for for user security um and after that successful then we emit the deposit event similarly um I guess couple notes uh assets should just be one erc20 token I mentioned in the very beginning like if you want to use native assets check out 7535 if you want to use multiple assets for an underlying check out 7575 um and that's how you be support you know like double-sided LP or or whatever um if you wanted to have different different ways to get into a vault uh some other things if a vault can't be deposited into that's how that's where we use the Max and preview functions um so max functions should be on a per user level and then preview deposit is on a broad anybody should be able to call preview functions and then see how many assets I'm going to get um and yeah yeah uh whenever we deposit it should return exactly what the return type is um the return amount back to uh back to the receiver whoever was asking for for shares and some rounding things here and everything like we've encountered some of like the St vaults and stuff which on Leo just like you know be careful of like some rounding things on that and uh you'll be golden so that's getting money into vaults getting money out of vaults is really very similar um but we replace deposit with redeem which is the market order here and then withdraw which is limit order a little bit confusing I know because you know you typically think of deposit and withdraw being anms but in 4626 case it's redeem um so pretty much the same conditions apply you know shares we're asking that it has to be less than the max preview redeem again is used as as a lower bound um again so that users don't feel like they got rugged when with drawing from a vault because you know preview functions should tell them like the least amount of basses they should receive so so they have an idea uh and then same one withd draw really except we use the preview and Max withd draw instead of R um some edge cases here to keep in mind is many vaults have implemented like time lock Behavior Uh even defi ones right it's like I don't know maybe it's trunch product or there's like some collateral thing and you have to like call it back or whatever and you have to like you know cool it down like Athena is actually a great example of this Athena has totally synchronous deposit steps but then on withdrawals they have it so that there's a cool down period you have to like request a cool down of shares um if you do that we'll talk more about 7540 and how that can be used natively but in the context of 70 of uh 4626 if a user is time locked then the correct Behavior which all these vaults have implemented is to just have you know your max functions and preview functions return zero and yeah um that's pretty much it for like the core flow how 4626 Works uh some other functions you know it inherits stuff from rc20 so like every 4626 is also an erc20 and then we have a bunch of functions in 4626 to do your typical like math calculations we have total assets convert shares pretty much you can get tvl and apy and everything directly from those uh just be careful in like using these things on chain I would you know be just like a little bit wary on because some of these as some of these numbers could definitely be be spoofed uh and you know for for the focus of like how do we display apy on and and like Vault details would generally gravitate toward using total assets and total Supply rather than the convert functions but that's a nuance and you know for hackers listening to this you're probably focused on the protocols so that's probably probably good here um yeah I mean just general recap um preview functions or simulations Max functions constraints convert functions or price in generally just remember that and there's no slipage parameters in core functions so generally in depositing to 466 Vault we recommend going through a router uh but that's you know separate from the actual like security concerns that that a vault would need to address per se uh yeah all right uh now for some uh for some new stuff here we'll talk about 7540 um which is uh again proved a few weeks ago and there's not too much stuff out there outside of the spec so hope that Um this can be a good resource and uh yeah um generally the reason why we why we built 7540 was because there are lot of vaults on 4626 that uh we had to introduce some sort of asynchronous capability to actually be able to bring um more types of yield on chain and that happens by essentially creating a request cycle for each action for each deposit each Redemption um and we'll have a note here is that 7540 um you don't have to implement both request deposit and request redeem you could just Implement one or the other and we have EIP 165 support so that you can actually like indicate you know is it just asynchronous this way is it just asynchronous on redeem we are expecting like you know most Vault would probably just request just implement the request redeem section U but request deposit could be important too for lots of assets that you don't you know maybe it's capped or whatever and you don't necessarily know whenever whenever you're submitting assets on chain um and then just a note here is that 7540 there's something called request IDs we're just going to be covering request ID of zero cases and for anyone hacking on 7540 for this I'd recommend like just focusing on request ID scenarios because not equal zero is there are just some things there that um honestly the spec uh would need to write another spec uh for properly handling that and there's just other things to consider there that probably would be uh could be a rabbit hole to go down so all right um talking about the general request cycle pretty much the tldr is that we have um vaults that cycle from pending to claimable to claimed and to go from each one of those steps there's some action that either the Vault or the user has to take so um it it starts with the user so the user would request a deposit on the request deposit step assets are already sent to the Vault and once assets are sent to the Vault we increment your your pending deposit request so that the vault's pending and then when the vault's in pending um The Vault operator at any time you know imagine this is um um Black Rock right like something in their uh in their logic so that they've been able to actually you know deposit pait your assets into the opportunity they passed all of like your kyc checks whatever that internal fulfillment would then be pushed on chain and then your pending deposit request would go down that was increased here and then your claimable deposit request would increase and then a vault goes fully into the claimable step um whenever a vault's claimable the uh thing that the user would need to do is then actually deposit those claim that claimable deposit request um into the into the Vault um and that deposit step looks like 4626 you know we could go back to like the deposit thing and the same stuff applies for the most part um but there is a a side note here which is that 7540 requires that you overload the deposit function with this added address controller um variable this is needed because again this entire thing is like a two-step process right because the user requests a deposit volter and vter and pending and then it could take an arbitrary amount of time for the vault operator to actually fulfill this it could be dependent on on all kinds of things so in that process to make it easier on the user instead of having the user just sit there monitor this thing like refresh their page for weeks um you can uh delegate and authorize a controller um this could be another protocol it could be an integrator and that integrator can then control your request so that it makes it way easier for the user to actually manage that and to properly support that added ux benefit um we have to overload the deposit function to allow for this address controller to to make that deposit not just the the user or or the receiver um and yeah so after you know the the user or the operator will make this deposit um assets are moved uh they're already in the vault but they're deposited and then your claimable deposit is zeroed out or you know to whatever degree those assets were deposited and then shares are sent back are sent back to the user um and yeah um the general flow here is you know uh we will emit the same events in 4626 we have request deposit events that are emitted on this request deposit step and I guess the big difference compared to 4626 is that um the assets are on the request deposit step as compared to on the deposit step um because the Vault operator needs to be able to at any time pretty much move the assets into the Vault and yeah um notes Here I think already covered this uh so yeah uh really same thing for for the request cycle on redemptions um the only thing here is that there's no overloaded function requ IR ired because redeem and 4626 already supports the additional parameter um and yeah that's pretty much that uh just some notes on 7540 generally you guys probably noticed that uh only request deposit and redeem and request redeem are supported whereas in in 4626 both mint majar here the reason why excuse me um only those are supported is because mint and withdraw remember those go off of like the output asset and in 7540 it's a little bit misleading to make it to request a deposit asking for shares when you have no idea exactly like how many shares the operator would be able to give you and you know imagine takes them like three weeks to fulfill it it's just way cleaner to just go off of the input asset rather than the output asset um and because of that that because of that fact uh in 7540 preview functions must always revert so all those things that we talked about 4626 that redeem all that those should revert because there's really no way for us to tell to create a condition to create a condition on which execution should be reverted so we just say preview functions revert them because that shouldn't be included in execution logic um so you might ask okay how do we actually figure out then how do we show users um how many shares or assets they're going to be getting um that's convert functions are still present 7540 and that's you can use um two side notes on uh other ERC support is that we mandate um erc1 165 so that people integrators can tell if uh either request deposit request regime or implemented and in any case let's say that you know a vault didn't Implement request deposit then it's assumed that that step is 4626 synchronous for integrators and 165 just helps us uh you know figure out where exactly and how that flow should work um and yeah same thing with 7575 uh on the asset uh so we can support multiple assets through 7575 and that's part of part of the spec um some security considerations in creating this um just implicitly in 7540 there's way more trust in the uh on the Vault operator right because pretty much this entire like internal fulfillment step is something that's totally offchain and not standardized so they can do whatever they want like technically if if the Vault operator doesn't move it to claimable you know assets could be stuck in the vault um you'll notice that like we didn't actually have any cancellations that we included in the spec you know obviously feel free to incorporate cancellations and um you know whatever whatever you write but uh the reason why it's not is because you know there's just asynchronous nature of those like sometimes they could be fulfilled and in a bunch of uh edge cases but definitely some something that would be important because uh you know it does it could cause dead assets and similarly still no slippage parameters and uh keep in mind that exchange rates of shares and assets after request deposit could definitely change um so we should don't assume that like the convert functions at the point of request deposit will still exist whenever the B operator actually makes it pable um and then uh so this this uh redeem step or or this deposit step here um don't know there it's twostep for a reason um you know the user controller should be the one who calls deposit or redeem after shares become claimable um if you try and like have some system where that second step isn't incorporated then all of a sudden it gets really hard to track and users or uh protocols whoever is integrating like they end up with assets and shares that they don't know how to push back to users and it's just easier if you know we have it all standardized right being two step and then I already mentioned the request ID equals zero case but pretty much on all these request deposits and request redeems are you can increment request IDs but um far easier to just keep it a zero and use the controller uh parameter to to distinguish uh requests all right so hopefully you guys have a better idea of uh what the standards actually are in terms of building them um there's been a lot of progress on being able to create these better safer um and the toolkit that we recommend right now to build ERC 4626 is what's what ur's done with their tokenized strategies so they've particularly built um this tokenized strategy repo um so that you can just foret modify like three functions in there um pretty much how funds are depl deed how funds are are are withdrawn and harvested and reported um and then that's all you have to do and then you can just simply deploy that rather than like you know you guys actually going through all of this crazy stuff and and uh trying to like figure out how all the math works and and keeping all that straight um so highly recommend just directly checking out what you're interest on in their V3 and it's super easy to deploy um and there's already been a bunch of strategies built on their tokenized strategy repo so link a couple and I think that's in the the hackathon thing now but you can check out the like compound V3 AA Pendle gearbox they already have all the strategies on there and these are great resources for you to take a look for any of the Vault implementations that that uh they're trying to build because this is pretty much exactly you know what the what the haon is for um and then on 7540 side it's far earlier um and the best implementation to take a look at is centeres 7540 but you know you know it's a it's a good it's a really good reference and you know for the brave-hearted that are looking to really be on uh you know The Cutting Edge of of what we're what we're doing on on vaults definitely take a shot um but notably you know there's faress resources um to to do that but we're happy to answer any questions just jump into the 4626 lines uh Channel and obviously I'm happy to I think this is it right yeah um and I'm happy to take any question now that we're now that we're on here so that's it thanks guys thank you Vikram for the great presentation I believe we have few questions on the chat box uh I see one from uh AR you want Big B yeah um what is the question RM okay um can you fine yeah uh that's pretty much it um so this first diagram right this this arbitrary money-making logic is a vault um whoever I want to move money to a strategy or anything and then get money out of a strategy that's it uh a box is a good way U to think of it all right anyone was any questions for yeah we got one questions from supero um Min yeah so it's interesting no uh there's nothing in the specification on a Min deposit uh but you could I mean I guess the benefit of doing it is you could reduce spam to your Evol but I'm not sure if unless you're incurring like a large cost by processing that I think in 4626 would be rare for someone to implement A Min A Min amount but definitely could see that in 7540 and pretty much like a way that A Min amount would be used in 7540 is like you know whenever you request a deposit your request would just be denied if uh if the amount was too small um be interesting yeah and I'm sure there definitely like a lot of that would require investment strategies that would that would be implementing that but haven't seen that in 466 um Carol asks any examples of strategies use cases yeah um I think Center fuge is great um and we'll definitely take a look at their implementation but you know pretty much what Center fug is doing is um there are funds that exist uh offchain that they're looking to get access to onchain capital for so pretty much people will will deposit and then um you know that capital is then uh moved and invested offchain and then users can can monitor like you know the fund and and and the status and everything of that on chain if you were to look to like just make something you know in terms of like in a defi sense lsts and lrts would be great to tackle on 7540 um and honestly like Athena and puffer and uh puffer ether right a lot of a lot of those projects they actually are 4626 and if you guys want to take a look you go to to tv. ERC 4626 doino and a good amount of those vaults actually do Implement um you know some sort of two-step uh Redemption process and that could all be on 7540 and it would be really cool for someone to wrap one of those protocols in 7540 to try that out um NJ asks uh expand a little bit more on the controller yeah good question um so pretty much the controller exists um to make the process easier for the user so the user can I didn't actually include this function but there's a function 7540 where you can set an operator for a request so pretty much the user doesn't want to sit around and and uh monitor when that when this gets to claimable so they can set a controller address they can authorize a controller and this could be a protocol it could be like manager it could be like their friend whoever really um and that person would then manage the request and they'd be able to like actually call that later for the user um yeah hopefully that answered your question U same thing exists on redemptions but that's already 3466 um when the Vault deposits chain asks when the Vault deposits new lending tool how does the Vault token allow the user uh so how it'll know is you can use assuming this is like 4626 it's a normal lending pool um the way that you could tell is because of the preview functions it would tell you how much you're getting out um and yeah the shares are are constantly appreciating with respect to assets so that number is all these charts are only up and that well the lending charts for the 4626 have um so yeah um hope that answered your question um too asks another question hopefully we have more time to take these sorry I just kind of I just kept going uh do we that's okay uh I think yeah yeah I think we have more two minutes and then we can wrap up all right so someone invests $ five it's really up to the user um yeah so the question is like again on the minimum Amounts is like why would a user want to do it uh if it's totally up to a user I think it'd be interesting um if there was like some sort of uh if there are a lot of very small users and deposit into something you could batch those actions that's interesting um which is I guess what you brought up um but I guess that the that' have to happen likely like it would expect batched actions to happen through some sort of uh smart wallet or I'm not sure if that' happen on a vault level it' be some sort of like account level um we absolutely can deposit share tokens as collateral and another Vault and uh yeah um if you're interested in that would take a look um at the 4626 Lin GitHub which I think should be one of the links on our on the hackathon and there's actually someone who used 7575 um to be able to deposit 4626 collateral natively instead of the s20 um so definitely check out the 4626 lines could Hub and like request there um okay uh thank you chain um yeah what type of vaults um so it's whatever you guys want to build it's really it's really open ocean that's why we you know said best uh Vault implantations I didn't really talk too much about super form but um pretty much any of these vaults can be instantly listed on super form and it's a front end for you guys so like never you know for if you're building a new Vault protocol there's no need for you to actually create your own front end you can just focus on on writing strategy that that makes money and then you just put on Super form and you get distribution and once on superform you can actually deposit any asset from any chain too um so we're like chain abstracted Marketplace for this stuff and uh if there was something like a cool Vault um we already talked about a good amount of of uh of things on the 7540 side like the L lsts lrts on the 4626 side um you know I think obviously like you know you guys can can use uh what what Ur laid out as a framework and some of the strategies that would be interesting like there's allot The Leverage strategies that could be written um and you know some of stuff like on gear bcks be cool uh I don't want to like say anything necessarily that would uh you know say like there are a lot of cool things that that can be that can be built um on 4626 so I don't want to like say that just one or two things would be cool but uh just you know we're we're accepting all submissions and you know we're just looking at code quality you know how much the the strategy returns but um primarily just looking for for good ideas and excited to see what you guys come up cool uh thanks a lot for listening everybody and I imagine we're we're probably probably at time so thanks cool I believe this is one of the most uh interactive workshops which I've attended really good back and forth of questions so Che Vikram uh yeah yeah uh big thanks for everyone for joining in and also thank you Vikram for your presentation uh feel free to connect with Vikram in the partner channel on Discord if you have any questions and I believe they shall get back to you whenever they are free uh cheers everyone and have a great uh rest of the weekend see you all bye-bye [Music]

Automatic transcript — names and jargon may be misspelled.