TIP-4626: TRON Vault Standard

[Pelirkere]

It’s good to see a proposal that explicitly says Ethereum gas assumptions don’t apply to TVM. Too many designs ignore Energy costs until it’s too late

[Molyle235000]

Keeping permit support optional feels like the right design choice here. It allows teams to adopt gasless flows when they are ready, without forcing extra complexity on simpler vaults. The core interface stays clean and easy to implement, which lowers the barrier for adoption. At the same time, more advanced protocols can still offer a much better UX through permits. This flexibility makes the standard practical for a wide range of use cases.

[Lei665]

Eight required methods feels refreshingly minimal. It’s enough for serious integrations without turning the interface into a checklist monster

[Ser11114]

Analytics platforms will benefit a lot from a standard like this. When conversions between assets and shares follow the same rules everywhere, TVL calculations become much more trustworthy. Share price tracking also becomes easier and more consistent across different vaults. This reduces the need for protocol specific heuristics and manual adjustments. In the long run, it should improve data quality for both users and researchers.

[Arl12]

How do you see fee logic or governance hooks being layered on later without fragmenting the standard again?

[Elava23]

The payment gateway example actually helped connect the dots for me. This isn’t just DeFi theory, it’s very applicable to real businesses

[soffije]

@os_creator

Interesting proposal! One thing I’m wondering about: how are fallbacks handled if a vault is temporarily unable to execute a submitted transaction (e.g., due to insufficient resources or a failed pre‑check)? Is there a recommended pattern for queuing/retrying, or does the vault simply revert and users have to resubmit manually?

Hey, @os_creator !

The vault does not implement any queuing or retry mechanism. If a pre-check fails (pause, cap, insufficient shares, etc.) or the transaction runs out of Energy, the call simply reverts.

Retry and fallback logic are intentionally kept off-chain. Frontends, relayers, or treasury automation systems are expected to re-simulate via previewDeposit, convertToShares, or convertToAssets and resubmit when conditions allow. This avoids on-chain state for pending operations and keeps vaults Energy-efficient.

For permit-based flows, a revert does not consume the signature. As long as the permit deadline has not expired and the nonce remains valid, the same signed message can be reused for a later submission.

[soffije]

@DenD

Would it be possible to wrap existing yield-bearing tokens into this new 4626 standard, or would the protocols need to launch entirely new versions of their vaults?

Hello, @DenD !

Both approaches are supported.

Existing yield-bearing tokens can be wrapped by adapter contracts that implement the TIP-4626 interface and translate calls to the underlying protocol’s deposit/withdraw logic. This allows protocols to become TIP-4626-compatible without changing their core contracts.

Alternatively, protocols may launch native TIP-4626 vaults for new deployments where full control over accounting, permit support, and Energy optimization is desired. The standard does not require migration; wrappers and native vaults can coexist.

[soffije]

@Dila_Yaranarth

This Vault standard seems like a really solid foundation for managing on‑chain assets with richer control logic. I’m particularly curious about role management and access control — for example, can the same Vault contract support multiple roles with different permissions (signer vs executor vs viewer)? And if so, how fine‑grained can those permissions be? In some other vault standards, it’s really helpful to restrict certain critical ops only to specific keys, while allowing others to view state or queue low‑risk actions. Some examples or recommended patterns here would be useful.

Hi, @Dila_Yaranarth !

TIP-4626 intentionally does not standardize role management or access control. The core interface only defines the asset/share accounting and the deposit / withdraw flows, and assumes normal TRC-20 permissions (owners control their balances; allowances gate third-party actions).

A vault can still implement multiple roles and fine-grained permissions, but that is out of scope and left to implementations. Common patterns are:

• Operational roles for strategy execution (e.g., harvest/rebalance) via onlyRole / multisig / timelock, while keeping deposit and withdraw permissionless.
• Emergency roles for pause/unpause or guardian actions that only affect operational state checks (caps, pauses) and do not override user ownership of shares.
• Viewers are not an on-chain role in this standard; reads are already permissionless. Off-chain “viewer” restrictions are handled at the UI/API layer.

If a protocol needs queued execution or signer/executor separation, it should be implemented as an extension layer (router, controller, or management module) that calls into a TIP-4626 vault, rather than being required by the vault standard itself.

[soffije]

@annaTs

Does this standard support ‘maxDeposit’ and ‘maxMint’ limits out of the box? Useful for vaults that need to manage capacity during early stages or specific risk scenarios.

Hey, @annaTs !

No. maxDeposit and maxMint are intentionally not part of the TIP-4626 core interface.

Capacity management (caps, pauses, phase-based limits) is handled through internal vault checks inside deposit() / withdraw(), not via standardized query methods. If a deposit would exceed a cap or violate risk constraints, the call simply reverts.

This design keeps the interface minimal and Energy-efficient, and reflects common TRON patterns where limits are global or time-based, not per-address. Frontends and automation are expected to rely on previewDeposit() plus off-chain configuration or protocol metadata if they need to surface capacity information.

Protocols that require explicit limit queries can expose them as non-standard optional methods without affecting TIP-4626 compliance.

[soffije]

@elgrmo

Excellent foundation for composability. The motivation mentions the possibility of creating “meta-vaults,” where one vault uses shares of another as its underlying asset. Is there a future plan to consider a standard extension that would explicitly define such scenarios and potentially add methods for safely determining the “depth” of nesting or detecting circular dependencies?

Hey, @elgrmo !

TIP-4626 allows meta-vaults by design, but it does not standardize nesting awareness or dependency introspection.

A vault may accept another vault’s share token as its underlying asset as long as it is a valid TRC-20. Conversion logic remains correct because all accounting is expressed via totalAssets() and totalSupply() at each layer. However, detecting nesting depth or circular dependencies is intentionally left out of scope.

Those concerns are better handled off-chain or in higher-level coordination layers (aggregators, routers, risk engines) that can analyze vault graphs and enforce safety rules. Adding on-chain introspection would increase complexity and Energy cost and is not required for correct vault operation.

[soffije]

@evancaker

how would fee on transfer tokens behave inside a TIP-4626 vault. Is that something vaults should explicitly block?

Hello, @evancaker !

Fee-on-transfer tokens are not forbidden, but they require explicit handling by the vault.

If the underlying asset takes a fee on transfer or transferFrom, the vault MUST base share minting on the actual amount received, not on the nominal assets parameter. In practice, this means measuring the vault’s asset balance before and after the transfer and using the delta for convertToShares.

Vaults that do not implement this pattern SHOULD explicitly block fee-on-transfer tokens, as naïvely assuming full transfer amounts would result in share over-minting and value leakage.

Because fee mechanics vary widely, TIP-4626 does not mandate support. Each vault should either:

• correctly account for net received amounts, or
• clearly document that fee-on-transfer assets are unsupported and revert on deposit.

The standard leaves this as an implementation choice to preserve correctness and Energy efficiency.

[soffije]

@Arl12

How do you see fee logic or governance hooks being layered on later without fragmenting the standard again?

Hey hey, @Arl12 !

Fee logic and governance are intentionally kept out of the core interface to avoid fragmentation.

TIP-4626 defines only the invariant layer: asset accounting, share issuance, and conversion rules. Fees (performance, withdrawal, management) can be implemented inside deposit() / withdraw() or in internal hooks without changing the external interface. From the outside, integrations continue to rely on the same methods and events.

Governance hooks follow the same pattern. Pauses, caps, strategy changes, fee updates, or role-based controls can be added as implementation-specific extensions or managed by external controllers (multisig, timelock, DAO modules) that call into a compliant vault.

This approach keeps the standard stable while allowing diversity at the implementation layer. As long as the required TIP-4626 methods behave correctly, additional logic does not affect composability, wallets, or aggregators.