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.

[yanghang8612]

@EllenWhitmore The recovery and onboarding gaps are the clearest justification for 4337 over native permissions — neither has a clean wallet-layer fix today. A standard paymaster interface is what lets the ecosystem subsidize first-touch UX predictably instead of per-token hacks, and programmable validation is the only non-custodial answer to lost-access recovery. The energy/bandwidth mapping is the hard part (acknowledged), but those UX wins are exactly what the cost table in V1 is meant to make concrete — so we prioritize the flows where 4337 actually earns its complexity.

[yanghang8612]

@BlackChar92 Right that the contract interface without a shared off-chain model just fragments wallets around private bundler/paymaster integrations. V1 will carry a non-normative "TRON operating model" section covering exactly your list: pricing UserOperations across energy + bandwidth, the maxFeePerGas == maxPriorityFeePerGas convention, EntryPoint liquid deposit vs staked energy, paymaster rejection reason codes, and a minimal ERC-7562-style validation-rule set adapted to TVM. On a standard UserOperation RPC — leaning "specify the shape, recommend not require," so wallet/exchange bundlers can ship without a public mempool initially.

[yanghang8612]

@lmveublue The trust-boundary point is the most important TRON-specific piece. Bundlers will initially be run by wallets/exchanges/payment providers, not an open network — V1 should say so plainly and define what the wallet MUST disclose: which bundler/paymaster service, who's liable for failure, and whether an operation is actually on-chain vs only queued off-chain. I'll make that last item a normative "submission transparency" requirement. And agreed on the cost comparison — normal transfer, TRC-20, batch, first-action-without-TRX, recovery — precisely to mark where 4337 is worth it and where native permissions or TRC-3009 (#883) suffice.

[warku123]

A follow-up on the preVerificationGas mapping — specifically the bandwidth part, want to check my understanding.

On Ethereum the cost EntryPoint can't measure with gasleft() (calldata + overhead) is still gas, the same unit it reimburses in. On TRON that bucket also holds bandwidth, which seems to be settled outside the VM: in Manager.processTransaction, consumeBandwidth() runs before trace.exec(), charged at the tx level against the bundler by serialized tx size, and never surfaced to the contract. Energy is readable inside the VM (GAS, GASPRICE/BASEFEE) because it's the VM's own meter; bandwidth isn't. So it looks like EntryPoint can measure and reimburse energy on-chain, but the bandwidth component stays invisible — exposing it would need a TRON-specific opcode, which works against the portability that motivates 4337.

If that's right, how would the bandwidth part of preVerificationGas be bounded or validated, given EntryPoint can't observe actual bandwidth on-chain? Or am I missing a path where it can be accounted for on-chain?

[yanghang8612]

@warku123 Your read of the mechanics is correct — bandwidth is settled at the tx level against the bundler by serialized size, before VM execution, and isn't exposed to the VM the way energy is. But I don't think it breaks the mapping, because of one thing that's easy to miss about preVerificationGas: on Ethereum it isn't measured on-chain either.

EntryPoint can't gasleft()-measure the calldata + outer-overhead bucket on Ethereum any more than it can measure bandwidth on TRON. What it does is bound, not measure: preVerificationGas is computed off-chain by the bundler (the spec deliberately doesn't specify a canonical way to estimate it), signed over as part of the UserOp, and folded in as a flat addend. The account's total payment is then bounded by the signed prefund envelope — (accountGasLimits + preVerificationGas) × maxFeePerGas, all signed fields — not by EntryPoint re-deriving the bucket. Two protections, both signature/off-chain based:

• Account side — the signature. In v0.7 the encoded userOp hashed for signing (UserOperationLib.encode) covers accountGasLimits, preVerificationGas, gasFees, and paymasterAndData; only signature is excluded. So the bundler can't change preVerificationGas after signing, and the account can never be charged more than the prefund envelope it signed — regardless of the bundler's actual cost.
• Bundler side — admission policy. A bundler that accepts a UserOp whose preVerificationGas underestimates its real outer cost just loses money, so it rejects underpaying ops off-chain — exactly as on Ethereum.

So the bandwidth component fits the same model. One correction to how I'd put the determinism: the chargeable-bandwidth unit is a deterministic, execution-path-independent function of serialized size — on par with Ethereum's EIP-2028 calldata-gas, not cleaner than it. The genuinely messy part (outer/overhead estimation) is the same on both chains.

Where TRON does differ — and this is worth being explicit about — is that the bundler's actual burned bandwidth can diverge from the nominal size × bandwidthPrice, for three TRON-specific reasons: (1) the free daily bandwidth allowance, (2) staked/delegated bandwidth, and (3) a governance-adjustable bandwidthPrice that can move between signing and inclusion. EntryPoint can observe none of these. But note the direction: this only makes the bundler's real cost lower or higher than nominal — it never lets the account be charged above its signed envelope. It's the same risk shape as Ethereum basefee movement against preVerificationGas, which bundlers already price into admission; not a new on-chain enforcement gap on the account side.

What that means for the TIP: define a nominal chargeable-bandwidth component — a deterministic function of the exact serialized transaction size (with the serialization / result-accounting rule spelled out, not just "tx size"), converted to sun and then to the energy-equivalent at the signed sun-per-energy rate, folded into preVerificationGas alongside outer-call overhead. Everything stays in the single energy unit EntryPoint reimburses in, and the signer can verify it off-chain before signing. It explicitly does not promise exact reconciliation against burned bandwidth (free/staked/price effects make that unobservable on-chain) — the bundler carries that basis risk, same as on Ethereum.

Net: bandwidth is bounded by (signed prefund envelope) + (bundler admission policy) — the same two mechanisms that bound Ethereum's unmeasurable calldata bucket — with a TRON nominal-conversion rule the spec defines. Exposing actual bandwidth on-chain would need a TRON-specific VM interface (opcode/precompile/system call), which is exactly the portability cost we want to avoid. I'll add this to the operating-model section.