This is to discuss the proposed standard on “tokenized vaults” created under SNIP-22 and accessible here.
Tokenized, yield-bearing vaults are a widely used pattern across many DeFi protocols including lending markets, aggregators, and interest bearing tokens on Starknet and beyond.
Other than SNIP-2 tokens (ERC-20s), current tokenized vaults on Starknet expose diverse interfaces making integration difficult for protocols, aggregators and wallets which have to implement adapters for each standard. This is inefficient and error prone.
SNIP-22 defines a minimal API for tokenized (and yield-bearing) vaults focusing on the concepts of underlying assets and shares and required functions for the management of these concepts through protocols integrating the vaults or users themselves. It is not restricted to a certain domain (e.g. yield aggregators) but allows for a wide range of applications.
The standard will lower the integration effort for yield-bearing vaults and tokens, result in better UX and increase security for users. It follows the ERC-4626 standard that has found wide adoption and has unlocked innovation and growth in EVM-land.
Thank you @nbundi for proposing this standardization of “tokenized vaults” on Starknet. After careful consideration, here’s my feedback:
Standardizing interfaces for tokenized vaults is indeed crucial to facilitate integration and reduce the risk of errors.
The proposal is not limited to a specific domain, allowing for a wide range of DeFi applications.
Aligning with a proven standard like ERC-4626 is a wise approach.
Questions:
How do you envision the migration of existing vaults to this new standard?
Given the critical importance of vaults in the DeFi ecosystem, could you detail the standard’s security considerations and audit plans?
The SNIP-17 proposal seems to be an important step for the Starknet DeFi ecosystem, promising to improve the efficiency and security of DeFi integrations. I generally support this initiative.
I look forward to the next steps in developing and discussing this standard.
First of all, ty for your comment and support of the effort. It means a lot coming from you as I’m sure you and the Bountive team have a good understanding of the yield-bearing tokens/vaults landscape on Starknet and know first-hand about the inefficiency and risks of having to integrate with different implementations.
Re your questions:
General security considerations have been discussed in the SNIP here
Implementation and audit are not directly part of the standard, the SNIP only defines the interfaces implementations should expose. That said, Vesu has implemented the standard for our vTokens and this implementation is audited by ChainSecurity and CairoSecurityClan. You can find the implementation here and audit reports linked here
Migration of existing vaults needs to be considered on a case-by-case basis. In general, I think DeFi on Starknet is still in a relatively early phase without a lot of integrations on the smart contract level. Migrating to a new implementation should thus still be possible without a lot of friction or security concerns. But again, this needs to be reviewed on a case-by-case basis and projects needs to decide for themselves if a migration is appropriate or if the additional efforts and risks justify an integration with a vault that doesn’t follow the standard.
Thank you for taking my previous comments into account. I’m delighted that the SNIP-22 proposal on tokenized vaults is evolving.
The flexibility to handle different types of underlying assets is also crucial. It’s good to know that the SNIP-22 standard has been designed to be adaptable to this diversity of uses.
Overall, I think this SNIP-22 proposal is very promising and addresses an important need in the Starknet ecosystem. The standardization of tokenized vault interfaces is a crucial topic for promoting interoperability and innovation.
I remain at your disposal to continue discussions and contribute to the development of this standard. Please don’t hesitate to keep me informed of the next steps.
