Track and Introduce ERC-4337 Account Abstraction Using Alt Mempool to TRON

[yanghang8612]

Background

ERC-4337 provides account abstraction without protocol/consensus changes. Users operate smart contract accounts with programmable validation/execution, signing a higher-level UserOperation gossiped in a separate alt mempool; bundlers batch UserOperations into ordinary transactions sent to a singleton EntryPoint contract, which verifies and executes them. Paymasters sponsor fees, account factories enable counterfactual (deploy-on-first-use) accounts, and signature aggregators enable aggregated signature validation for compatible accounts. This unlocks arbitrary signature schemes (e.g., passkeys/secp256r1), fee sponsorship, batching, session keys, and social recovery — all at the application layer.

TRON already has a native account permission system — weighted multi-sig and per-operation permissions (TIP-16, TIP-105) — covering part of this space, but without programmable validation (arbitrary signatures), application-layer sponsorship beyond the native model, counterfactual deployment, or a shared smart-account tooling ecosystem. We propose to track ERC-4337 and introduce it to TRON as a TIP (proposed TIP-4337) to evaluate how much of the EVM AA stack to adopt and how it should interact with native features. Because 4337 is partly infrastructure (mempool/bundlers) rather than a pure contract interface, the initial focus is the on-chain pieces (EntryPoint, account/paymaster interfaces, UserOperation) plus scoping the off-chain infrastructure TRON requires.

Scope

• Follow ERC-4337's on-chain interfaces (EntryPoint, account validation, paymaster, UserOperation) as closely as possible.
• Choose a target EntryPoint version and document the ABI impact (v0.6 uses an unpacked UserOperation; v0.7+ uses PackedUserOperation; v0.8 aligns with EIP-7702), and align the account surface with the ERC-7579 track.
• Document — as non-normative discussion — how bundling, the alt mempool, and fee handling map onto TRON, since these differ structurally from Ethereum.

Compatibility Topics for Discussion

• Native account abstraction & EIP-7702 overlap. TRON's native permissions (TIP-16/TIP-105) already offer weighted multi-sig and scoped permissions, and TIP-7702 (#728) is a separate path giving EOAs programmable code. Open: what does 4337 add beyond native permissions — arbitrary signatures (passkeys via TIP-7951 (#785)), application-layer sponsorship, counterfactual deployment, session keys — and which are worth the complexity; should TRON pursue 4337, 7702, native enhancements, or a combination; can a 4337 account also be a native-permission account.
• Energy/Bandwidth vs. UserOperation gas fields. A UserOperation carries callGasLimit/verificationGasLimit/preVerificationGas/maxFeePerGas/maxPriorityFeePerGas, but TRON has no EIP-1559 priority market and meters execution in energy (staked or burned TRX) while charging calldata/transport in bandwidth (a separate fee track). How these map — callGasLimit/verificationGasLimit to energy, preVerificationGas to per-operation outer overhead (which on TRON includes bandwidth) — what maxFeePerGas/maxPriorityFeePerGas mean without a fee auction, and how EntryPoint settles costs and refunds against its deposit balances (bandwidth is not refunded through EntryPoint).
• UserOperation hash, signing, and address encoding. How userOpHash is constructed and bound to a TRON network: the TIP-712 domain strips the 0x41 address prefix and uses chainId = block.chainid & 0xffffffff, which affects the operation hash, EntryPoint domain binding, and cross-network/cross-chain replay protection.
• Native sponsorship & paymaster funding. TRON contracts can already subsidize callers' energy via the deployer-configurable consume_user_resource_percent — protocol-level sponsorship without a paymaster. How a 4337 paymaster relates to or competes with this and whether it is even necessary for simple sponsorship (vs. only conditional/token-fee cases); and how paymaster funding works given that an EntryPoint deposit is a liquid, on-demand balance whereas Stake 2.0 (TIP-467) provides energy with lock/unlock delays — these are distinct and should not be conflated.
• EntryPoint singleton: deployment, version, governance. TVM CREATE2 yields a 0x41-prefixed address, so Ethereum's canonical EntryPoint address can't be reproduced — what is TRON's canonical EntryPoint deployment, who governs/audits it, which version to target (weighing unpacked v0.6 vs. PackedUserOperation v0.7+ vs. v0.8/EIP-7702 alignment vs. ERC-7579 compatibility and migration path), and how cross-version upgrades are handled.
• Bundlers and the alt mempool. TRON uses Super Representative block production with no Ethereum-style public fee-priority mempool. Whether bundlers just submit normal TriggerSmartContract transactions to EntryPoint with the alt mempool kept off-chain, what their economic incentive is without a priority-fee market (relayer fees, sponsorship, service operation), and whether any node/SR-side support (e.g., a UserOperation RPC) is needed.
• tx.origin semantics under bundling. With a bundler, tx.origin is the bundler and msg.sender is the account — neither is the user's key. Existing TRON contracts that gate on tx.origin == msg.sender or read tx.origin for access control behave differently when invoked via a 4337 account; the TIP should surface this and recommend msg.sender + TIP-1271 patterns.
• Validation rules (ERC-7562). To keep the alt mempool DoS-resistant, 4337 uses tiered validation rules that are stake- and reputation-aware (not a static opcode blacklist) — restrictions on opcodes/storage access during validation depend on whether the entity is staked. How to map these rules, reputation, and staking onto TVM, and how to retune limits given energy/bandwidth-based DoS economics (specific opcode examples to be filled once a target version is chosen).
• Cost overhead on TRON (open). Given bandwidth-priced calldata and native sponsorship, whether the per-operation overhead of routing through EntryPoint is materially different from Ethereum, and whether it changes the 4337-vs-native-permissions trade-off for common flows (simple transfers, approvals).

References

• ERC-4337: https://eips.ethereum.org/EIPS/eip-4337 · ERC-7562: https://eips.ethereum.org/EIPS/eip-7562
• TIP-7702 (tracking issue #728), TIP-7951 (#785), TRC-2771 (tracking issue #852)
• Native account model: TIP-16, TIP-105; TIP-712, TIP-1271, TIP-467
• Related TRON track: ERC-7579 modular smart accounts tracking issue (Track and Introduce ERC-7579 Minimal Modular Smart Accounts to TRON #880)

[ouy95917]

Three EntryPoint versions exist (v0.6 unpacked, v0.7+ packed, v0.8 aligns with 7702). With TIP-7702 still under design on TRON (#728), how does the team think about the EntryPoint version target? Locking v0.6 keeps things simple but ages quickly; jumping to v0.8 couples 4337 to 7702, which may not ship simultaneously. Ship a specific version, or leave the EntryPoint as a versioned parameter?

[yanghang8612]

@ouy95917 Most consequential roadmap call on this TIP. Direction:

• Target v0.7 PackedUserOperation as the V1 surface. Reasons:
  • v0.7 has the broadest current production deployment on Ethereum and L2s — bundler SDKs, paymaster contracts, account libraries all stable around it. v0.6's unpacked layout is being retired; building TRON on v0.6 inherits a known-deprecated ABI on day one.
  • v0.8 explicitly couples to EIP-7702. With TIP-7702: Add a new tx type that permanently sets the code for an EOA #728 still scoping the TRON variant of 7702, locking V1 to v0.8 would either delay 4337 indefinitely or force the 7702 design to follow 4337's timing. v0.7 lets the two tracks proceed independently.
• EntryPoint address and version will be specified normatively in the TIP, not left as ecosystem parameter. Different EntryPoints across wallets = no portable accounts, defeats the whole point.
• A future TIP can bump to v0.8 (or whatever 7702-aligned version exists then) once TIP-7702: Add a new tx type that permanently sets the code for an EOA #728 lands.

[lily309]

UserOperation carries five gas/fee fields tuned for EIP-1559 — callGasLimit / verificationGasLimit / preVerificationGas / maxFeePerGas / maxPriorityFeePerGas. TRON has no priority market and splits cost into energy (staked/burned) and bandwidth (separate track). How are these mapped? Are the maxFeePerGas fields simply ignored, or do they need to be enforced for ABI parity?

[yanghang8612]

@lily309 Mapping plan:

• callGasLimit and verificationGasLimit → energy budgets. Only two fields where upstream semantics map cleanly: a per-call execution budget enforced by EntryPoint. They become an energy cap each. The TIP defines the unit explicitly (energy, not gas — same numeric type, different semantics) and requires the EntryPoint to enforce them as energy limits.
• preVerificationGas → outer overhead in energy. Covers calldata + bundler outer-tx cost on Ethereum; on TRON it folds calldata bandwidth (converted via 100 sun/byte) and outer-call overhead together. Bundlers compute it and account holders sign over it just like upstream.
• maxFeePerGas / maxPriorityFeePerGas are the lossy fields. TRON has no priority market, so maxPriorityFeePerGas has nothing to enforce. The TIP requires both fields to be present (ABI parity with v0.7 PackedUserOperation matters — bundler SDKs assume the layout), but normatively MUST be set to the same value, representing the maximum sun-per-energy the signer is willing to pay. EntryPoint validates and rejects transactions whose effective rate would exceed it.
• Result: bundler libraries, paymaster contracts, account validation code port without ABI changes; the semantic differences live entirely in EntryPoint implementation.

[EllenWhitmore]

Native TIP-16 / TIP-105 permissions cover part of what we need, but they leave gaps the wallet layer genuinely can't close. Account recovery is probably the most painful one: there's just no clean answer today for a user who loses access, and programmable validation would finally give us a real story there without going custodial.

Onboarding is the other big one. The "first action is impossible without TRX" problem doesn't have a good fix at the wallet level — we can hack around it case by case, but a standard paymaster interface would let the broader ecosystem subsidize first-touch UX in a normal, predictable way.

Batching matters too. Multi-step flows are still multi-confirmation, multi-fee experiences today, and a lot of users drop off somewhere in the middle. Counterfactual deployment would also clean up a few flows we've been working around.

The energy/bandwidth mapping work isn't trivial, we get that. But the upside for end-user UX is substantial. Would really like to see this prioritized.

[BlackChar92]

Support prioritizing TIP-4337. Native TIP-16/TIP-105 permissions are valuable, but they do not cover programmable validation, standardized paymasters, counterfactual deployment, batching, or recovery flows.

One suggestion for V1: alongside the v0.7 EntryPoint target, include non-normative bundler/paymaster operating guidance for TRON — pricing UserOperations across energy + bandwidth, handling maxFeePerGas == maxPriorityFeePerGas, maintaining liquid EntryPoint deposits vs staked energy, paymaster rejection reason codes, minimal ERC-7562-style anti-DoS rules for TVM, and whether a standard UserOperation RPC is expected.

The contract interface alone is not enough for interoperability here; without a shared off-chain operating model, wallets will likely fragment around private bundler/paymaster integrations.

[lmveublue]

Support moving forward with 4337, but V1 should be explicit about the trust boundary on TRON.

On TRON, bundlers may initially be operated by wallets, exchanges, or payment providers, rather than by a fully open public network. That is workable, but the standard should say what this means for users and wallets: which bundler/paymaster service is being used, who is responsible for failures, whether an operation has actually been submitted on-chain, or whether it is only queued off-chain.

I also suggest adding a practical cost comparison for common flows: normal transfer, TRC-20 transfer, batch operation, first action without TRX, and account recovery. That would help clarify where 4337 is genuinely useful, and where native permissions or simpler token-level standards are enough.