NEP-621: Tokenized Vault Standard on NEAR | Contract Standards Meeting

Captions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.

1. 0:01

   [clears throat] Perfect. So, hello everyone and welcome to a new um contract standard protocol meeting. Today we're going to be discussing NEP 621 uh which is about Oh, I lost the title. Give me one second. Yeah, vault ne. So Edward, I think that you are the one that is uh uh the champion in this in so uh please go ahead explain us a little bit of what it is and yeah the floor is yours.

2. 0:42

   Sounds good. Thanks a lot Jill and um yeah I'm Edward basically working on meteor wallet and then my team is also in this meeting Steve and also way so yeah I'm very happy to present about what we've been doing the past couple months. I'm just going to share my screen if you don't mind and then just quickly go through this NEP. If any of you have any questions, feel free to raise your hand and interrupt. Um then I'm just going to share my screen right now.

3. 1:08

   So yeah, it is NAP61 tokenized for basically we have raised a proposal for a standardized tokenized v interface on protocol and it is basically a near equivalence of ERC 4626. It defines standard V behaviors and interface. I think for us right now the main scope is to make sure we have something that's standardized when it comes to accepting deposit, issuing share token and providing redemptions. So that's the whole scope of of this NEP. We aren't going to go into very detail of the

4. 1:39

   implementation of the NEP but we will try to cover as much as possible in this meeting as well. So the use cases of votes generally cover a few things but on near right now I think the major thing is like for example liquid staking tokens we currently have three LST on near we have an we have um senior and also linear but there's no standardized interface for any of them then we've got

5. 2:02

   landing market like for example the recent one is templ they are sort of like using v infrastructures as well but still there's no standard um interface and then of course onchain capital allocator for view finance and more market. So I do see like for us we have an urgent need to standardize all the interfaces and interactions most importantly to make things more interoperables between different parties. For example when it comes to

6. 2:27

   defy integration when it comes to wallets or maybe when it comes to um just generally comm communicating and making sure partners can easily integrate them. I think there's this need or demand to make sure we standardize them. Now let's just quickly go through the NEP. Um I'm like we mentioned earlier we're not going to go through each of the methods but as we mentioned just now there are like a couple of important things that is basically redemption minting share tokens and also issuing sorry deposits

7. 3:00

   issuing share tokens and also redemptions. So when we categorize the interfaces there is asset information conversion helpers basically helping um users or the developers to convert to shares or from shares to asset amount. Then there's deposit and redemption limits the max deposit u max shares.

8. 3:21

   There is also redemption operations um which is which is redeem preview redeem and withdraw and preview shares deducted from withdraw. Now I think what's interesting is there's no deposit method here which is sort of something that we'll go through later on. That is one of the major differences between NP um 621 and also ERC 4626.

9. 3:46

   Now I think if you go through this NDP you realize there's an example implementation which is a minimal interfaces. So if anyone's keen to see how a void can be implemented you can go through there. There are a few security implications that we've mentioned here as well. There's a few future possibilities for extension as well. So like for example, one of them is to support the intense token or like multi

10. 4:10

    token support which is one of the main thing on near right now. Then there can be multi asset vault extensions basically allowing the vote to accept more than one asset. Right now these standards only defines one asset. And the last thing is asynchronous vote operations which is also available on Ethereum. All of these are possible future extensions that we can further look into. Now coming back to the NDP itself, I think one of the main thing

11. 4:35

    that we have to go through here is the major differences between ERC 4626 and also NP621. The first thing is deposit and minting because on unlike EDM you know deposit and means on near have to go through FD transfer. So we don't have a mean like deposit method instead they have to be embedded into a message and then passed into the FT events. The second part is the nature of near which is asynchronous. So when it comes to certain methods like previewing or max

12. 5:10

    methods, we can guarantee to match actual value and so you know certain in certain conditions or like maybe most of the conditions developers might need to track the total assets internally within the the contract and those are the two major differences between us and um ERC 4626.

13. 5:30

    And I think that is roughly it. If you have any questions, feel free to let me let us know. And then again, if you're keen to go to the NEP, here's a link. I can share the slides later, but it's pretty simple. Thank you. Perfect. Thank you so much. And yeah, I want to double down that uh thank you so much on on on putting the differences between, you know, when one creates an ERC and translates this into an NEP because it's true that most of the time that is most of the things that we have to deal at, right? like uh the fact that

14. 6:01

    you cannot directly translate uh Ethereum world into near world. There are um uh there are many things to take into consideration especially how NEP 141 works and uh the async nature of near and not only on your presentation but also on the NEP. This is very well reflected. So kudos on that and thank you. Um now I think you were one of the uh people uh reviewing the NEP if I remember correctly. Any thoughts on it and you know like what's your idea on

15. 6:34

    you know your stand on like passing or not passing this NP. Yeah. Um so yes I was uh well u yeah the first review reviewer of the of the NAP but uh also I mean um more like from the representing let's say the infrastructure committee right also pushing this initiative forward as in as Edward explained at the beginning right like to have to feel this um primitive this primitive that is was gaining a lot of traction and popularity uh in in DeFi right this

16. 7:12

    token vault. Um and yeah we saw that okay this is something that is becoming very important uh and used in many projects and and different um components in the ecosystem and it was very important to standardize it and and to have it you know like okay this is how um token balls should work and I think yes um um as I approved it I think the team uh meteor team did a great job in in this specification Um also very important uh knowing the differences

17. 7:46

    with the the the Ethereum world right because uh from what we asked from the infra committee was like yes let's have an uh ERC I was 4626 equivalent in in year but this is not as simple as you're just copy pasting uh from from Ethereum right there is a many uh important differences that you have to take care of and that we didn't think uh at the beginning and I think the team took took care of Um and that's it right uh as I said uh I review it

18. 8:18

    I mainly compare it with the with Ethereum and and how it was working and and the well making sure that the functionality of of the standard for Ethereum was taken care and and also implemented here and I think everything else is well all good um taken care and and yeah very very happy with the with the work that they with your team.

19. 8:44

    Perfect. Uh Alexander, you were also part of the team reviewing it and I also saw that uh you went very thoroughly through the NEP even like suggesting some some some changes. Uh so what do you think about the NEP? Is it now in a in a nice state and what's your general thought on it and you know your vote? Yeah. Uh thank you for the uh NEP.

20. 9:09

    Basically I also try to compare to the original um proposal and um also we have the differences between Ethereum in your world. Of course, we have to mention uh method names of course uh except of the FTON transfer um which changed a few of them like for instance instead of uh um what was that uh instead of preview mint we have preview asset amount required to mint shares method.

21. 9:45

    uh uh I think uh from the engineering um standpoint usually you know uh uh it's a big question about method names and and so on. I think that clarity and uh you know is important. So that that's why I I feel like we have to go with these new improved longer method names and uh and I think that we don't have to take the original Ethereum uh kind of method names for granted. So I I believe

22. 10:27

    we have to we have to kind of do our our own way. uh but because of the reason and the reason is is confusion around the original uh terminology and meaning of this standard and I think uh yeah that was my concern and then we kind of I approve the way we uh kind of you know we established uh uh right now um what was else Um basically reviewing from the practical engineering perspective.

23. 11:08

    Um there is some terminology kind of asset and assets literally plural name means another uh just uh term and so like asset is an uh FT address and assets means like an amount of uh tokens you know deposited and so on. Um I think we improved it. Um uh I think also the method documentation is good like uh it shows differences between the original Ethereum proposal and the new proposal which is cool uh although it's prone to

24. 11:50

    some you know the types and it stakes u in just uh in wording but the uh API is good. Okay, so that's um that's my review and u it's pretty helpful that we actually kind of copy pasteed the original proposal because you know uh you know that it already uh reviewed uh by the Ethereum team partially so it's helpful. Okay, that's my perspective. Thanks. Okay, thank you so much. And I do want to to you know state

25. 12:30

    that while we can use ERC's as like uh uh templates or you know guidance it's true that we don't need to copy them 101 especially because again there are many things in the nature of near that do not do not map oneonone to to Ethereum and therefore uh indeed like I think that you were referring to the fact that um in in near in order to make a funual token transfer right like a And or to attach functionable tokens in a function

26. 13:01

    call, we need to use FT transfer call, right? Like we cannot just simply like make a call and attach some funable tokens. And because of that, uh you needed to change a couple of methods on how uh things are deposited and made, right? Like instead of deposited me, you need to act on FDL transfer, which is the method that is going to be executed on the vault when they receive a funable

27. 13:26

    token. um through you know attached to to to a function call. So yeah it's fine that we don't copy you know the naming oneonone because again functionality is not going to be uh oneonone. Okay perfect. Uh then I think that for all intended purposes this NEP is approved and we do expect to see in the future that if anyone is trying to create a tokenized vault uh them to to basically follow this standard. We're going to make sure also to reflect this in the documentation.

28. 13:58

    Uh thank you so much for the team working on this. Edward, thank you so much for Meteor championing this uh this this NP and keep making contributions to the ecosystem. And Aiker and Alexander, honestly, thank you so much. Without your reviews, we will not have a growing ecosystem. So we truly we we we we truly uh evaluate uh all of your contributions both as uh NEP creators and as NEP reviewers. So thank you so much.

29. 14:32

    Thank you. Thank you. Yeah, with that being said, uh I think we can conclude this meeting. Have a great rest of your day and see you all around in the air. Thank you. Cheers. Have a great day. Bye. Bye. Bye.