[Feature] Official ERC-4337 Support with Canonical EntryPoint for ERC-7710, ERC-7715 and AI-Powered Applications

[FinchAlex]

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:

1. Officially support ERC-4337 Account Abstraction on the Tron network.
2. Deploy and maintain a canonical (official) EntryPoint contract with a well-known fixed address.
3. 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

[zeusoo001]

@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]

@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:

• official deployment and maintenance of a canonical EntryPoint
• java-tron / node compatibility with ERC-4337 contracts and tooling
• bundler-facing APIs such as eth_sendUserOperation
• wallet/provider standards such as ERC-7715
• delegation-related flows such as ERC-7710

A few questions that might help the maintainers evaluate this more clearly:

• Is TVM already compatible with the latest audited ERC-4337 EntryPoint (for example v0.6 or v0.7), or would some adaptation be needed?
• Are there any TRON-specific differences that developers should account for when aiming for ERC-4337 compatibility, such as address derivation, CREATE2, chainId, fee model, or transaction submission flow?
• Would bundler support be considered part of java-tron, or would it be better handled as a separate official service / reference implementation?
• Since ERC-7715 is wallet-facing, would it make sense to track wallet permission APIs separately from core/node support?
• If the team is open to this direction, would a Nile testnet deployment plus documentation/examples be a good first step before discussing mainnet standardization?

A possible path could be:

1. Verify compatibility of the current TVM / RPC stack with the latest EntryPoint
2. Deploy an official testnet EntryPoint on Nile and publish the address
3. Validate it with common smart account / bundler flows
4. Document the recommended integration path for wallets, bundlers, and developers
5. Evaluate ERC-7710 / ERC-7715 as follow-up workstreams if needed

This 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]

EntryPoint currently in use by certain project teams: https://tronscan.org/#/contract/TAdf98Cvp29FxBvV9U2D6XzT1oKoToCqSJ/code

[lvs0075]

The proposal mixes concerns across different layers. From a java-tron perspective, the relevant scope is limited:

• Node layer: ensure eth_sendRawTransaction and related RPC methods handle UserOperation-format calldata correctly — this is likely already working if TVM is EVM-compatible
• EntryPoint deployment: this is a smart contract deployment task, not a java-tron code change; it can be tracked separately
• Bundler API (eth_sendUserOperation etc.): this requires a dedicated bundler service, not changes to the node

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.