[Discussion] TIP-8004: Introduce ERC-8004 Agent Identity / Reputation / Validation Registry + X402 Proof-of-Execution Support for TRON

[boboliu-1010]

[Discussion] TIP-8004: Introduce ERC-8004 Agent Identity / Reputation / Validation Registry + X402 Proof-of-Execution Support for TRON

This issue opens the community discussion for TIP-8004: Agent Identity, Reputation, Validation Registry + X402 Execution Proof support on TRON.

---

Summary

ERC-8004 is currently in Review status on Ethereum and has already seen thousands of agents registered and multiple mainnet projects (INFINIT Labs, Mira Network, Spaace, etc.) actively using it. TRON, with its superior TPS, near-zero fees, and full Solidity/EVM compatibility, is perfectly positioned to become the primary execution layer for real-world agent economies. Without a native, ERC-8004-compatible standard, TRON risks missing the entire 2026–2027 AI-agent narrative wave.

This proposal introduces support for the ERC-8004 on-chain Agent Registry standard, consisting of three primary registries and an optional execution-proof layer:

1. Identity Registry – On-chain Agent identity NFT + metadata
2. Reputation Registry – User/agent ratings and feedback
3. Validation Registry – Third-party verification results
4. (Optional) X402 Execution Proof – Standardized proofs of what an agent actually executed

---

Motivation

The Web3 ecosystem is rapidly shifting toward autonomous AI agents that execute on-chain actions on behalf of users.
However, TRON currently lacks a standardized mechanism to:

• Identify agents on-chain
• Discover their capabilities
• Evaluate credibility or trustworthiness
• Access third-party validation or audit results
• Share these trust signals across wallets, marketplaces, and dApps

By adopting ERC-8004, TRON can:

1. Become compatible with the emerging multi-chain agent economy.
2. Provide extremely low-cost and high-throughput execution – ideal for agent workloads.
3. Enable wallets, DEXs, and dApps to integrate AI agents safely and trustably.
4. Attract developers from the Ethereum/Layer2 ecosystem who have begun adopting this standard.

---

Technical Scope

This TIP proposes adding support for:

On-chain Registries

• TRON-compatible Identity Registry (via TRC-721)
• TRON-compatible Reputation Registry
• TRON-compatible Validation Registry

Agent Metadata

• Support for IPFS-hosted agent.json
• Standardized endpoints for A2A / MCP / HTTP agent communication

Session Key Support

• Integrate with TRON’s native AccountPermission system
• Enable limited-scope, revocable execution keys for autonomous agents

Optional X402 Integration

• Provide interfaces for agent execution proof submissions
• Allow wallets and explorers to display verifiable proof-of-execution

---

Expected Impact

• TRON becomes an early adopter of standardized AI Agent infrastructure
• TRON wallets and dApps can display verified / rated / audited Agents
• Increased developer trust and safer user experiences
• Attract cross-chain Agent developers to TRON
• Establish a foundation for a TRON-native Agent economy

---

Author

bobo&hades(@Hades-Ye)

---

References

• EIP-8004 – Trustless Agents
• X402 – Execution Proof Framework
• TRON AccountPermission Documentation
• ERC-4337 Session Key Pattern

---

Please share your feedback, suggestions, or concerns below.

[0xbigapple]

I believe introducing ERC-8004 support is an excellent direction for TRON. 👍 Do we have any more concrete implementation plans or technical details for the rollout? For example:

Identity Registry
How will the ecosystem handle agent metadata, endpoints, and URI storage on TRON?
Will metadata live on BTFS or another decentralized storage layer?

Reputation Registry
Reputation Registry are vulnerable to Sybil attacks, rating manipulation, and fake validation, what security or reputation-protection mechanisms are planned?

USDT Transfer Costs & High-Frequency Agent Transactions
Transfer fee for USDT on the Tron network is much higher than that on Ethereum and BNB, for agents that need to perform high-frequency micropayments, is there any plan to reduce energy costs or optimize USDT transfers for AI-agent use cases?

Any clarification or roadmap details would be greatly appreciated.

[lxcmyf]

@boboliu-1010
Thank you for proposing TIP-8004. Bringing ERC-8004 / Agent Registry / X402 support to TRON is a valuable direction.

To help the community evaluate the proposal more effectively, it would be great to clarify a few key points:

1. Compatibility scope with ERC-8004 (whether the ABI is fully aligned, and whether TRON-specific fields are needed).

2. Cost and anti-abuse design for the Reputation / Validation registries, since storage on TRON is very cheap.

3. How Session Keys map to TRON’s AccountPermission system (call restrictions, resource limits, etc.).

4. Minimal integration approach for X402 proofs (on-chain storage vs. off-chain commitments).

Overall, we strongly support the direction. Looking forward to further refinement and community discussion.

[GordonLtron]

Regarding the Identity Registry, it would be valuable to define a TRON-specific metadata schema that explicitly handles Energy delegation preferences—allowing agents to signal how their transaction costs are covered (e.g., by the user or the agent), which would be crucial for high-frequency agent operations

[boboliu-1010]

I believe introducing ERC-8004 support is an excellent direction for TRON. 👍 Do we have any more concrete implementation plans or technical details for the rollout? For example:

Identity Registry How will the ecosystem handle agent metadata, endpoints, and URI storage on TRON? Will metadata live on BTFS or another decentralized storage layer?

Reputation Registry Reputation Registry are vulnerable to Sybil attacks, rating manipulation, and fake validation, what security or reputation-protection mechanisms are planned?

USDT Transfer Costs & High-Frequency Agent Transactions Transfer fee for USDT on the Tron network is much higher than that on Ethereum and BNB, for agents that need to perform high-frequency micropayments, is there any plan to reduce energy costs or optimize USDT transfers for AI-agent use cases?

Any clarification or roadmap details would be greatly appreciated.

Thanks, @0xbigapple, for the excellent and crucial questions! This is exactly the kind of technical discussion we need to ensure a robust TIP-8004.

Here are some initial thoughts on a practical implementation path, would love to get community feedback on this direction.

1. Metadata / URI

1.1. ERC-8004 approach

ERC-8004 stores only a tokenURI on-chain, and keeps all agent metadata (agent.json) off-chain.

A typical agent.json referenced by tokenURI looks like:

{
  "name": "ExampleAgent",
  "description": "Minimal metadata example for ERC-8004",
  // Image stored on IPFS
  "image": "ipfs://bafybeigd.../avatar.png",
  // Endpoint served via HTTPS
  "endpoints": [
    {
      "name": "A2A",
      "endpoint": "https://agent.example/agent-card.json"
    }
  ],
  ...
}

1.2. TRC-8004 optional approaches

TRON developers may choose any compatible storage backend.
In addition to IPFS, they may optionally use:

• BTFS (a decentralized storage layer native to the TRON ecosystem)
• Other storage providers as long as the URI format remains standard

1.3. Advantages

Option	Advantages
IPFS	Maximum cross-chain compatibility; widely supported across the EVM ecosystem.
BTFS	Native to TRON; potentially lower cost or faster access; easier ecosystem integration.
HTTPS	Simple for testing and rapid development.

Metadata remains fully compatible with ERC-8004 regardless of which storage option is used.

2. Reputation / Sybil considerations

2.1. ERC-8004 approach

ERC-8004 uses feedbackAuth to authorize who can submit feedback.
Sybil resistance is intentionally left to:

• Frontends
• Off-chain aggregators
• Application-level trust models

The standard provides raw feedback signals but does not define reputation algorithms.

2.2. TRC-8004 optional approaches

On TRON, additional practices may be used at the implementation level:

• Frontends / explorers may filter feedback by trusted reviewers
• Off-chain aggregators may weight reviewer reputation or detect abnormal patterns
• Agents may issue feedbackAuth selectively to verified users or sub-agents

These are deployment-level choices, not protocol changes.

2.3. Advantages

Option	Advantages
ERC-8004 default	Simple, neutral, cross-chain consistent; minimal assumptions about identity.
Frontend filtering	Reduces spam visibility; easy to implement per app.
Off-chain aggregation	Allows ML/statistical models without increasing on-chain cost.
Selective authorization	Useful for high-value agents (trading, routing, automation).

Applications can choose the trust model that matches their risk profile.

3. USDT cost and high-frequency execution

3.1. ERC-8004 approach

ERC-8004 does not prescribe any gas or execution-cost model.
On Ethereum, agent interactions follow the general gas-price model, which can be costly for frequent operations.

3.2. TRC-8004 optional approaches

TRON’s resource model offers additional optimization paths, such as:

• Using Energy or Energy-rental services to cover repeated contract calls
• Using batch processing for high-frequency agent tasks
• Leveraging recent TRON governance activity Proposal: Decrease the transaction fees #789 that discusses reducing the Energy unit price, which would lower contract execution cost further

These approaches can coexist with ERC-8004 without modifying the standard.

3.3. Advantages

Option	Advantages
ERC-8004 default	Simple and consistent across EVM chains.
Energy / rental	Predictable and lower-cost execution for automation-heavy agents.
Batch processing	Reduces total on-chain interactions.
Lower Energy unit price	Directly reduces the cost of Identity / Reputation / Validation writes.

This makes TRON a practical environment for high-frequency agent workloads.

These are my initial thoughts for the technical specification. The goal is to build on TRON's existing strengths to make the rollout as smooth as possible.

[lxcmyf]

@boboliu-1010
A few things I’m curious about regarding TRC-8004:

• Between IPFS and BTFS, have you noticed any speed/reliability differences when dealing with lots of agents?

• For HTTPS metadata, how do you handle updates without breaking tokenURI?

• With selective feedbackAuth, is there a risk of concentrating reputation control too much?

• For batch processing / Energy optimization, could that ever conflict with ERC-8004 standard behaviors or cross-chain use?

[boboliu-1010]

To help the community evaluate the proposal more effectively, it would be great to clarify a few key points:

1. Compatibility scope with ERC-8004 (whether the ABI is fully aligned, and whether TRON-specific fields are needed).
2. Cost and anti-abuse design for the Reputation / Validation registries, since storage on TRON is very cheap.
3. How Session Keys map to TRON’s AccountPermission system (call restrictions, resource limits, etc.).
4. Minimal integration approach for X402 proofs (on-chain storage vs. off-chain commitments).

Thank you for the sharp technical feedback. These points are critical for ensuring TIP-8004 a robust, TRON-native standard.

Here is a deeper, more optimized approach to address your concerns:

1. Compatibility & Address Handling (Optimized)

We will maintain 100% ABI compatibility with ERC-8004 to ensure existing tooling works.

• Address Normalization: Since ERC-8004 relies heavily on address types, the implementation will handle the conversion between TRON’s hex addresses (41...) and standard EVM 0x format internally. This ensures external tools see standard EVM interfaces while internal logic remains valid on TRON.
• Extension Strategy: Instead of modifying the core registry, TRON-specific metadata (e.g., Energy/Bandwidth strategies) will be standardized within the optional fields of the agent.json off-chain schema, keeping the on-chain contract lightweight.

2. Cost & Anti-Abuse: "Proof of Interaction"

Given cheap storage, simple fees aren't enough. I propose a "Interaction-Gated" Reputation System:

• Verifiable Interaction: The registry contract checks if the rater’s address has actually called the Agent’s contract (or spent assets with it) before accepting a review. This prevents "sybil" ratings from empty wallets.
• Staked Validators: For the ValidationRegistry, validators must lock a bond (TRX). If they sign false validations, a "challenger" can submit a fraud proof to slash their stake. This creates an economic security layer rather than just a spam filter.

3. Session Keys: Hybrid Architecture

TRON's native AccountPermission is powerful but has a limit (8 keys/permissions). I propose a Hybrid Model:

• L1 (Native): Use AccountPermission for the "Hard Kill Switch." The user delegates a key with a strict ResourceLimit and Operations mask (e.g., preventing generic TRX transfers).
• L2 (Contract Guard): For granular control (e.g., "Can only call swap on Curve"), the Agent acts through a smart contract wallet or proxy. The contract validates the specific function signatures and parameters.
• This combination offers both native resource protection and EVM-level logic flexibility.

4. X402 Integration: Attestation-Based Approach

Storing raw proofs is inefficient. We should adopt an Attestation / Optimistic Pattern:

• Attestation Standard: Treat X402 proofs as standardized attestations (similar to EAS). The agent posts a signature (Attestation) referencing the off-chain proof CID (BTFS/IPFS).
• Optimistic Window: The proof is assumed valid unless challenged within a time window.
• Verifier Network: Specialized verifier nodes (off-chain) can subscribe to these attestations and verify the computation. This keeps the TRON mainnet uncongested while maintaining cryptographic integrity.

I believe this architectural approach leverages TRON's high throughput while solving the specific challenges of identity and security. I will update the TIP draft to reflect these technical specifications.

[lxcmyf]

@boboliu-1010
Thanks for the update. The design looks clean in theory, but I have one concern:

Some of the proposed mechanisms — especially the hybrid permission model and the off-chain X402 verifier network — may be overly complex for TRON’s current developer ecosystem. They might be difficult to implement or maintain in practice.

Before finalizing the TIP, could we consider whether a simpler MVP version would be more realistic for TRON?

[Sunny6889]

I strongly support implementing ERC-8004 on TRON. Standardized agent identity, reputation, and validation mechanisms would benefit the ecosystem.

But I have below questions:

• Resource Consumption: What are the expected gas/energy consumption ranges for the three ERC-8004 registry contracts (Identity, Reputation, Validation) on TRON? Are there testnet benchmarks available?

• Infrastructure Impact: Given TRON's Energy/Bandwidth model, what operational burdens might full nodes face with high resource consumption? How might this affect:

  • Transaction processing times
  • Storage requirements

[bladehan1]

That's a good idea. I'd like to know if NFT identities can be transferred.

[warku123]

Hello, @boboliu-1010.

Thank you for the detailed and thoughtful technical clarifications provided so far. The proposed "Proof of Interaction" and hybrid session key models are particularly compelling for building a robust, TRON-native agent ecosystem. As the discussion moves forward, I would like to raise two interconnected points for further clarification, focusing on the economic model and its implications for system integrity.

1. Cost Structure for Sustainable Registry Operation

The proposal rightly highlights TRON's low-cost environment as a key advantage for high-frequency agent operations. However, to ensure the long-term sustainability and anti-spam resilience of the registries themselves, could you elaborate on the envisioned on-chain cost structure?

2. Preventing Collusion and Rating Inflation in a Low-Cost Environment

The "Proof of Interaction" mechanism is a smart foundational step against pure Sybil attacks. Yet, in a very low-fee environment, coordinated groups or even a single agent owner with multiple wallets could generate "real" but low-value interactions to manipulate ratings cheaply.

On the summary, my question is: How does the proposal plan to leverage TRON's cost advantage without letting it become a vulnerability for the trust system it aims to build? The goal is to ensure that low cost facilitates legitimate mass adoption, not artificial mass rating inflation.

I believe addressing these economic and incentive design details will greatly strengthen the proposal's case for a sustainable and trustworthy agent network on TRON.

Thank you for your work and consideration.

[boboliu-1010]

@boboliu-1010 Thanks for the update. The design looks clean in theory, but I have one concern:

Some of the proposed mechanisms — especially the hybrid permission model and the off-chain X402 verifier network — may be overly complex for TRON’s current developer ecosystem. They might be difficult to implement or maintain in practice.

Before finalizing the TIP, could we consider whether a simpler MVP version would be more realistic for TRON?

@lxcmyf Thanks for the feedback — it’s very helpful.

At this stage, the intention is to move toward a practical MVP that can be implemented and deployed on the testnet. The goal is to validate the basic architecture early, gather feedback from developers, and iterate before introducing any of the more advanced components.

The MVP would focus on the essential registry structure (Identity, Reputation, and Validation) in their simplest form, without enabling complex logic. This allows us to test the standard end-to-end, ensure compatibility, and give the community something concrete to interact with.

I would like to continue the discussion with the community regarding what the first deployable version should include, so we can align on a clear and realistic MVP scope for the initial testnet rollout.

Looking forward to further conversation and refinement together.

[lxcmyf]

MVP focusing on core architecture has a clear idea, which is convenient for rapid verification. I support limiting the scope of the first test network version to the basic registration structure (identity/reputation/verification), and suspending complex logic. We can discuss the next step around the specific minimum function set, such as defining the specific technical boundary of the "simplest implementation". We look forward to jointly refining the plan.