[Feature Request] Add high-level Smart Account abstraction (toSmartAccount / createSmartAccount) aligned with viem, following java-tron ERC-4337 support

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

• Related java-tron issue: https://github.com/tronprotocol/java-tron/issues/6647
• Reference design: viem’s toSmartAccount (https://viem.sh/docs/account-abstraction/accounts/smart/toSmartAccount.html)
• TronWeb is currently evolving toward better TypeScript support (v6.x), making this the ideal time to introduce a modern Smart Account module.

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!

Start by reviewing the proposed tronweb/smart-account entry point, viem’s toSmartAccount reference, and the related java-tron issue. Then compare the proposal with TronWeb’s existing low-level EOA APIs. The work is not ready for implementation until the Smart Account API, ERC-4337 dependency, and acceptance criteria are agreed.