Repository navigation
[Feature] Official ERC-4337 Support with Canonical EntryPoint for ERC-7710, ERC-7715 and AI-Powered Applications #6647
Description
Problem Statement
The rapid growth of AI-powered applications in the crypto space — including autonomous AI agents, intelligent trading bots, AI-driven DeFi tools, and session-based assistants — is driving massive demand for programmable smart accounts. These applications heavily rely on ERC-4337 Account Abstraction as the foundation, along with two important extension standards:
- ERC-7710: Smart Contract Delegation — Standardizes safe delegation of specific permissions and capabilities from smart contract accounts.
- ERC-7715: Request Permissions from Wallets — Defines a standard JSON-RPC method (
wallet_grantPermissions) for dApps to request granular permissions, which are then redeemed via ERC-7710 delegations.
To build reliable infrastructure (smart wallets, bundlers, paymasters, and AI agents) on Tron, a trusted, official EntryPoint contract is essential — similar to the canonical EntryPoint deployed on Ethereum and other major EVM-compatible chains. Without an official one, developers are forced to rely on third-party or community deployments, which introduces significant trust, security, and interoperability risks, especially for high-value AI use cases.
Who would benefit: Developers building next-generation AI-native dApps, wallet providers, bundler operators, and the entire Tron ecosystem that wants to remain competitive in the fast-growing AI + crypto narrative.
Proposed Solution
Request the Tron core team / java-tron maintainers to:
- Officially support ERC-4337 Account Abstraction on the Tron network.
- Deploy and maintain a canonical (official) EntryPoint contract with a well-known fixed address.
- Consider including support for ERC-7710 and ERC-7715 delegation features on top of ERC-4337 in the roadmap.
This would provide a single trusted entry point for all UserOperations and enable seamless ecosystem-wide adoption.
Specification
- Deploy the latest stable ERC-4337 EntryPoint contract (v0.6 or v0.7 recommended for maximum compatibility) using deterministic deployment (e.g., CREATE2) to ensure a predictable address.
- Ensure full compatibility with standard ERC-4337 bundlers, paymasters, and smart account implementations.
- No core protocol changes required (ERC-4337 operates entirely at the smart contract layer).
- Support ERC-7710 delegation redemption interfaces and ERC-7715 permission request flows where applicable.
API Changes (if applicable):
None required at the protocol level. Existing EVM-compatible RPC methods (eth_sendUserOperation, eth_estimateUserOperationGas, etc.) should be supported if not already available.
Configuration Changes (if applicable):
None.
Protocol Changes (if applicable):
None (pure smart contract layer implementation).
Scope of Impact
- Smart contracts (official EntryPoint deployment)
- API/RPC (optional enhanced UserOperation support)
- Documentation
- Others: Ecosystem tooling (bundlers, wallets, AI agent frameworks)
Breaking Changes
No breaking changes.
Backward Compatibility
Fully backward compatible. Existing EOAs, transactions, and smart contracts remain completely unaffected. This is an additive feature.
Implementation
Do you have ideas regarding the implementation?
Yes. Deploy the audited EntryPoint contract from the official account-abstraction repository (https://github.com/eth-infinitism/account-abstraction) using a deterministic salt for consistent addressing. Publicly announce the official address and maintain it long-term.
Are you willing to implement this feature?
I am happy to assist with testing, documentation, community coordination, or validation on the testnet, but the official deployment and long-term maintenance should be handled by the Tron core team to ensure maximum trust and ecosystem adoption.
Estimated Complexity
Medium (mainly contract deployment, documentation, and possible minor RPC enhancements; no consensus or protocol changes needed).
Testing Strategy
Deploy first on the Nile testnet and verify compatibility with popular ERC-4337 bundlers and smart account libraries. Test the complete UserOperation lifecycle, paymaster sponsorship, and delegation flows.
Test Scenarios
- Basic UserOperation submission and execution
- Paymaster-sponsored transactions
- ERC-7710 delegation creation and redemption
- ERC-7715 permission request + redemption flow
- Session key usage for AI agents
Performance Considerations
Minimal on-chain overhead per UserOperation. Off-chain bundling should scale efficiently on Tron's high-throughput network.
Alternatives Considered (Optional)
- Relying on community-deployed EntryPoint contracts (not ideal due to trust and fragmentation risks)
- Developing a fully custom Tron-native Account Abstraction solution (valuable long-term, but ERC-4337 compatibility remains highly beneficial for interoperability)
Additional Context (Optional)
The combination of ERC-4337 + ERC-7710/ERC-7715 is becoming critical infrastructure for building user-friendly, permissioned AI agents that can act autonomously within safe, predefined limits without exposing private keys. Official support would significantly strengthen Tron's position in the rapidly expanding AI + crypto ecosystem.
Related Issues/PRs
References
- ERC-4337: https://eips.ethereum.org/EIPS/eip-4337
- ERC-7710: https://eips.ethereum.org/EIPS/eip-7710
- ERC-7715: https://eips.ethereum.org/EIPS/eip-7715
- Official Account Abstraction repository: https://github.com/eth-infinitism/account-abstraction
Activity
zeusoo001 commentedon Apr 7, 2026
@FinchAlex Is Tron EVM fully compatible with the latest version of ERC-4337? How to incentivize developers and the community to use the official EntryPoint instead of third-party deployments? Is there a need to provide examples, documentation, toolchains, or testnet support?
waynercheung commentedon Apr 7, 2026
@FinchAlex This looks like a meaningful direction for TRON, especially as more wallet, agent, and permissioned execution use cases emerge around ERC-4337-style account abstraction.
To help the discussion move forward constructively, it may be useful to clarify the scope a bit, since the proposal currently touches several different layers at once:
EntryPointjava-tron/ node compatibility with ERC-4337 contracts and toolingeth_sendUserOperationA few questions that might help the maintainers evaluate this more clearly:
EntryPoint(for example v0.6 or v0.7), or would some adaptation be needed?CREATE2,chainId, fee model, or transaction submission flow?java-tron, or would it be better handled as a separate official service / reference implementation?A possible path could be:
EntryPointEntryPointon Nile and publish the addressThis may help separate what belongs in core node support, what belongs in ecosystem tooling, and what belongs in wallet/provider standards, while still keeping the overall goal aligned.
lily309 commentedon Apr 8, 2026
EntryPoint currently in use by certain project teams: https://tronscan.org/#/contract/TAdf98Cvp29FxBvV9U2D6XzT1oKoToCqSJ/code
lvs0075 commentedon Apr 9, 2026
The proposal mixes concerns across different layers. From a java-tron perspective, the relevant scope is limited:
Suggest splitting into three separate tracks: (1) TVM compatibility verification, (2) official EntryPoint deployment on testnet, (3) bundler reference implementation. ERC-7710/7715 can be a follow-up once the foundation is stable.
itxtoledo commentedon Apr 13, 2026
We are building a multichain wallet with AA. We would really like Tron to support this. And we would be one of the first to use this with Paraguayan and Brazilian users. We use USDT a lot here and this would be very good.
lxcmyf commentedon May 13, 2026
I checked this against the current
java-tronimplementation. I think this proposal is useful, but it should be split into a few concrete compatibility tracks so it is clear what belongs injava-tronand what belongs in ecosystem tooling.From the node side:
CREATE2,CHAINID,BASEFEE/energy-fee related behavior, and Ethereum-compatible JSON-RPC methods likeeth_call,eth_estimateGas,eth_chainId, logs/receipt queries, etc.eth_sendRawTransactionis currently exposed as unsupported inTronJsonRpcImpl, and I do not seeeth_sendUserOperation/eth_estimateUserOperationGassupport injava-tron.CREATE2deterministic deployment also needs TRON-specific validation/documentation because the address derivation uses TRON address conventions/prefixes, so a canonical EntryPoint address should be treated as a TRON canonical address, not assumed to match Ethereum’s canonical address directly.So from a
java-tronperspective, I suggest the first actionable step should be a compatibility verification matrix rather than committing everything as one feature:chainId,CREATE2, logs, and revert-data behavior.eth_sendUserOperationandeth_estimateUserOperationGasshould live outsidejava-tronas a dedicated bundler/reference service, or whether any node-level JSON-RPC additions are actually required.ERC-7710 / ERC-7715 probably should be tracked separately after the ERC-4337 EntryPoint and bundler path are validated, since those are wallet/provider/delegation flows rather than core node compatibility work.
This would make the issue more actionable for
java-tron: first prove TVM/RPC compatibility with the official EntryPoint on testnet, then publish the canonical deployment details and decide whether any node changes are needed.EllenWhitmore commentedon May 18, 2026
Adding a developer voice in support — an officially-deployed canonical EntryPoint is something the TRON ecosystem has needed for a while, and I'd really like to see it land. I maintain an account-abstraction integration across several EVM chains, and on every other chain integration is a one-line config change. On TRON it's currently a multi-week security conversation because no one fully trusts the third-party deployments, and that friction is the real reason most AA-native teams skip the chain — not the technology, just the trust gap.
lxcmyf commentedon May 20, 2026
Following up on my earlier comment, I think the next step should be kept narrow and concrete.
From the
java-tronside, this issue should first verify ERC-4337 compatibility rather than combine EntryPoint deployment, bundler APIs, ERC-7710, and ERC-7715 into one scope.Suggested next steps:
CREATE2,chainId, energy/fee model, logs, receipts, and revert data.This should make the issue actionable for
java-tron: first prove TVM/RPC compatibility, then decide whether any node-level changes are needed.halibobo1205 commentedon May 27, 2026
@lxcmyf, is there any update?
lxcmyf commentedon May 27, 2026
@halibobo1205
The issue is still pending further confirmation on the ERC-4337 compatibility scope. I think the next useful step is still to first clarify the EntryPoint version and the Nile testnet validation plan before discussing any
java-troncode changes.ERC-7710 / ERC-7715 can remain as follow-up topics after the ERC-4337 path is clearer.
lxcmyf commentedon May 29, 2026
The ERC-4337 discussion has now moved to the TIP track:
tronprotocol/tips#881
I think it makes sense to continue the design discussion there first, especially around EntryPoint version, TRON-specific gas/energy mapping, bundler behavior, and whether any node-level JSON-RPC changes are actually required.
For this
java-tronissue, we can keep it as the implementation/compatibility follow-up after the TIP scope becomes clearer.halibobo1205 commentedon Jun 3, 2026
Status update: this issue is blocked on tronprotocol/tips#881. We won't have further discussion or progress until the TIP has a concrete design.
seunlanlege commentedon Jun 8, 2026
Going to add that ERC-4337 is useless without EIP-7702
lxcmyf commentedon Jul 9, 2026
Progress on this issue depends on TIP-4337 (tronprotocol/tips#881) — EntryPoint version/address/governance, bundler RPC needs, the energy/bandwidth ↔ gas mapping, and how 4337 fits with TRON's native permissions are all being scoped there. Let's keep #6647 as the downstream implementation/compatibility follow-up until that TIP has a concrete design.
On 4337 vs 7702: they're complementary, not a hard dependency — 4337 works with smart-contract accounts on its own, while 7702 mainly removes the EOA-migration friction (EntryPoint v0.8 aligns with it). Which combination TRON should adopt is itself an open item in #881 and is best discussed there.
lxcmyf commentedon Sep 3, 2026
The ERC-4337 design discussion for TRON is now centralized in tronprotocol/tips#881, including the EntryPoint version and governance, bundler/RPC requirements, Energy/Bandwidth mapping, and its relationship with TRON’s native permissions and TIP-7702.
Please continue any further design discussion, proposals, or new questions in #881 to avoid maintaining parallel threads.
This issue will remain blocked as a downstream
java-tronimplementation and compatibility tracker until the TIP defines a concrete design. Once the scope is settled, we will either update this issue with actionable implementation tasks or close it in favor of more specific follow-up issues.