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

[ProgramCrafter]

To this day it is not determined what a 'vault' even is.

Like, do these match? DEX (if so, does liquidity pool contract match? does vault?), staking contract, vesting contract, TON Believers Fund, atomic swap contract, and so on.

[trademasterhub]

Mainnet validators

Please take part in the voting for network config adjustment.
Details of updates are given above.

1. Check that your validator software is on the latest version: commit cac968f.

If you use mytonctrl, first please ensure that you are up to date, in particular on commit 3816eb2 and vote for proposal via

vo 82972944767423313821326283030352055259326179170465528006873474837778003422390 76533703899083343601323766308882775352019089807862422256342837336826006755613

If you do not use mytonctrl, each round:

1.Create signed vote in validator-engine-console: createproposalvote 76533703899083343601323766308882775352019089807862422256342837336826006755613 vote-msg-body.boc
2. Send obtained vote-msg-body.boc to -1:5555555555555555555555555555555555555555555555555555555555555555 in internal message from any wallet from masterchain with 2 TON attached. If you are using wallet.fif script, it can be done via:
fift -s wallet.fif -1:5555555555555555555555555555555555555555555555555555555555555555 2 -B vote-msg-body.boc
and send resulting message to network.
If you are using lite-client, it can be done via
lite-client -C global-config.json -rc "sendfile wallet-query.boc"

Repeat for
82972944767423313821326283030352055259326179170465528006873474837778003422390

[behrang]

Hey, nice doc.

I just propose to add jetton master address to Deposit and Withdraw events.

Maybe they become useful in a future when a vault switches its jetton master to another version. In this case, event processors can differentiate between events on different jettons used in the same vault.

[ipromise2324]

Hey, nice doc.

I just propose to add jetton master address to Deposit and Withdraw events.

Maybe they become useful in a future when a vault switches its jetton master to another version. In this case, event processors can differentiate between events on different jettons used in the same vault.

Hi, thanks for your suggestion! Here's my thinking:

1. The vault itself is the jetton master. Even if the vault's code is upgraded due to a new jetton master version, the vault's address (i.e., the jetton master address) won't change. So adding the jetton master address to emit logs may not achieve what you're hoping for.
2. The Vault standard doesn't require upgradability. Implementations are free to remain immutable, meaning the jetton master version may never change for some vaults.
3. Jetton upgrades involve broader complexities. If a vault truly needs to upgrade jetton-related functionality, it raises much larger questions — like how to migrate existing share jetton wallets. I believe this topic goes beyond the scope of the Vault standard and should be discussed in a broader context, such as "How to migrate from Jetton 1.0 to Jetton 2.0."

When designing this standard, I did consider adding a version number to help other contracts verify vault code correctness, which would also help off-chain systems identify the vault version. However, passing this field via internal messages (or emit logs) offers no real security guarantee. If upgrade permissions are compromised, an attacker can still forge fake messages to deceive other contracts. That's why the standard emphasizes that upgradable vaults should implement robust multi-layered protection mechanisms.

In conclusion, I don't think we should add the jetton master address or version number to the Deposited and Withdrawn events. This topic might be better suited as a separate standard for TON contract upgrades (including jetton upgrades), rather than being included in the Vault standard.

[ipromise2324]

To this day it is not determined what a 'vault' even is.

Like, do these match? DEX (if so, does liquidity pool contract match? does vault?), staking contract, vesting contract, TON Believers Fund, atomic swap contract, and so on.

Thanks for your feedback! I've added a Vault definition at the beginning of the Summary. Any contract that matches it can implement this standard, and the Guide provides examples.

It's hard to strictly exclude certain types. For example, on Ethereum, most DEXs don't inherits ERC-4626, but Balancer does, and Ethena's sUSDe (Staked USDe, the yield-bearing version of the synthetic stablecoin USDe, which uses vesting for rewards) also inherits ERC-4626.

In general, if a contract aligns with the Vault definition, it can safely adopt this standard.