TIP-4626: TRON Vault Standard

soffije · November 24, 2025, 7:35pm

TIP-4626: TRON Vault Standard (Tokenized Share Vaults)

Summary

Define a standard interface for tokenized vaults on TRON that accept a single TRC-20 asset as underlying, issue TRC-20 share tokens representing proportional ownership, and support streamlined deposit/withdraw flows optimized for TRON’s resource model. An optional extension integrates TIP-2612 (Permit) to enable gasless, single-transaction vault operations via off-chain signatures.

Abstract

TIP-4626 establishes a unified standard for tokenized share vaults in the TRON ecosystem. A compliant vault accepts deposits of a single TRC-20 asset (such as USDT or USDD) and issues share tokens that represent proportional claims on the vault’s total managed assets.

The standard defines a minimal yet complete interface including core methods for asset information (asset(), totalAssets()), conversion helpers (convertToShares(), convertToAssets()), preview functionality (previewDeposit()), and deposit/withdrawal operations (deposit(), withdraw()). All methods are designed specifically for TRON’s architecture, accounting for TRC-20 token mechanics, Bandwidth/Energy resource model, 0x41-prefixed address handling, and TIP-712 domain separation requirements.

An optional permit extension leverages TIP-2612 to enable gasless vault operations. Users can sign off-chain approval messages that relayers or dApps submit on-chain, eliminating separate approval transactions and reducing Energy consumption. This creates one-click deposit and withdrawal experiences where users only need to sign once rather than broadcast multiple transactions.

The specification draws conceptual inspiration from Ethereum’s ERC-4626 while being purpose-built for TRON. Unlike a direct port, TIP-4626 focuses on the minimal interface required for TRON’s high-volume stablecoin flows, removes Ethereum-specific assumptions about gas refunds and opcode costs, and prioritizes Energy efficiency for protocols processing millions of daily transactions.

Motivation

TRON processes extraordinary stablecoin volumes daily, with USDT alone seeing billions in transfers. This makes TRON the natural home for treasury management, yield generation, and capital efficiency solutions. Many protocols already implement vault-like patterns where users deposit TRC-20 assets, the protocol deploys that capital across lending platforms or liquidity pools, and users receive receipt tokens representing their claim on the vault’s managed assets plus accumulated yield.

However, these implementations exist in isolation. Each protocol invents its own method names, accounting conventions, and interaction patterns. A lending protocol might call its deposit function supply() while a liquidity aggregator uses stake() and a yield optimizer uses enter(). One vault might calculate shares as a simple 1:1 ratio while another uses complex formulas with decimal scaling factors. Some emit custom events while others reuse standard Transfer events in non-standard ways.

This fragmentation creates concrete problems. Wallet developers cannot build unified vault dashboards because each vault requires custom integration code. DeFi aggregators that want to route user deposits across multiple vaults must maintain separate adapters for each protocol. Analytics platforms struggle to calculate accurate TVL and APY metrics because accounting methods differ. Most critically, protocols cannot easily compose—a vault cannot hold shares of another vault as its underlying asset because there’s no standard interface to rely on.

Why Standardization Matters for TRON

As TRON’s DeFi and payment infrastructure grows, a unified vault standard becomes essential. Payment processors, custodians, and institutional treasuries need predictable, repeatable interfaces they can integrate once and reuse across all yield sources. Cross-chain bridges and aggregators likewise depend on consistent accounting and conversion logic to move capital efficiently between networks.

TRON also has platform-specific requirements that generic Ethereum standards do not address. Its Bandwidth/Energy model rewards minimizing storage writes and avoiding heavy loops; its 0x41-prefixed address format requires careful handling in TIP-712 signatures; and its high-throughput environment favors frequent small deposits rather than occasional large ones. A TRON-native vault design is therefore necessary for maximum efficiency.

For high-volume businesses such as payment gateways, the benefits are immediate. Idle balances from thousands of daily remittances can be swept into yield positions and withdrawn on demand using a single standard interface. Instead of custom integrations for each protocol, TIP-4626 lets applications compare vaults, allocate capital programmatically, and operate more efficiently across the entire ecosystem.

The Two-Transaction Problem

Even when users want to deposit into a vault, current flows create unnecessary friction. The standard pattern requires two separate transactions: first call approve() on the asset token to grant the vault a spending allowance, then call the vault’s deposit function to actually move tokens and receive shares. Each transaction requires the user to broadcast it, wait for confirmation, and pay Energy or Bandwidth costs.

This two-step flow particularly hurts onboarding. New users often hold only stablecoins without any TRX for transaction fees. They must first acquire TRX (adding another step), then execute two separate transactions before they can begin earning yield. In regions where TRON is used for remittances and payments, this complexity prevents mainstream adoption of yield-generating features.

TIP-2612 (Permit for TRC-20) solves the approval step by allowing users to sign an off-chain message instead of broadcasting an approval transaction. However, vaults need explicit integration to leverage this capability. By standardizing permit-based deposits and withdrawals in TIP-4626, we ensure all compliant vaults offer gasless operations out of the box. A user can sign once, a relayer submits the permit and deposit in a single transaction, and the user pays nothing—the relayer or protocol covers Energy costs as part of their service.

Why Not Simply Port ERC-4626?

ERC-4626 is a strong conceptual base, but porting it verbatim would add unnecessary complexity for TRON’s needs. The Ethereum version defines sixteen methods to support multiple interaction models, extensive preview functions, and per-address limit checks—features tailored to Ethereum’s gas mechanics and UX patterns, not TRON’s.

TRON users operate almost entirely in an asset-centric flow: deposit USDT, withdraw USDT. Parallel “shares-first” methods like mint and redeem offer little practical value and only enlarge the interface. Likewise, Ethereum-style max* functions solve per-user cap problems uncommon on TRON, where protocols typically use global caps or time-based constraints.

Additionally, ERC-4626 was optimized around Ethereum’s gas model—opcode costs, gas refunds, and the economics of storage clearing. TRON’s Energy system behaves differently and penalizes storage writes and unnecessary external calls far more than method count or opcode selection. Simply copying Ethereum patterns can make TRON vaults less efficient, not more.

TIP-4626 instead focuses on the minimal set of methods that TRON vaults actually require, preserving conceptual compatibility while tailoring the design to TRON’s architecture. This results in simpler implementations, lower Energy consumption, and easier integration for wallets, aggregators, and high-throughput financial applications.

Key Benefits of TIP-4626

A unified vault standard gives the TRON ecosystem predictable behavior and simpler integrations. Wallets, dApps, and analytics platforms can support all compliant vaults through a single interface, while users get consistent deposit and withdrawal flows across every protocol.

Standardization also maximizes composability. Vault shares can be used as collateral, combined into meta-vaults, or bridged cross-chain because their value and behavior are always determined through the same conversion functions. This enables new classes of products that were previously too fragmented to build reliably.

The permit extension directly improves UX on TRON. Users can interact with vaults through one-click, gasless flows powered by signatures, while protocols or relayers cover Energy costs. This lowers onboarding friction and enables richer automation, batching, and cross-protocol operations.

TIP-4626 also encourages efficiency. Shared patterns for minimizing storage writes and leveraging view-only preview functions reduce network load. Permit-based flows cut the number of required transactions, improving both performance and scalability.

Finally, the standard offers a clear foundation for future upgrades. Features like fee models, strategy modules, governance hooks, and liquidity routers can be added as optional extensions without breaking compatibility. This ensures TIP-4626 can evolve with the ecosystem while remaining stable for developers.

Specification

All TIP-4626-TRON–compliant vaults must follow a few TRON-specific rules so that they behave consistently across the ecosystem and remain efficient under the Bandwidth/Energy model.

1.1 Underlying Asset (TRC-20)

asset() MUST return a TRC-20 token contract address.
The asset MUST implement the standard TRC-20 interface:
- transfer, transferFrom, approve, allowance, balanceOf, totalSupply.
The asset MAY implement extensions (e.g. TIP-2612 permit, fee-on-transfer), but these MUST NOT break normal TRC-20 behavior expected by the vault (i.e. predictable balances and successful transfer / transferFrom).

1.2 Shares (Vault Token, TRC-20)

Vault shares MUST be TRC-20 tokens.
The common & Energy-efficient pattern is that the vault contract itself is the share token (vault = TRC-20).
Alternatively, shares MAY live in a separate TRC-20 contract, but:
- this adds an extra contract call for each deposit/withdraw,
- and therefore increases Energy cost.
The share token MUST emit standard Transfer and Approval events so wallets, explorers and analytics can treat it like any other TRC-20.

1.3 Address Handling & TIP-712

TRON has multiple address representations that need to be normalized for signatures:

On-chain (TVM/Solidity):
20-byte address type (same as Ethereum).
Off-chain (RPC/Explorers):
- 0x41… hex format, or
- base58check format starting with T….
TIP-712 / permit signatures:
- The domain separator and typed data MUST use the 20-byte address value.
- For a 0x41… hex address, the leading 0x41 byte is the TRON prefix and is not part of the 20-byte TVM address.

Implementation requirement (normalization):

When building TIP-712 / TIP-2612 messages:

Convert base58check (e.g. TXYZ…) to hex (e.g. 0x41abcd…) if needed.
Strip the first byte 0x41, leaving the 20-byte value 0xabcd….
Use that 20-byte value in domain separator and typed structs.

This keeps wallet signing and TVM verification consistent.

1.4 Resource Model (Bandwidth / Energy)

TRON uses Bandwidth and Energy instead of Ethereum’s gas. Vaults should be written with this in mind.

Read-only functions (asset, totalAssets, convertToShares, convertToAssets, previewDeposit):

MUST be marked view (or pure if applicable).
MUST NOT modify state or emit events.
MUST be deterministic for the same block state.

State-changing functions (deposit, withdraw):

SHOULD minimize SSTORE operations (each is expensive in Energy).
SHOULD avoid unbounded loops that scale with number of users or deposits.
SHOULD avoid patterns that depend on gas refunds (they do not exist on TVM).
MAY rely on Energy delegation if the protocol wants to sponsor user operations.

Best practice:
Cache values you need several times in the same transaction (e.g. totalAssets, totalSupply) instead of re-calling external contracts. For complex strategies, keep heavy calculations off-chain and expose only simple view helpers.

2.1 Core Interface: `ITRC4626Vault`

TIP-4626 defines a minimal interface with eight required methods. This is enough for basic vault integrations (frontends, aggregators, strategies) without unnecessary complexity.

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/// @title ITRC4626Vault - TRON Vault Standard Interface
/// @notice Minimal interface for tokenized share vaults on TRON
/// @dev Inspired by ERC-4626, simplified and adapted to TRON
interface ITRC4626Vault {
    // ========================= Events =========================

    /// @notice Emitted when assets are deposited and shares minted.
    /// @param caller  msg.sender that initiated the deposit
    /// @param owner   Address that provided the assets (may differ from caller)
    /// @param assets  Amount of underlying assets deposited
    /// @param shares  Amount of shares minted
    event Deposit(
        address indexed caller,
        address indexed owner,
        uint256 assets,
        uint256 shares
    );

    /// @notice Emitted when shares are burned and assets withdrawn.
    /// @param caller   msg.sender that initiated the withdraw
    /// @param receiver Address receiving the assets
    /// @param owner    Address whose shares were burned
    /// @param assets   Amount of underlying assets withdrawn
    /// @param shares   Amount of shares burned
    event Withdraw(
        address indexed caller,
        address indexed receiver,
        address indexed owner,
        uint256 assets,
        uint256 shares
    );

    // ============== Metadata & Asset Accounting ==============

    /// @notice Underlying TRC-20 asset of the vault.
    /// @dev MUST NOT revert.
    function asset() external view returns (address assetTokenAddress);

    /// @notice Total amount of underlying assets managed by the vault.
    /// @dev SHOULD include assets deployed in strategies.
    /// @dev MUST NOT revert.
    function totalAssets() external view returns (uint256);

    // ============== Conversion Helpers (view) ================

    /// @notice Convert an asset amount to the corresponding share amount.
    /// @dev MUST use same rounding direction as deposit().
    function convertToShares(uint256 assets) external view returns (uint256 shares);

    /// @notice Convert a share amount to the corresponding asset amount.
    /// @dev MUST use same rounding direction as withdraw().
    function convertToAssets(uint256 shares) external view returns (uint256 assets);

    // ================= Deposit Preview (view) =================

    /// @notice Preview how many shares would be minted by a deposit of `assets`.
    /// @dev MUST return the same value deposit() would mint in current state.
    /// @dev MUST NOT revert due to vault state (pause, caps, etc.).
    function previewDeposit(uint256 assets) external view returns (uint256 shares);

    // ================== Core State-Changing ===================

    /// @notice Deposit `assets` into the vault, minting shares to `receiver`.
    /// @dev Caller MUST have approved the vault to spend at least `assets`.
    /// @dev MUST emit {Deposit}.
    function deposit(uint256 assets, address receiver)
        external
        returns (uint256 shares);

    /// @notice Withdraw `assets` from the vault, burning shares from `owner`.
    /// @dev If caller != owner, caller MUST have allowance for owner's shares.
    /// @dev MUST emit {Withdraw}.
    function withdraw(
        uint256 assets,
        address receiver,
        address owner
    ) external returns (uint256 shares);
}

This asymmetric API (deposit: assets + receiver, withdraw: assets + receiver + owner) is intentional: it allows deposit on behalf of and withdraw on behalf of patterns for relayers, routers, and automated strategies.

3.1 Share Price

At a high level:

totalAssets() returns the vault’s total managed assets.
totalSupply() (from the share TRC-20) returns total shares in circulation.

The “price per share” is:

pricePerShare = totalAssets() / totalSupply()

All conversions are proportional to this ratio.

3.2 Rounding Rules

To protect the vault and remaining depositors from value extraction:

convertToShares() and deposit() MUST round down:
- Users never receive more shares than the exact fraction.
convertToAssets() and withdraw() MUST round down:
- Users never withdraw more assets than their share fraction.

Small rounding dust stays in the vault, slightly favoring long-term depositors.

Example

Vault state: totalAssets = 1000, totalSupply = 100 → 1 share = 10 assets.

Deposit 99 assets:

shares = 99 * 100 / 1000 = 9.9 → 9 shares (round down)

Withdraw 99 assets:

shares = 99 * 100 / 1000 = 9.9 → 9 shares burned
assets paid = convertToAssets(9) = 9 * 1000 / 100 = 90

3.3 First Depositor

When totalSupply() == 0, the share price is undefined. Implementations MUST handle this explicitly.

Common patterns:

Simple: first depositor gets 1:1 (shares = assets).
Safer: use “virtual shares” / “dead shares” minted at deployment to a burn address so that the first user cannot manipulate the initial price by sending assets directly to the vault.

Production vaults SHOULD implement one of these protections.

4.1 Deposit Flow (`deposit(assets, receiver)`)

Typical steps inside the vault:

Checks
- assets > 0 (recommended).
- Optional: vault not paused, caps not exceeded, etc.

Compute shares

uint256 shares = convertToShares(assets);
require(shares > 0, "zero shares");

Pull assets

require(
    underlying.transferFrom(msg.sender, address(this), assets),
    "transferFrom failed"
);

Mint shares
- Mint shares to receiver.
- Update share totalSupply and balances.

Emit event

emit Deposit(msg.sender, receiver, assets, shares);

Here, msg.sender pays the tokens, receiver gets the shares. They may be the same or different.

4.2 Withdraw Flow (`withdraw(assets, receiver, owner)`)

Checks
- assets > 0 (recommended).
- Optional: vault not paused, withdraw allowed.

Compute shares

uint256 shares = convertToShares(assets);
require(shares > 0, "zero shares");

Allowance (if caller != owner)
- Check TRC-20 allowance of shares.
- Decrease it, unless it is type(uint256).max (infinite allowance pattern).
Burn shares
- Burn shares from owner.

Transfer assets

require(
    underlying.transfer(receiver, assets),
    "transfer failed"
);

Emit event

emit Withdraw(msg.sender, receiver, owner, assets, shares);

Roles in one call:

owner — who loses shares.
receiver — who receives assets.
msg.sender — who initiates (user, relayer, strategy, etc.).

5.1 Optional Permit Extension (TIP-2612)

To avoid the classic approve → deposit and approve → withdraw two-step flows, vaults can integrate with TIP-2612. This allows deposits and withdrawals to be executed via a signature plus a single transaction, improving UX and enabling sponsored/relayed operations.

5.2 Deposit with Permit

Traditional flow (2 tx):

asset.approve(vault, assets)
vault.deposit(assets, user)

Permit flow (1 tx + 1 signature):

User signs TIP-2612 permit for the asset:
- owner = user, spender = vault, value = assets.

Any caller (user or relayer) calls:

vault.depositWithPermit(assets, user, user, deadline, v, r, s);

Inside depositWithPermit:
- asset.permit(user, vault, assets, deadline, v, r, s)
- asset.transferFrom(user, vault, assets)
- Mint shares to receiver.

Result: one on-chain transaction, user only signs once off-chain.

5.3 Withdraw with Permit

Requirements:

The share token (vault or separate) implements TIP-2612.

Flow:

User signs permit for the shares:
- owner = user, spender = vault, value = sharesNeeded.

Any caller calls:

vault.withdrawWithPermit(assets, user, user, deadline, v, r, s);

Inside withdrawWithPermit:
- shareToken.permit(user, vault, sharesNeeded, deadline, v, r, s)
- Burn shares from owner.
- Transfer assets to receiver.

This enables “one signature → one transaction → full withdraw” flows and combines nicely with relayers or Energy-sponsoring services.

Differences from ERC-4626 (Ethereum)

TIP-4626-TRON keeps the mental model of ERC-4626, but trims and adapts it to TRON.

Removed / Not Included Methods

Compared to full ERC-4626, TIP-4626 omits:

maxDeposit, maxMint, maxWithdraw, maxRedeem
previewMint, previewRedeem, previewWithdraw
mint, redeem

Rationale:

TRON vault users mostly think in assets, not shares.
Limits are often global / time-based, not per-user contract methods.
Frontends can get everything they need from:
- totalAssets, totalSupply, convertToShares, convertToAssets, previewDeposit.

This keeps the interface smaller and cheaper to implement.

TRON-Specific Adaptations

Token standard: TRC-20 instead of ERC-20.
Address formats: 0x41 / base58check + normalization in TIP-712.
Resources: Bandwidth/Energy instead of gas refunds & opcode-level tuning.
Permit: TIP-2612 + TIP-712 instead of EIP-2612 + EIP-712.

Preserved Concepts

Despite the differences, TIP-4626 keeps the important bits:

Tokenized shares proportional to totalAssets.
Clear conversion helpers with defined rounding.
Standard Deposit and Withdraw events.
Composability: a vault can hold other vaults as assets.
Safety-first: rounding rules protect the vault and remaining depositors.

This gives TRON a vault standard that feels familiar to ERC-4626 users, but is native to TRON’s architecture and resource model.

Requires

TIP-4626-TRON relies on existing TRON standards and requires no protocol-level changes. Vaults depend on the TRC-20 token standard for both underlying assets and share tokens, since all deposits, withdrawals, and share-accounting operations use standard TRC-20 semantics such as transferFrom, approve, and totalSupply.

If the optional permit extension is implemented, TIP-712 must be supported in both contracts and wallets, as it enables typed structured data signatures on TRON. This ensures users can sign readable permit messages that authorize deposits or withdrawals without sending approval transactions.

Permit-based operations also require TIP-2612 support on the involved TRC-20 tokens. The underlying asset must implement TIP-2612 for gasless deposits, while the vault’s share token must implement TIP-2612 for gasless withdrawals. If either token lacks TIP-2612, those specific permit flows are simply unavailable.

Signature verification uses the standard TVM ecrecover precompile, which already exists and requires no upgrades. All logic runs fully at the smart-contract layer, meaning TIP-4626-TRON can be deployed and used immediately across the ecosystem.

Backward Compatibility

TIP-4626 is intentionally designed as a non-breaking addition to the TRON ecosystem. Any existing TRC-20 token can already serve as a vault asset without modification—stablecoins like USDT or USDD work immediately, and TIP-2612 support is only needed for optional permit-based flows, not for core vault functionality.

Current vault implementations on TRON can adopt TIP-4626 through upgrades, wrappers, or parallel deployments. Upgradeable contracts can integrate the interface directly, while non-upgradeable vaults can be wrapped by adapters exposing the TIP-4626 methods. Protocols may also deploy new TIP-4626-compliant vaults and migrate users gradually at their own pace.

Wallets and dApps require no mandatory updates for basic use: vault shares are standard TRC-20 tokens that appear in balances and can be transferred normally. TIP-712 support enables optional permit flows, and many TRON wallets already implement it due to TIP-2612 adoption. Frontends can detect TIP-4626 vaults simply by checking for asset() and totalAssets().

The standard does not interfere with existing behavior. Standard TRC-20 operations continue to function, and the Deposit/Withdraw events follow familiar patterns already used by many protocols. Developers may add extra methods without affecting compliance as long as required TIP-4626 functions remain intact.

Energy costs remain comparable to traditional vault operations, and permit-based flows can even reduce total network usage by removing separate approval transactions. Thanks to its additive, non-disruptive design, TIP-4626 allows gradual adoption across the ecosystem, enabling early adopters to benefit immediately while preserving full compatibility with existing contracts and tooling.

Example Workflow

Scenario: Payment Gateway Treasury Management

A remittance service processes $10M+ USDT daily on TRON. During low-volume periods, idle USDT sits unused. The service wants to earn yield on treasury balances using a TIP-4626-compliant vault with TIP-2612 permit integration.

Setup

Asset: USDT (TRC-20 with TIP-2612 support)
Vault: TreasuryVault (implements TIP-4626 + optional permit extension)
User: Payment gateway’s hot wallet

Initial State

Gateway holds: 5,000,000 USDT
Vault holds: 50,000,000 USDT across 100 depositors
Share supply: 45,000,000 vault shares
Share price:

price = totalAssets / totalSupply = 50,000,000 / 45,000,000 ≈ 1.111 USDT per share

Flow 1 — Traditional Deposit (Two Transactions)

Step 1: Preview deposit

(Off-chain, no Energy)

const shares = await vault.previewDeposit(1_000_000e6);
// → 900,090 shares  (1,000,000 * 45M / 50M, rounded down)

Step 2: Approve vault (user pays Energy)

await usdt.approve(vault.address, 1_000_000e6);
// ~50,000 Energy consumed

Step 3: Deposit (user pays Energy)

await vault.deposit(1_000_000e6, gateway.address);
// ~120,000 Energy consumed

Events

USDT.Transfer(gateway → vault, 1,000,000e6)
Vault.Transfer(0x0 → gateway, 900,090)
Vault.Deposit(gateway, gateway, 1,000,000e6, 900,090)

Result

User paid ~170k Energy
User now holds 900,090 shares
Shares represent a proportional claim on underlying assets

Flow 2 — Gasless Deposit With Permit

(One Signature, Zero User Transactions)

The gateway signs one TIP-712 permit; a relayer pays Energy.

Step 1: Preview deposit

Same preview as before (zero Energy):

const shares = await vault.previewDeposit(1_000_000e6);
// → 900,090 shares

Step 2: User signs permit off-chain

Frontend constructs a TIP-712 message for USDT:

const domain = {
  name: 'Tether USD',
  version: '1',
  chainId: 0x2b6653dc >>> 0, // TRON mainnet, low 32 bits
  verifyingContract: usdt.address
};

const types = {
  Permit: [
    { name: 'owner',  type: 'address' },
    { name: 'spender', type: 'address' },
    { name: 'value',   type: 'uint256' },
    { name: 'nonce',   type: 'uint256' },
    { name: 'deadline', type: 'uint256' }
  ]
};

const value = {
  owner: gateway.address,
  spender: vault.address,
  value: 1_000_000e6,
  nonce: await usdt.nonces(gateway.address),
  deadline: Math.floor(Date.now()/1000) + 3600
};

const signature = await signer._signTypedData(domain, types, value);
// Produces { v, r, s }

The user pays 0 TRX.

Step 3: Relayer submits `depositWithPermit`

await vault.depositWithPermit(
  1_000_000e6,
  gateway.address,
  gateway.address,
  value.deadline,
  signature.v,
  signature.r,
  signature.s
);
// Relayer pays ~170,000 Energy

The vault internally performs:

USDT.permit(owner → vault, value, signature)
USDT.transferFrom(owner → vault, assets)
Mint shares to receiver

Events

Same as traditional deposit.

Result

Gateway pays 0 TRX & 0 Energy
Holds 900,090 shares
Relayer or dApp sponsored the transaction
UX improved: only one signature from the user

Flow 3 — Gasless Withdraw With Permit

(One Signature, Zero User Transactions)

Assume the gateway wants to withdraw 500,000 USDT back to hot wallet.

Step 1: Preview shares required

const sharesRequired = await vault.convertToShares(500_000e6);
// ≈ 450,045 shares (rounded down)

Step 2: User signs permit for vault shares

If the vault is the TRC-20 share token, the permit domain is:

const domain = {
  name: 'Treasury Vault Shares',
  version: '1',
  chainId: 0x2b6653dc >>> 0,
  verifyingContract: vault.address
};

Permit struct:

const types = {
  Permit: [
    { name: 'owner', type: 'address' },
    { name: 'spender', type: 'address' },
    { name: 'value', type: 'uint256' },
    { name: 'nonce', type: 'uint256' },
    { name: 'deadline', type: 'uint256' }
  ]
};

const value = {
  owner: gateway.address,
  spender: vault.address,
  value: sharesRequired,
  nonce: await vault.nonces(gateway.address),
  deadline: Math.floor(Date.now()/1000) + 3600
};

const sig = await signer._signTypedData(domain, types, value);

Again, gateway pays 0 TRX.

Step 3: Relayer executes withdraw

await vault.withdrawWithPermit(
  500_000e6,
  gateway.address,
  gateway.address,
  value.deadline,
  sig.v,
  sig.r,
  sig.s
);
// Relayer pays ~130,000 Energy

Vault executes internally:

vault.permit(owner → vault, sharesRequired, sig)
Burn sharesRequired shares
Transfer 500,000 USDT to receiver

Result

Gateway receives 500,000 USDT instantly
Gateway performs zero on-chain actions
Only cost is an off-chain signature
Relayer or system sponsor covers Energy

Final State After All Flows

Component	State Change
Vault	Increased/decreased assets + shares accordingly
Gateway	+900,090 shares (after deposit), −450,045 shares (after withdraw), +500k USDT
Relayer	Paid Energy for both gasless calls
UX	Gateway executed everything with two signatures, zero tx

Conclusion

In summary, TIP-4626-TRON introduces a unified, lightweight, and TRON-optimized vault standard that enables predictable share accounting, efficient treasury management, and seamless integration across the ecosystem. By pairing TRC-20–based vault shares with TIP-712 and optional TIP-2612 permit flows, the standard delivers a modern, gasless-friendly user experience where deposits and withdrawals can be executed with a single signature and no upfront TRX requirements.

We encourage the TRON developer community to review this proposal, provide feedback, and consider adopting TIP-4626-TRON for yield vaults, liquidity accounting layers, custodial systems, and automated treasury protocols. With community support, reference implementations, and wallet/tooling integration, TIP-4626-TRON can become a foundational building block for stablecoin infrastructure, high-volume settlement systems, and next-generation DeFi products on TRON.

By embracing this standard, TRON dApps can offer smoother onboarding, reduced operational friction, and a consistent interface for managing tokenized assets—further strengthening TRON as a leading platform for large-scale financial applications.

os_creator · January 6, 2026, 4:13pm

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?

DenD · January 7, 2026, 2:30pm

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?

Dila_Yaranarth · January 7, 2026, 2:40pm

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.

annaTs · January 7, 2026, 2:55pm

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.

elgrmo · January 9, 2026, 10:06pm

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?

Proposal		Replies	Views
TIP-2612: TRC-20 Permit TRON submitted	6	1460	January 9, 2026
TIP-4337/3074: TRON Account Abstraction & Meta-Transaction Standard TRON	0	991	January 15, 2026
TIP-4494: TRC-721 Permit TRON submitted	6	1962	January 8, 2026
TIP-1193/1474: Standard JSON-RPC and Provider Specification for TRON TRON	7	1307	January 9, 2026
TIP-Batch: TRON Settlement Batching Layer TRON building	32	3219	January 12, 2026

TIP-4626: TRON Vault Standard

TIP-4626: TRON Vault Standard (Tokenized Share Vaults)

Summary

Abstract

Motivation

Why Standardization Matters for TRON

The Two-Transaction Problem

Why Not Simply Port ERC-4626?

Key Benefits of TIP-4626

Specification

1.1 Underlying Asset (TRC-20)

1.2 Shares (Vault Token, TRC-20)

1.3 Address Handling & TIP-712

1.4 Resource Model (Bandwidth / Energy)

2.1 Core Interface: ITRC4626Vault

3.1 Share Price

3.2 Rounding Rules

3.3 First Depositor

4.1 Deposit Flow (deposit(assets, receiver))

4.2 Withdraw Flow (withdraw(assets, receiver, owner))

5.1 Optional Permit Extension (TIP-2612)

5.2 Deposit with Permit

5.3 Withdraw with Permit

Differences from ERC-4626 (Ethereum)

Removed / Not Included Methods

TRON-Specific Adaptations

Preserved Concepts

Requires

Backward Compatibility

Example Workflow

Scenario: Payment Gateway Treasury Management

Setup

Initial State

Flow 1 — Traditional Deposit (Two Transactions)

Step 1: Preview deposit

Step 2: Approve vault (user pays Energy)

Step 3: Deposit (user pays Energy)

Events

Result

Flow 2 — Gasless Deposit With Permit

(One Signature, Zero User Transactions)

Step 1: Preview deposit

Step 2: User signs permit off-chain

Step 3: Relayer submits depositWithPermit

Events

Result

Flow 3 — Gasless Withdraw With Permit

(One Signature, Zero User Transactions)

Step 1: Preview shares required

Step 2: User signs permit for vault shares

Step 3: Relayer executes withdraw

Result

Final State After All Flows

Conclusion

Related proposals

2.1 Core Interface: `ITRC4626Vault`

4.1 Deposit Flow (`deposit(assets, receiver)`)

4.2 Withdraw Flow (`withdraw(assets, receiver, owner)`)

Step 3: Relayer submits `depositWithPermit`