Add Tokenized Vaults Standard TEP

[ipromise2324]

This TEP establishes a standardized interface for tokenized vaults on TON, enabling consistent deposit/withdrawal operations, rate queries, and cross-protocol communication. Inspired by ERC-4626 but adapted to TON's asynchronous design, it improves DeFi ecosystem interoperability and reduces integration complexity.

[andrew-cong]

This proposal represents a strong, forward-thinking contribution to TON's DeFi ecosystem, addressing key fragmentation issues while thoughtfully adapting established standards like ERC-4626 to our asynchronous, message-driven architecture. It has high potential to accelerate protocol composability and developer adoption.

[SlorrUndef]

Hey @ipromise2324, thanks a lot for sharing - your proposal looks really solid!

We’ve also been working on an implementation that already includes feedback from top-tier partners like Aave, Ethena, and Affluent. Given that it reflects inputs from several ecosystem players, it feels more practical to move forward with this version as a base. That said, your proposal brings in great ideas, and it would be super valuable if you could comment on the current draft so we can capture the best of both approaches.

#525

We’ll also make sure to provide more transparency on future standards in progress, so everyone can stay aligned.

Looking forward to your feedback!

[alan890104]

@SlorrUndef Thank you for your response! I really appreciate the effort you've put into this proposal and the industry feedback you've gathered.

However, I'd like to respectfully clarify a few points. As the Founder of Torch Finance and working closely with TON developers, we have deep insights into the practical challenges developers face in this ecosystem. Our proposal isn't just conceptually similar to yours, it actually provides comprehensive coverage of scenarios that your current version doesn't address.

While industry feedback from major players is valuable, we shouldn't overlook the importance of technical completeness and developer experience. Our implementation includes:

• Complete design philosophy documentation, including the technical rationale for why Mint/Redeem functionality should not be implemented directly on TON
• Detailed data format specifications crucial for proper implementation
• Comprehensive unit tests covering edge cases
• Solutions for developer pain points we've identified through direct ecosystem engagement

Our proposal has similarly undergone extensive ecosystem validation, including feedback from leading protocols such as EVAA, DeDust, Storm Trade, Bidask, TONCO, Swap Coffee, as well as input from TON core team members. As a project backed by Curve Finance, we also have deep understanding and experience with ERC standards.

Based on these considerations, I personally believe that if we continue development based on proposal #524, while also inviting Aave, Ethena, and Affluent to review it, this would significantly reduce duplicated efforts. This approach is more aligned with TVM characteristics, and the current implementation is nearly ready for audit.

[ipromise2324]

Hi, glad to see you're also working hard for the TON ecosystem. I've carefully studied TEP-525, and here's my technical analysis and comparison:

1. Internal Functions and Get-methods Design Flaws

TEP-525's convert_to_shares(slice asset, int assets) has serious design issues.

As a get-method: Completely unusable, as it cannot accept additional off-chain data (such as price payload).

As an internal function: Equally problematic. Taking Tolk as an example, modern TON development doesn't store data in global variables but leverages lazy loading patterns. When additional data is needed, the current design forces developers to:

1. After receiving message: load storage → validate data → store storage (temporarily store data)
2. In convert_to_shares(): load storage again to retrieve data

This violates the Single Responsibility Principle and is inefficient.

TEP-524 elegantly solves this through the VaultOptions → VaultConfig pattern:

• Get-methods can accept VaultOptions parameters, supporting off-chain data input
• Internal functions directly receive validated VaultConfig, avoiding unnecessary storage operations

This design makes get-methods truly usable and internal functions more efficient.

2. Missing Rounding Rules

TEP-525 implements deposit/mint/withdraw/redeem operations but doesn't define rounding rules. For example:

• Deposit/Redeem should round down
• Mint/Withdraw should round up

3. Ambiguous Callback Mechanism

TEP-525's forwardPayload may appear in either refund_message or mint_payload, with unclear semantics. This increases complexity for developer interactions.

TEP-524 provides a standardized Callbacks structure, clearly distinguishing successCallback and failureCallback, each with independent payloads.

4. Insufficient Error Handling

TEP-525's refund lacks error codes, so interacting contracts cannot determine failure reasons (vault paused? limit reached?).

TEP-524 includes ResultCode in every operation, allowing contracts to respond appropriately to specific errors.

5. Mint/Withdraw UX Issues

TEP-525's mint operation might refund tiny amounts (e.g., 0.000000001 USDT), spending 0.05 TON gas to refund such small amounts—terrible user experience.

TEP-524 focuses on operation modes familiar to current TON users, with potential expansion when wallet plugins become widespread.

6. Quote Timeliness

TEP-525's preview_request lacks timestamp, preventing receivers from judging data freshness.

TEP-524's OP_TAKE_QUOTE includes timestamp, initiator, and receiver, providing complete context—more secure and flexible.

7. Missing Gas Estimation

Many developers have this experience: even after following documentation and sending transactions with correct message formats, they still get errors. Only after asking in the protocol's community do they discover insufficient TON was attached.

TEP-524 provides complete gas estimation methods, allowing developers to accurately estimate required gas and avoid this frustrating experience.

8. Event Standardization

TEP-525 lacks unified event log formats, hindering explorer and indexing service parsing.

TEP-524 defines complete event formats (Deposited, Withdrawn, Quoted), facilitating ecosystem tool integration.

9. Security Discussion

TEP-525 doesn't discuss critical security issues. TEP-524 thoroughly analyzes:

• Vault upgrade risks and mitigation measures
• Donation attack protection
• Callback mechanism security considerations
• Multi-signature and timelock recommendations

Conclusion

TEP-524 is not just an interface specification but a complete solution based on actual TON development experience.

It truly understands and addresses the needs of three core groups:

• Pain points developers actually encounter
• The smooth user experience needed for adoption
• Security concerns protocols care about most

Based on the technical analysis above, TEP-524 addresses many practical challenges that developers face in TON's ecosystem. While I respect all contributions to the ecosystem, I believe technical merit should guide our decision rather than timing or which protocols have provided feedback. TEP-524 provides a comprehensive foundation that would serve well as the base for the vault standard.

I appreciate the effort everyone has put into advancing TON's DeFi infrastructure. I'm happy to collaborate and explore how we can incorporate valuable ideas from different proposals to make the standard even better.

Looking forward to continuing this productive dialogue together.

[alan890104]

@ipromise2324 well done, nice comparison

[ipromise2324]

Hey @shuva10v, thanks a lot for your suggestions — they definitely help make the vault more usable. Based on your feedback, I’ve made the following changes:

1. Updated depositAsset to be not null for single-asset vaults, and also adjusted the Withdrawn and Quoted logs accordingly to improve flexibility for off-chain listeners.
2. Since you mentioned that including totalAssetAmount would make it easier for off-chain systems to reconstruct the state, I’ve added this field not only to the Deposited and Withdrawn logs but also included a totalSupply field, which should further help with state reconstruction.
3. Added the TL-B specification for minting shares, aligning with common practice (as in TEP-74 implementations), so that developers can more easily align their implementations.

Please take a look and let me know if I missed anything 🙏

[blendotsequad]

God