Is your feature request related to a problem?
Yes. I have already opened an issue in java-tron requesting official ERC-4337 support with a canonical EntryPoint contract (see link below).
Once the protocol side supports Account Abstraction, developers will need a clean, high-level way in TronWeb to work with Smart Accounts (programmable wallets). Currently, TronWeb only offers low-level EOA APIs. Without an official abstraction, every project will have to reinvent the wheel for gasless transactions, batch operations, paymasters, social recovery, and AI-agent compatible accounts.
Description of the solution you'd like
I would like TronWeb to add a high-level Smart Account abstraction, inspired by viem's toSmartAccount design.
The goal is to provide a unified, extensible API that allows developers to create and use custom Smart Accounts easily, while staying consistent with Tron’s transaction format, Energy/Bandwidth model, and future ERC-4337 UserOperation flow.
Key desired characteristics:
- It should be extensible so developers can implement their own Smart Account logic (getAddress, encode/decode calls, signUserOperation, getNonce, etc.).
- It should integrate smoothly with existing TronWeb instances.
- Once a canonical EntryPoint is deployed (as requested in java-tron), it should support standard ERC-4337 patterns where possible.
- Provide good TypeScript support and clear documentation.
Preferred naming could be toSmartAccount (to maximize familiarity for Ethereum developers migrating to Tron) or a Tron-native name like createTronSmartAccount.
Proposed API example:
import { toSmartAccount } from 'tronweb/smart-account'
const smartAccount = await toSmartAccount({
tronWeb, // current TronWeb instance
entryPoint: {
address: '0x...',
version: '0.7'
},
async getAddress(): Promise<string>,
async encodeCalls(calls: any[]): Promise<string>,
async signUserOperation(userOp: any): Promise<string>,
// ... other required methods
})Why this matters for the TRON ecosystem
- Makes TRON much more attractive for modern dApps, especially those targeting better UX (gasless, batching, session keys, AI agents).
- Aligns with the growing demand for Account Abstraction seen across other chains.
- Reduces fragmentation — all developers can build on the same official abstraction instead of creating incompatible custom solutions.
- Prepares TronWeb for the upcoming ERC-4337 features requested in java-tron.
Additional context
I am willing to contribute to the design discussion, provide feedback, or even help with a PR once the java-tron side makes progress.
Looking forward to the team’s thoughts on this!
Is your feature request related to a problem?
Yes. I have already opened an issue in java-tron requesting official ERC-4337 support with a canonical EntryPoint contract (see link below).
Once the protocol side supports Account Abstraction, developers will need a clean, high-level way in TronWeb to work with Smart Accounts (programmable wallets). Currently, TronWeb only offers low-level EOA APIs. Without an official abstraction, every project will have to reinvent the wheel for gasless transactions, batch operations, paymasters, social recovery, and AI-agent compatible accounts.
Description of the solution you'd like
I would like TronWeb to add a high-level Smart Account abstraction, inspired by viem's
toSmartAccountdesign.The goal is to provide a unified, extensible API that allows developers to create and use custom Smart Accounts easily, while staying consistent with Tron’s transaction format, Energy/Bandwidth model, and future ERC-4337 UserOperation flow.
Key desired characteristics:
Preferred naming could be
toSmartAccount(to maximize familiarity for Ethereum developers migrating to Tron) or a Tron-native name likecreateTronSmartAccount.Proposed API example:
Why this matters for the TRON ecosystem
Additional context
I am willing to contribute to the design discussion, provide feedback, or even help with a PR once the java-tron side makes progress.
Looking forward to the team’s thoughts on this!