TIP-4337/3074: TRON Account Abstraction & Meta-Transaction Standard

Networks TRON
1

TIP-4337/3074: TRON Account Abstraction & Meta-Transaction Standard

Summary

We propose a TRON-native account abstraction (AA) standard – analogous in spirit to Ethereum’s EIP-4337/EIP-3074 – that enables smart contract wallets on TRON with features like session keys, social recovery, gasless transactions, and bundling. This design leverages TRON’s existing architecture (TVM, multi-key accounts, resource model) and complements it with new smart-contract interfaces (an EntryPoint, paymaster contracts, smart-wallet contracts, etc.). The standard is fully optional and backward-compatible: existing TRON accounts and transactions remain unchanged, while dApps may adopt AA to improve UX (for example, allowing users to pay gas in tokens or offload gas entirely). We also outline a lighter “relayer” variant (inspired by EIP-3074) that requires only a forwarder contract (no new opcodes), and discuss what protocol features (e.g. AUTH/AUTHCALL) could further simplify meta-transactions if adopted by TRON. Overall, TRON’s fast DPoS chain, built-in multi-sign and paymaster capabilities, and emphasis on usability make it well-suited to benefit from such an AA standard.

Abstract

Account abstraction (AA) allows users to own smart contract wallets (instead of simple key-pair EOAs) as their primary account. Smart wallets can enforce custom logic: multi-signature and social recovery, session keys, flexible gas/payment schemes, etc. Ethereum’s EIP-4337 achieves this by introducing a new “UserOperation” object, an EntryPoint contract, bundlers, and paymasters. We adapt this concept to TRON’s model, designing a TRON-specific AA standard that fits TRON’s resource model and philosophy. Key ideas include:

  • TRON Smart Wallets – contracts that implement an AA interface, holding TRX/tokens and executing transactions under custom authorization logic (multisig, guardians, session keys, etc.).
  • EntryPoint Contract – a deployed singleton that receives UserOperations, verifies them (by calling the smart wallet’s validation logic, and optionally a paymaster’s logic), then executes the intended transaction on behalf of the smart wallet. Bundlers (off-chain relayers) call this EntryPoint with batches of UserOperations.
  • Paymaster Contracts – optional contracts that sponsor gas for certain users/operations (e.g. a TRC-20 token contract can act as its own paymaster, enabling “Gas Free” transfers in that token).
  • UserOperation Structure – a new data structure including fields like target address, call data, nonce, fee limit (in TRX or tokens), expiration, plus signatures. Unlike Ethereum’s gas fees, TRON’s resource model (energy, bandwidth, and fixed TRX cost) is used.
  • Session Keys & Recovery – smart-wallet logic can allow ephemeral “session keys” with limited use, or designate guardians who can help recover an account (social recovery). These are built into the wallet’s validation code rather than the protocol.

We compare two variants: (a) a full execution-abstraction model (analogous to EIP-4337) using an alternate mempool and bundlers, and (b) a relayer/meta-tx model (inspired by EIP-3074/ERC-2771) using a forwarder contract. We emphasize that this standard is TRON-native: it uses TRON’s existing VM and fee model, aligns with TRON’s user-friendly goals (e.g. gasless USDT via paymaster), and solves TRON-specific pain points (like the 1.1 TRX account-activation cost). Finally, we analyze compatibility: no consensus changes are needed for the contract-based version (making it backward-compatible), while an AUTH/AUTHCALL-based variant would require a hard fork (but could be offered as an optional upgrade).

Motivation

TRON already provides partial account flexibility through built-in multi-signature accounts and resource sponsorship, but core UX frictions remain. Users still must manage private keys directly, hold TRX for fees, and pay a fixed account activation cost (1.1 TRX). Developers often rely on ad-hoc solutions such as custodial wallets, manual energy delegation, or protocol-specific gas abstractions.

Account abstraction addresses these limitations by introducing smart-wallet accounts with programmable authorization and execution logic. This enables gasless or token-paid transactions via paymasters, eliminates upfront account activation costs through contract-based wallet creation, and allows session keys for safer, frictionless dApp interactions. Social recovery can be embedded directly into wallet logic, avoiding costly on-chain permission updates.

A unified AA standard also enables transaction batching and sponsored execution, improving UX for complex dApp flows. This approach aligns naturally with TRON’s design philosophy—fast finality, predictable fees, and strong stablecoin usage—while remaining fully compatible with the TVM and existing fee model.

In short, TRON already has the building blocks for account abstraction, but lacks a coherent, protocol-aligned standard. This proposal formalizes those capabilities into a TRON-native AA model tailored to the network’s architecture and adoption goals.

Background

TRON’s account and resource model is similar to Ethereum’s EVM but with important differences. TRON uses the Tron Virtual Machine (TVM), an EVM-like runtime. Accounts can be either EOAs (controlled by private keys) or contract accounts. Crucially, TRON EOAs can have multiple permission levels and keys: one address can incorporate multi-signature (by enabling account permission with threshold and keys). For example, TRON’s account permissions allow an account to define an owner and one or more active keys, each with weights, so that transactions can require 1-of-2 or 2-of-3 signatures.

However, enabling multi-signature costs 100 TRX under current rules

TRON’s fee model is also distinctive. There are two primary resources: Bandwidth and Energy . Bandwidth (consumed by transactions) and Energy (consumed by smart-contract execution) are obtained by staking TRX or delegated from others. If an account’s bandwidth/energy balance is insufficient, the chain automatically burns TRX at fixed rates (0.001 TRX per bandwidth unit, 0.0001 TRX per energy unit). Thus, sending transactions can be effectively “free” if the user has enough staked resources; otherwise TRX is burned. Recently, TRON introduced a Gas Free feature for TRC-20 USDT, where transaction fees (bandwidth/energy) are paid in USDT instead of TRX. These built-in mechanisms show TRON’s flexibility in fees (users can pay in tokens or via staking).

On the contract level, TRON supports custom authorization and forwarding patterns. While not standardized like Ethereum’s ERC-2771, one can implement a forwarder contract in TRON that verifies a user’s off-chain signature and then calls a target contract on their behalf, mimicking “meta-transactions.” EVM-compatible tools (Solidity on TVM) can reuse many patterns from Ethereum.

Comparing Ethereum’s account abstraction proposals: EIP-4337 (“ERC-4337”) defines UserOperations, an EntryPoint contract, bundlers, and paymasters to achieve AA without a fork. EIP-3074 proposes adding two opcodes (AUTH/AUTHCALL) so that EOAs can authorize a contract (invoker) to act on their behalf. The Ethereum context proves the utility of AA (sponsored gas, arbitrary signature schemes, social recovery, etc.), but it assumes Ethereum’s gas market and protocol. TRON has no native equivalent of AUTH/AUTHCALL; meta-transactions on TRON must be done via contracts or node-level features like Gas Free.

Importantly, TRON’s environment can accommodate a contract-based AA standard without protocol changes. The TVM is EVM-like and supports contract calls; an EntryPoint-like contract can be deployed. Bundlers would be off-chain relayers that pay TRX to call the EntryPoint (recovering funds from users). TRON’s fee model with fixed prices simplifies some aspects: there’s no gas price auction. A UserOperation on TRON needs to specify token/fee limits but not EIP-1559-style fees.

In summary, TRON’s architecture – with multi-key accounts, staking-based fees, and existing gasless mechanisms – provides a solid foundation for an AA standard. We build on these elements, adapting Ethereum’s AA concepts to TRON’s model.

Specification

We outline two complementary approaches for TRON account abstraction: (1) Execution-Abstraction via Bundler/EntryPoint (a full AA model like ERC-4337) and (2) Relayer/Forwarder Meta-Transactions (a lighter model akin to ERC-2771/EIP-3074). Both share the goal of letting users operate smart wallets instead of raw EOAs, but differ in complexity and requirements.

1. Data Structures & Interfaces

  • UserOperation (TRON): A struct that encapsulates a desired transaction from a user’s smart wallet. Fields include:
    • sender (address): the smart-wallet contract address (or a proxy for an EOA’s abstracted account).
    • target (address): the contract to be called (or 0 for account creation).
    • value (uint256): amount of TRX or tokens to send with the call.
    • callData (bytes): calldata for the target (function selector + args).
    • nonce (uint256): anti-replay nonce for this sender.
    • validUntil/validAfter (timestamps): optional time-range when this operation is valid.
    • energyLimit (uint256): the maximum Energy units to allow for execution. (Bandwidth is auto-calculated from tx size.)
    • Fee fields: TRON has no variable gas price; instead we can include:
      • feeToken (address): which token (e.g. USDT or TRX) to use for fees. If zero or TRX, fees paid in TRX (by burning or stake). If a TRC-20 stablecoin, a paymaster contract might cover the fee from that token.
      • maxFee (uint256): maximum fee (in the selected token) that the sender is willing to pay.
    • sessionKey (address, optional): an identifier for a session key (see below).
    • paymaster (address, optional): address of a Paymaster contract sponsoring this operation.
    • paymasterData (bytes, optional): extra data to forward to the Paymaster (if any).
    • signature (bytes): the user’s signature authorizing this UserOperation. The signature scheme can be arbitrary (e.g. ECDSA of a hash of the above fields, or other schemes if the wallet supports it). It must prove that the sender approves this operation.This structure is inspired by ERC-4337’s UserOperation , but we adapt fields to TRON’s model: no gas price fields (TRON fee model is fixed), instead a fee token and max fee field allow gasless or token-pay scenarios.
  • Smart Wallet Interface: Any smart-contract wallet must implement a standard interface so EntryPoint can invoke it. We propose:
interface ITRONSmartWallet {
    // Validate a UserOperation; revert if invalid.
    // Can check signatures, nonces, session keys, and paymaster allowances.
    function validateUserOp(TRONUserOperation calldata op) external view;
    // Execute the operation (sending tokens or calling target) after validation.
    function executeUserOp(TRONUserOperation calldata op) external;
}

In practice, a smart wallet contract’s validateUserOp would check signature, nonces, etc., possibly requiring multiple signer approvals (social recovery), or checking if sessionKey is allowed, etc. After validation passes, the EntryPoint will call executeUserOp, which should carry out target.call{value:op.value}(op.callData). (The wallet contract can encode this logic in its code; EntryPoint may simply delegate via a function call.)

  • EntryPoint Contract: A singleton contract (deployed once on TRON mainnet) that accepts a batch of UserOperations in one call (e.g. handleOps(UserOperation[] ops, address beneficiary)). Its role:
    1. Simulation/Validation: For each UserOperation, it calls the sender’s validateUserOp. This may be done off-chain by the bundler, but on-chain the EntryPoint should also check (via a staticcall) that validation passes. If a paymaster is set, it also calls the paymaster’s validation.
    2. Execution: It then invokes each UserOperation’s execution. Either by calling sender.executeUserOp(op) if the wallet supports it, or by calling the target directly with op.callData (but making sure it’s billed to the wallet). For security, the EntryPoint ensures funds/gas are properly forwarded.
    3. Gas Settlement: The EntryPoint should reimburse the bundler for the consumed gas/fees, by withdrawing from the sender’s or paymaster’s deposit. In TRON’s model, we can simplify: the bundler (who signs the transaction to call handleOps) pays TRX for gas up front (bandwidth+energy). After execution, EntryPoint transfers appropriate tokens/TRX from the wallet or paymaster to the bundler’s address. For example, if feeToken was USDT and paymaster approved it, the EntryPoint can have the user’s wallet send USDT to the bundler, or directly transfer TRX if the wallet held enough.
    4. Record Keeping: The EntryPoint updates nonces, tracks deposits, and emits events for executed UserOperations.This design parallels ERC-4337’s EntryPoint. In TRON’s case, it would be implemented in Solidity (or other TVM language) and deployed like any TRC contract.
  • Bundler (Relayer): An off-chain service (node/operator) that:
    1. Receives UserOperation requests from users (via RPC, frontend, etc.).
    2. Performs off-chain checks (validate signature, nonce, gas estimates).
    3. Submits them to the TRON EntryPoint via handleOps, in one transaction (or multiple).
    4. Pays TRX upfront for the bandwidth/energy of that transaction.
    5. Expects reimbursement (in TRX or tokens) from the EntryPoint. Any surplus (tips) go to the bundler as profit.Unlike Ethereum, TRON does not (yet) have a standard “user operation mempool” RPC. This would rely on third-party infrastructure or a custom relaying network.
  • Paymaster Contracts: Optional contracts that accept to pay fees for user operations. For example, a TRC-20 contract (like USDT) could implement a Paymaster interface: it maintains a balance (either funded by whomever) and, upon a user operation, it pays the required fee in USDT. The EntryPoint would then use those funds to reimburse the bundler. Essentially, a paymaster guarantees gas fees. The EntryPoint requires paymasters to stake/deposit some TRX as collateral, mirroring ERC-4337’s model, so they have “skin in the game”.

2. Execution-Abstraction Flow (Full AA, EIP-4337 Style)

  1. UserOperation Creation: A user’s wallet (smart contract) gathers the desired action (e.g. calling a DApp) and constructs a UserOperation struct. The wallet includes the target contract, calldata, any TRX to send, and signs the operation with its private key(s). It may specify a paymaster (if the wallet uses a sponsoring contract) and max fee. It also includes a nonce. This can be done by a web app or wallet software.
  2. Send to Bundler: The signed UserOperation is sent to a bundler service (similar to how wallets send transactions to RPC nodes). The bundler verifies that the signature is valid and that the wallet’s nonce is correct.
  3. Bundler Calls EntryPoint: The bundler batches one or more UserOperations and sends a TRON transaction to the EntryPoint.handleOps method. In TRON’s JSON-RPC, this is a smart contract call by the bundler’s account. The bundler sets a high feeLimit for this transaction to cover execution costs.
  4. EntryPoint Validation: On-chain, the EntryPoint contract iterates over the batch. For each op:
  • If sender is not yet deployed (i.e. new wallet creation via initCode), it deploys it. (Optional: one could allow deploy-on-demand.)
  • It calls sender.validateUserOp(op). The smart wallet contract checks signatures (possibly multiple), nonces, session key validity, and any paymaster conditions. It should revert if not authorized.
  • If a paymaster is specified, EntryPoint calls paymaster.validatePaymasterOp(op). This ensures the paymaster has enough deposit and approves this operation (for example, the paymaster might check the gas cost vs. what it can cover).
  • If validation fails, the EntryPoint reverts the bundle (or skips that op, depending on design).
  1. EntryPoint Execution: If validation passes, EntryPoint then executes the operation: either by calling sender.executeUserOp(op) (delegating execution to the wallet contract), or by directly invoking target.call{value:op.value}(op.callData) on behalf of the wallet (the wallet contract would implement this). This performs the actual user’s action (like transferring tokens, interacting with a DApp, etc.).
  2. Gas/Fees Settlement: After execution, EntryPoint collects fees. If a paymaster was used, it withdraws the required token or TRX amount from the paymaster’s deposit. Otherwise, it collects from the wallet’s funds (the wallet must have set aside TRX or approved tokens). Then EntryPoint sends the appropriate compensation to the bundler’s address (usually msg.sender of the handleOps call).
  3. Result: The operation has been carried out as if the wallet itself executed it. The user (wallet) saw the action take place on-chain, but did not need to submit a transaction or hold TRX. The bundler is paid for the gas, typically just enough to cover the consumed bandwidth/energy.

This flow mirrors Ethereum’s ERC-4337 scheme but uses TRON’s fee model. For example, instead of specifying “maxFeePerGas”, the UserOperation might specify “maxFee” in TRX or stablecoin units. The EntryPoint simply ensures the bundler’s transaction had enough feeLimit to cover the energy (gas) costs.

3. Relayer-Based Meta-Transactions (EIP-3074-Style, Lightweight)

A simpler, no-fork variant is to implement meta-transactions via a Trusted Forwarder contract (similar to ERC-2771) rather than a full UserOp/bundler system. In this model:

  • A forwarder contract MetaForwarder is deployed on TRON. It has a function (e.g. executeMeta(address from, address to, uint256 value, bytes data, bytes signature)) that verifies a user’s signature over (from, to, value, data).
  • Users pre-sign messages authorizing a call. For example, Alice signs “I authorize sending 10 TRC20 tokens from my account to Bob”.
  • A relayer collects the signature and calls MetaForwarder.executeMeta, which:
    1. Checks the signature is valid for from (the user).
    2. Calls to.call{value: value}(data), but in such a way that to’s contract sees from as the sender (for example by using an isTrustedForwarder pattern).
  • The forwarder then charges the sender from a fee (in TRX or token) if agreed, or withdraws from a deposit.

This is essentially EIP-3074’s concept of an invoker: a contract that acts on behalf of an EOA after authorization. In TRON we cannot add new opcodes easily, but we can mimic the same idea with a forwarder contract. DApps must be written or proxied to trust MetaForwarder (e.g. use _msgSender() that recognizes the forwarder).

This forwarder approach has lower overhead: no new protocol features, no separate mempool, and bundlers can even be integrated into normal TRON transactions (just call the forwarder as part of a contract call). However, it is more limited: it typically handles one operation at a time and does not inherently support batching or advanced paymaster logic (beyond what the forwarder contract implements). Still, it can allow gas sponsorship (the forwarder could be funded by a sponsor) and social recovery (if the forwarder contract includes recovery logic). It’s a viable fallback if TRON does not adopt the full AA model.

4. Session Keys & Social Recovery

Session Keys: A session key is an ephemeral key that a user delegates limited authority to (e.g. for a short time or specific actions). Under this standard, session keys are handled by the smart wallet’s logic. For example, a wallet contract could maintain a list of active session keys with expiration times or gas limits. When validateUserOp is called, it checks if signature corresponds to a stored session key that hasn’t expired. In effect, the session key becomes an authorized signer for that operation. This allows DApps to “log in” with a session key: e.g. a user’s phone app generates a session key for a game, and can transact on the user’s behalf without requiring the master key’s daily use.

Social Recovery: Similarly, a smart wallet contract can embed social recovery: it may hold a set of guardian addresses (trusted friends or devices) that can collectively authorize a wallet state change. If the user loses their primary key, they could coordinate (e.g. 2-of-3 guardians sign) to call a recover() method on the wallet, replacing the user’s key. The AA standard supports this because guardians can sign a special UserOperation for recovery. This is analogous to ideas in EIP-3074 invokers with recovery, but here implemented at the wallet-contract level using TRON’s permission logic. Unlike Ethereum EOAs, TRON accounts can be multi-sign without abstraction – but as noted, enabling that costs TRX. A smart wallet could offer multi-sig and recovery without that on-chain fee.

5. Paymasters and Gas Payment

We accommodate TRON’s unique fee model. A UserOperation may specify a feeToken and maxFee. Common cases:

  • TRX payment: If feeToken is TRX (address zero), the user pays gas in TRX. If the wallet has staked energy/bandwidth, those cover the costs; otherwise TRX is burned. The bundler’s TRX cost is reimbursed from the wallet’s TRX.
  • Token payment (GasFree-like): If feeToken is e.g. the USDT contract, a Paymaster (possibly the USDT contract itself) will cover the TRX fee by deducting USDT. For instance, TRON’s native Gas Free allowed USDT transfers without TRX. In our model, a Paymaster contract could hold USDT and, upon each operation, pay the needed energy/bandwidth fee in TRX (by trading the USDT or using a built-in mechanism). The bundler would then receive USDT as compensation.
  • Sponsored payment: A contract or service (the paymaster) explicitly sponsors a user’s transactions. For example, a DeFi protocol might cover newcomers’ gas. The paymaster would deposit TRX or tokens into the EntryPoint ahead of time (similar to staking) to guarantee it can pay.

This approach fits TRON’s philosophy: e.g. a platform could let users transact with stablecoins only, or let third parties sponsor gas, aligning with TRON’s move to allow non-TRX gas payment.

6. Example Workflow (Gasless Token Transfer)

  1. Alice creates a smart wallet contract (or uses an existing one) and registers a guardian for recovery. She funds it with USDT and possibly stakes some energy.
  2. Alice wants to send 100 USDT (TRC-20) to Bob but has no TRX. She composes a UserOperation: {sender: AliceWallet, target: USDTContract, value:0, callData: transfer(Bob,100), nonce: N, feeToken: USDT, maxFee: 1 USDT, paymaster: USDTContract, ...}. She signs it with her wallet’s private key.
  3. Alice’s app sends this UserOp to a bundler node. The bundler sees Alice chose the USDT contract as paymaster (TRON’s Gas Free feature allows the USDT contract to act as its own paymaster).
  4. The bundler submits EntryPoint.handleOps([AliceOp], beneficiary=BundlerAddr) as a TRON transaction, staking enough TRX for feeLimit.
  5. EntryPoint calls AliceWallet.validateUserOp(op). Alice’s wallet contract checks the signature (valid), nonce (correct), and sees a valid paymaster (the USDT contract). Then it calls the USDT contract’s paymaster hook.
  6. USDT contract’s paymaster logic verifies that Alice has enough USDT deposited (she does). It signs off.
  7. EntryPoint then calls AliceWallet.executeUserOp(op), which does USDTContract.transfer(Bob,100). Bob receives 100 USDT.
  8. The energy/bandwidth is consumed, and since Alice’s wallet had delegated energy, no TRX was burned. Now the EntryPoint finalizes fee payment: it takes (e.g.) 0.0005 TRX worth of USDT from Alice’s approved deposit and transfers it to the bundler (for the gas used). This matches the Gas Free paradigm: Alice paid nothing in TRX, and Bob got his tokens, with the fee taken from the token transfer itself.
  9. Alice’s operation is complete. The guardians/social recovery features didn’t intervene here, but if she had lost her key, she could use her guardian(s) to recover the wallet separately.

This example shows gasless USDT transfer (leveraging TRON’s Gas Free concept) in an AA framework. If Alice had multiple signers, validateUserOp could require 2-of-3 signatures (recovering from a lost key scenario) without needing to pay the 100 TRX update fee.

Requires

  • TRON Virtual Machine (TVM) and Fee Model: Uses standard TRON smart contracts and the existing fee system. No new opcodes or transaction types are required for the full AA variant.
  • New Contracts: Deployment of a standard EntryPoint contract and optional Paymaster contracts. Also smart wallet contracts must implement the AA interface. These are all TRC deployments, feasible today.
  • Backwards Compatibility: Because no consensus changes are mandatory, legacy dApps and wallets remain unaffected. AA features can be introduced purely by adopting these contract standards.
  • Optional Protocol Changes: For the lighter AUTH/AUTHCALL variant to be native, TRON core would need to add new opcodes. This would require a hard fork. We merely suggest it as a possibility (EIP-3074 shows its power). Until then, the relayer/forwarder pattern can simulate AUTH behavior at the contract level.
  • Staking/Resource Sufficiency: Users or paymasters should ensure enough staked TRX (energy/bandwidth) or token deposit to cover fees. Existing TRON staking and delegation APIs suffice.
  • Interface Adoption: DApp contracts that wish to accept meta-transactions may need minor changes (e.g. using _msgSender() logic if using a forwarder).

In essence, implementing this standard only requires that TRON’s current infrastructure (TVM, staking model, multi-key accounts) remain in place. If TRON governance chooses to adopt new AA-friendly features (like AUTH opcodes), this design can evolve to use them, but it works today without them.

Backward Compatibility

This proposal is fully backward compatible with TRON’s current protocol and accounts:

  • No Disruption to EOAs: Regular TRON EOAs and transactions work exactly the same. AA introduces new optional smart-wallet accounts; it does not deprecate or change EOAs. If a user does not use a smart wallet, nothing changes for them.
  • No Mandatory Upgrades: Existing contracts do not need to be rewritten. AA simply adds new wallets and entrypoint contracts that co-exist. DApps unaware of AA will continue to function normally.
  • Contract-Only Changes: All new code is deployed as smart contracts (EntryPoint, wallets, forwarder), so TRON nodes require no updates. Block validation logic remains identical.
  • Fee Model Consistency: TRON’s fee calculations and token mechanics are untouched. Users still pay for bandwidth/energy via staking or TRX burn as before (or via the new AA paymaster tokens), with the same unit costs.
  • Optional AUTH/AUTHCALL: If TRON someday adds Ethereum-style AUTH/AUTHCALL opcodes to allow EOAs to delegate calls directly, that would be an optional enhancement. Until then, everything falls back to contracts. Even if AUTH/AUTHCALL were introduced, existing AA smart wallets could continue to work (and possibly switch to using AUTHCALL internally), preserving compatibility.

Thus, adoption of this standard poses no risk to current TRON functionality. At worst, non-AA transactions simply ignore the new contracts. At best, it provides a new extension that TRON projects can opt into as needed – “paper-ready” for future use even if not immediately active. As one TRON DAO forum proposal notes, such gasless AA is seen as a future enhancement (and must be enabled at the wallet/app level, not forced on users).

Example Workflow

  1. UserAction: A TRON user (Alice) wants to perform an action (e.g. send tokens, interact with a DApp). Instead of sending a normal TRON transaction, her smart-wallet contract will handle it.
  2. Construct UserOperation: Alice’s wallet creates a UserOperation with the intended call. For example, to transfer TRC-20 token to Bob, it sets target = TokenContract, callData = transfer(Bob,amount), etc. It sets a nonce, value if any TRX is sent, and chooses a paymaster (e.g. the token contract) and feeToken.
  3. Sign Operation: Alice signs the operation with her wallet’s key (or keys, if multisig). This authorizes the op without needing a TRON transaction.
  4. Relayer Submission: Alice sends the signed UserOperation (off-chain) to a bundler/relayer service.
  5. Bundler Call: The bundler checks the operation and then submits it on-chain by calling EntryPoint.handleOps with the UserOperation as input. The bundler’s TRON account pays the on-chain fee for this transaction (feeLimit).
  6. Validation: On receiving handleOps, the EntryPoint contract:
  • Calls validateUserOp on Alice’s wallet contract. The wallet verifies the signature(s) and nonce, ensuring Alice authorized this call. It also checks with the specified paymaster (if any) that fees are OK.
  • If a session key or guardians are involved, the wallet’s validation logic handles them here.
  1. Execution: The EntryPoint then invokes the desired action: e.g. it calls the token contract’s transfer on behalf of Alice’s wallet. This has the same effect as if Alice’s wallet had submitted a normal transaction.
  2. Gas Settlement: After execution, the EntryPoint pays the bundler. If Alice used TRX fees, it deducts TRX from her wallet’s deposit. If she used a token/paymaster, it obtains the equivalent fees from the token contract or paymaster. The bundler receives the reimbursement.
  3. Completion: The transaction is now mined. Bob got his tokens, Alice’s intended action is done, and the bundler is compensated. Alice herself never directly spent TRX or broadcast a transaction.

Example Workflow
Example Workflow1342×1438 99.5 KB

This workflow demonstrates how gasless or token-paid transactions can appear native to the user. For example, TRON’s native Gas Free USDT transfer is just one case of this pattern: our AA lets any token or account use the same mechanism.

Conclusion

TRON’s unique architecture – its TVM, resource model, and account features – provides fertile ground for a tailored account-abstraction standard. By adopting a contract-based AA design (EntryPoint, bundlers, smart wallets) and an optional relayer-based variant, TRON can offer the user-friendly benefits of ERC-4337/EIP-3074 in a way that fits TRON specifically.

Crucially, this standard is non-disruptive. It uses the existing TVM and fee rules, so it is backward-compatible. DApps and wallets can opt-in at will. If TRON decides to upgrade with AUTH/AUTHCALL in the future, this framework can evolve accordingly; if not, the smart-contract variant still yields major improvements.

In short, introducing a TRON-native AA standard aligns perfectly with TRON’s goals: it enhances security (social recovery), improves UX (gasless, session keys), and leverages TRON’s resource model for innovation. We conclude that such a standard is well-suited to TRON’s philosophy and can be implemented using TRON’s existing infrastructure, offering a clear path forward for smart-wallet accounts on TRON.

2

This proposal does a solid job adapting ERC-4337 concepts to TRON’s resource model instead of simply porting Ethereum assumptions that don’t really apply to bandwidth and energy.

3

This is a really thoughtful adaptation of account abstraction to TRON’s resource model. I like that it doesn’t try to copy Ethereum 1:1 but actually leans into bandwidth and energy

4

The part about eliminating the 1.1 TRX account activation cost via contract wallets feels huge for onboarding. That alone could improve UX a lot

5

Curious how bundlers would realistically price their services on TRON since there’s no gas auction. Would this end up being more centralized?

6

I appreciate that this is fully backward compatible. Optional standards tend to get adopted much more easily than forced protocol changes

7

The comparison between a full 4337-style approach and a lighter relayer model is helpful. Feels pragmatic instead of ideological

8

The idea of handling session keys purely inside wallet logic feels very clean and flexible. It avoids protocol complexity while still giving dApps a safer way to interact repeatedly without exposing the main key

9

This approach could finally make consumer-facing apps on TRON feel less technical. Users really should not have to understand energy, bandwidth, or staking just to send a token

10

I like that the proposal doesn’t push a single “correct” implementation. Teams can start with a simple forwarder and later migrate to a full EntryPoint model if needed

11

How do you imagine bundlers competing with each other on TRON in practice? Without gas price auctions, what would realistically drive pricing or prioritization?

12

The explanation around social recovery is actually one of the strongest parts here. It clearly shows why smart wallets can be more user-friendly than native multisig

13

The fact that this removes the need to pay 100 TRX just to enable multisig is a big deal. That cost alone has probably discouraged many users from better security setups

14

I’m curious whether wallets would expose AA features automatically or let users opt in per transaction. UX decisions here will matter a lot

15

The EntryPoint contract seems powerful, but it also feels like a natural focal point for risk within the system. Since so much validation and execution logic flows through it, its security assumptions really matter. It would be helpful to see clearer guidance around recommended auditing practices, especially for upgrades over time. I’m also curious whether immutable deployments or carefully scoped upgrade paths are preferred here. Clarifying this could increase confidence for teams building on top of it

16

This feels particularly well-suited for stablecoin-heavy flows, which is already where most TRON activity happens

17

The forwarder-based model reminds me of early meta-transaction systems, but with a noticeably higher level of maturity. The separation of responsibilities between the user, the relayer, and the target contract feels much clearer and more intentional. It avoids some of the ambiguity that caused issues in earlier designs. At the same time, it keeps the implementation lightweight and approachable for teams that don’t need full account abstraction. This balance makes it a practical option rather than just a transitional workaround

18

One thing I appreciate is how clearly this aligns with TRON’s fixed-fee philosophy instead of trying to retrofit Ethereum-style gas logic

19

Would it be possible for wallets to automatically rotate session keys in the background to further reduce long-term risk for users?

20

The paymaster design feels flexible enough to support both dApp-sponsored gas and user-paid token fees without becoming overengineered. It allows different business models to coexist, from onboarding subsidies to fully user-funded transactions. I also like that it aligns naturally with TRON’s existing Gas Free concepts rather than introducing something entirely new. This makes it easier for developers to reason about costs and incentives. Overall, it strikes a good balance between power and simplicity