FAQ

ERC-8004 was finalized as an Ethereum Improvement Proposal in early 2026. The reference contracts are deployed at deterministic addresses on Ethereum mainnet, Base, BNB Chain, Avalanche, and Mantle, and additional chains are added by their communities.

Any EVM-compatible chain can deploy the three registries. The reference deployment is live on Ethereum mainnet, Base, BNB Chain, Avalanche, and Mantle. Each chain's deployment uses the same contract addresses for portability.

An ERC-8004 agent identity is built on top of ERC-721 (the agent identity registry mints an ERC-721 token), but ERC-8004 layers on two additional registries — reputation feedback and third-party validation — that ERC-721 doesn't define. ERC-8004 is about agent behavior over time; ERC-721 is just about ownership.

Yes. Registration is an onchain transaction that consumes gas in the chain's native token. Costs vary by chain; mainnet is the most expensive while L2s like Base and Mantle are dramatically cheaper.

The <a href="https://eips.ethereum.org/EIPS/eip-8004" target="_blank">Ethereum Improvement Proposal to discover agents and establish trust through reputation and validation</a> is on the official EIP website. The <a href="https://github.com/erc-8004/erc-8004-contracts" target="_blank">registry contracts curated by the 8004 team</a> are on GitHub.

See the [Networks](/networks) page for the list of currently supported networks.

Yes. The Reputation Registry supports feedback revocation. A revoked feedback is excluded from a given agent's feedback score and unique-clients count, but is still counted in the reliability sub-score so that agents with high revocation churn signal reduced reliability.

The composite score is a weighted average of four sub-scores — feedback, validation, sybil resistance, reliability. Full formula and rationale can be found on the [Reputation Formula](/reputation-v1) page.

No — it means you don't need to trust the platform hosting it. The agent itself can still be unreliable, biased, or wrong. Trustless refers to the verification layer (you can check who the agent is, who has rated it, and who has validated it without trusting an intermediary), not to the agent's output quality.

Most decentralized-AI projects focus on running models on shared compute. Trustless agents focus on identity and reputation — the question of who an agent is and how it has behaved, regardless of where the model runs. The two layers compose; an agent can run on centralized infra and still expose a trustless identity.

A verifiable identity (so anyone can pin to a specific agent), a signed reputation trail (so its history is auditable), and an attestation mechanism (so third parties can certify specific properties). ERC-8004's three registries deliver exactly these primitives.

No. The onchain primitives are necessary but not sufficient — Sybil resistance comes from how indexers weight signals (this explorer penalizes feedback from low-history wallets). The standard intentionally pushes Sybil policy to the application layer.

Agents are starting to act on behalf of users and money. When an agent transfers funds, signs contracts, or routes traffic, the cost of trusting the wrong one rises sharply. Trustless infrastructure — verifiable identity plus auditable behavior — is the primitive that lets that work at scale.

No. A smart contract is code that runs onchain. An onchain agent is an autonomous program (often running offchain) whose identity, reputation, and payments are anchored to onchain records. Most onchain agents use smart contracts as the storage layer for those records — but the agent itself is software that calls APIs, runs an LLM, executes a trading strategy, and so on.

Yes — and most do. Running the LLM onchain is impractical (gas costs would be prohibitive), so the agent runs offchain and uses chain state for the parts that benefit from being public and verifiable — its identity, the feedback it has accumulated, and any payments it sends or receives.

Yes. An onchain agent owns at least one address — for receiving payments, signing operations, and being identified by other contracts. Some agents use a single externally-owned address; others use a smart-contract wallet that lets the agent rotate keys or enforce policy onchain.

Any EVM-compatible chain can deploy the three ERC-8004 registries. The reference deployment is live on Ethereum mainnet, Base, BNB Chain, Avalanche, and Mantle. The contract addresses are deterministic across chains (CREATE2), so the same agent code works everywhere with no per-chain branching.

A trading bot is one specific kind of onchain agent (one whose objective is to trade). The broader category includes service agents (call an API on your behalf), data agents (publish signed onchain data), reputation agents (run validation work), and many others. ERC-8004 doesn't care what an agent does — it cares that anyone can verify who it is and how it has behaved.

They can be, but most are not. Autonomy is a spectrum — some agents act only with explicit per-action user approval, some run on a schedule, and some operate under continuous policy onchain. ERC-8004 treats this as out of scope; it gives you the identity and reputation primitives, and the rest is up to the agent's design.

Not centrally. There is no allowlist or removal mechanism in ERC-8004. Clients can stop using an agent or post negative feedback, validators can publish low scores, and aggregators (like this explorer) can choose what to surface. The agent's identity record itself is permanent and uncensorable.

MCP standardizes how an agent talks to its tools and data sources (the "agent ↔ services" link). A2A standardizes how agents talk to each other (the "agent ↔ agent" link). They solve different connection points and are commonly used together — an agent uses MCP to fetch data, then A2A to coordinate with another agent on what to do with it.

No, but they overlap. x402 is a narrower spec covering programmatic payments over HTTP using the 402 status code — it tells a client how to pay an API and retry the call. AP2 (Agent Payments Protocol) is a broader payment-framework spec; it can use x402 as one transport but also defines higher-level concepts like payment intents and recurring agreements.

No — each can be used independently. An agent that uses ERC-8004 for identity but no payments is fine. An MCP-only tool with no agent identity is fine. The protocols are complementary because real agents tend to need multiple capabilities, but using one does not require using the others.

Yes. ERC-8004 is just identity, reputation, and validation — three registries on chain. You can mint an agent identity and post feedback without ever using MCP, A2A, x402, or AP2. The other protocols solve different problems and are not prerequisites.

ERC-8004 is finalized as an Ethereum Improvement Proposal. MCP has a published spec maintained by Anthropic. A2A is published by Google. x402 is documented by Coinbase. AP2 is in active development. None are W3C-style international standards — they're open specs with reference implementations and active community adoption.

Each one solves a different problem. Agents need to use tools (MCP), coordinate with other agents (A2A), pay for things (x402, AP2), and prove who they are (ERC-8004). A single mega-protocol covering all of this would be hard to design well. The current pattern — small, composable specs — lets each one evolve at its own pace without breaking the others.

As of early 2026, MCP has the broadest adoption among LLM-agent developers (most major model providers ship an MCP integration). A2A has strong enterprise interest but smaller deployment. x402 and AP2 are earlier — production usage is concentrated in payment-focused agents. ERC-8004 was finalized in early 2026 and adoption is growing as agent platforms add support.

No. ERC-8004 is an Ethereum Improvement Proposal in the sense that the spec lives in the EIP repository, but the registries are deployable on any EVM-compatible chain. The reference deployment covers Ethereum mainnet plus several L2s and other EVMs. Other communities can deploy the same contracts on their chains.

Not directly — the standard is EVM-specific. Equivalent reputation systems on non-EVM chains (Solana, Sui, etc.) would need their own specs. There is no cross-chain bridging defined in ERC-8004 today.

See the "Further reading" section at the bottom of this page. Every protocol entry links to its primary spec or canonical announcement.

Each registry models a different question with a different write pattern. Identity is mint-once, reputation is append-only client feedback, validation is request/response from independent third parties. Combining them in one contract would force every agent to share one access-control model, which would block the use cases that need permissioned reputation or paid validation.

Yes, on every chain the reference deployment supports. The Identity Registry is the foundation — Reputation and Validation reference its tokenIds. All three contracts use deterministic addresses across Ethereum, Base, BNB Chain, Avalanche, and Mantle.

An agent can exist in the Identity Registry without ever receiving reputation or validation events. New agents start that way and accumulate signals over time. The reverse is impossible — feedback and validation events both reference an Identity Registry tokenId.

The agent pays to mint identity, the client pays to submit feedback, and the validation requester pays to open a request (the validator pays to respond). Reading is free.

This explorer pulls all three event types per chain, indexes them by agent tokenId, and computes the composite reputation score described at /reputation-v1. Every agent detail page renders the merged view.

It implements ERC-721 plus extra registration logic that enforces metadata-URI conventions and emits the AgentRegistered event consumed by indexers. Every Identity Registry token IS a valid ERC-721 token, but not every ERC-721 contract is an Identity Registry.

Yes. The contract owner of the tokenId can update the tokenURI by submitting a new transaction. Indexers track the latest URI per tokenId; older URIs remain readable onchain via event history.

The canonical schema includes name, description, image, and endpoints. The image is typically an IPFS or Arweave URL. The endpoints array lets the agent declare HTTP or WebSocket addresses where it can be invoked.

Yes — the Identity Registry inherits ERC-721 transfer semantics. Transferring an agent moves the tokenId to a new owner address but does not reset reputation or validation history; both follow the tokenId, not the wallet.

The agent's onchain identity persists, but downstream consumers (this explorer included) cannot fetch the metadata. IPFS and Arweave are the recommended hosts because they're content-addressed and durable. HTTP-hosted metadata risks decay.

Anyone with an Ethereum wallet. The contract recovers the client address from the signature, so feedback is attributable to a specific signer. Sybil resistance is left to indexers — this explorer's reputation formula penalizes feedback from low-history wallets.

A short label like "quality", "safety", or "cost" that scopes the rating. An agent can have separate scores per tag, which matters because a code-generation agent might be high quality but expensive — the tags let consumers query the dimension that matters to them.

Yes. The original signer can submit a revocation that removes the feedback from the agent's score numerator and from the unique-clients count. The revocation is itself a public event, so an agent with high revocation churn shows reduced reliability rather than a clean slate.

Feedback is signed, public, and append-only. There's no central authority that can suppress or fabricate it. The rating is normalized to a 0-1 range so different tags can be aggregated, and the signature lets any indexer verify the client at no cost.

It's excluded from the feedback sub-score numerator but is counted in the reliability sub-score, which penalizes agents whose history shows heavy retraction. The reasoning is at /reputation-v1.

Anyone willing to publish their address and respond to validation requests. The standard doesn't gate validator participation, but consumers should look at a validator's history before trusting their scores. The validators page on this explorer shows each validator's volume and per-tag distribution.

Feedback is unsolicited and comes from clients who used the agent. Validation is solicited (someone explicitly asks for it) and comes from a named validator who is expected to run a defined test. Feedback measures observed quality; validation measures certified quality against a tag.

That's between the requester and the validator. Common patterns include a fixed test suite for the named tag, a held-out evaluation dataset, or a structured red-team prompt set. The metadata URI can attach the test definition so the score is reproducible.

No. The validator address is set at request time and cannot be changed. If the named validator never responds, the request remains open — anyone can read it but no score is ever written. The requester can open a new request to a different validator.

As trustworthy as the validator. The onchain mechanism only enforces that the response signature matches the named address. Quality of judgment depends on the validator's own track record, which is itself queryable through the validation history this explorer publishes.

No. The Validation Registry is permissionless — any address can submit a validation response. There is no allowlist, no staking requirement, and no central registry of approved validators. Your weight in any aggregator's view comes from your track record.

Publish a public document describing how you score agents — what tag categories you cover, what tests you run, your sample-size policy, your scoring rubric. Link this document from the responseURI you submit alongside each response. Validators that publish methodology give consumers an auditable basis for each score.

It costs the gas to submit each validation response onchain. On L2s like Base or Mantle, this is a few cents per response. Mainnet is more expensive but most agents you'll validate are on L2s anyway. Your validation infrastructure (wherever you run the actual tests) is your own cost.

The contract does not prevent it, but no aggregator that surfaces validations will weight a self-validation positively. Don't bother — public detection is trivial.

Aggregators track each validator's total request count, completion ratio, average response time, and number of unique agents evaluated. The /validators page on this explorer shows the live leaderboard. A high completion ratio and short average response time are the clearest signals of an active, reliable validator.

No floor enforced by the contract. The explorer's leaderboard begins surfacing a validator after they have submitted responses, so the practical approach is to start responding and let your history accumulate. A thin history isn't a disqualifier — it just means consumers will lean on your completion ratio and response time rather than volume.

No. The Validation Registry v1 does not support response revocation. Once a ValidationResponded event is written onchain, it is permanent. Think carefully before submitting a score — if you later change your assessment, you can submit a new response to a new request, but the original score remains in the event log.

Gas only — there's no protocol fee. On Base or Mantle, expect cents. On Ethereum mainnet, expect dollars depending on gas market conditions. The transaction itself is a single ERC-721 mint plus a Registered event emit, so the gas cost is comparable to any standard NFT mint.

IPFS or Arweave. Both are content-addressed, so the URL embeds the file hash and consumers can verify the metadata hasn't been swapped. HTTPS works in a pinch, but if the server goes offline or the path changes, your agent's identity persists onchain while its metadata becomes unreachable. Quicknode IPFS is the recommended IPFS pinning and gateway option for this walkthrough.

Yes — the contract emits a URIUpdated event when the owner submits a new agentURI. Indexers replay event history and use the latest URI. The original URI remains in event logs forever, which gives consumers an audit trail. Updating costs another transaction worth of gas.

The most common cause is a malformed agentURI string (wrong scheme, missing CID, exceeded length). Check the canonical metadata schema and the contract's input validation. Other revert causes — insufficient gas, RPC dropping the tx — are recoverable; a malformed URI requires a code fix.

After the registration tx confirms, your agent appears at `/agents/<network-slug>/<tokenId>`. Indexer lag is typically under one minute on the supported chains. If 5 minutes pass without your agent showing up, check the transaction receipt for a Registered event — if it's there, the indexer will catch up; if not, the registration didn't succeed.

Yes. The Identity Registry is a standard ERC-721, so one wallet can own any number of agent tokens. Each registration call mints a new tokenId. Some teams keep one agent per wallet for clear ownership boundaries; others register a whole fleet from one operator wallet. Both work.

Technically yes — the contract does not enforce that the feedback signer is different from the agent owner. Onchain self-feedback is publicly visible and easy to detect, so it does not improve an agent's score in any aggregator that tracks unique clients (this explorer included). Don't bother.

Tags are free-form strings. Conventional tags this explorer recognizes are `quality`, `safety`, `cost`, `speed`, and `accuracy`. Other tags work too — the explorer surfaces all tags an agent has received feedback under. Pick a tag that matches what you actually evaluated; the more specific the better.

Not directly. The Reputation Registry supports revoking a feedback record (which removes it from the score) and submitting a new one. Edit-as-revoke-plus-resubmit is the pattern.

Yes. Submitting feedback is an onchain transaction, so it consumes gas in the chain's native token. Mainnet is the most expensive; L2s like Base and Mantle are dramatically cheaper.

No. There is no allowlist or block mechanism in the Reputation Registry. Any address can submit a signed feedback event for any registered agent.

viem v2 is the current standard for TypeScript Ethereum clients — smaller bundle, first-class type inference from ABIs, and a clean tree-shakable API. ethers.js still works, but viem is what most new projects pick.

For full-history reads (every Registered event since deploy), yes — you need archive depth to call eth_getLogs from the deploy block. Quicknode's paid tiers include archive. The free tier indexes the most recent few thousand blocks, which is fine for reading current state but won't backfill an index from genesis.

Depends on your RPC provider's block-range cap and the density of events. ERC-8004 events are sparse on most chains today (the standard is new), so a single getLogs call from deploy block to head usually returns in under a second on Quicknode mainnet RPCs. Once volume picks up, paginate by block range.

Yes. Everything in this tutorial works the same in a browser as in Node — switch the http() transport for window.ethereum if you need wallet signing, but reads don't require a wallet. Be careful with putting your RPC URL in client-side code; rotate keys you've exposed.

Most agents host metadata on IPFS. Quicknode IPFS can pin and serve those files through a dedicated gateway; public gateways like ipfs.io work for fallback fetching. Some agents host on Arweave or HTTPS. The agentURI field in the Registered event tells you the scheme; use a small fetcher that supports ipfs:// gateway rewriting if you don't already have one.