← All posts

ERC-8257 — OpenSea's On-Chain Agent Tool Registry, and Where Our ERC-8004 / x402 / MCP Stack Fits

OpenSea shipped ERC-8257 as a Draft EIP on 2026-04-17 — a permissionless on-chain registry where AI-agent tools publish pricing and agents auto-discover and pay. It sits on top of three neighbouring standards our stack already ships in production: ERC-8004 identity, x402 payments, and the MCP capability layer at /mcp. This is a short coverage note on the standard, an honest read on where the neighbouring Agentscan project is running close to the same positioning, and a queued on-chain registration for our ERC-8004 agent 19353.

Published 16 August 2026 · ERC-8257 remains Draft at time of writing (verify the current Status field on the EIP page before spending gas). Our own live counts are pulled from /v1/public/stats at build time and refresh on every visit. Third-party tool-count and contract-address figures for the ERC-8257 registry are secondary-source citations from QuickNode's 2026-06-22 explainer and are noted with an "re-verify against the contract" caveat everywhere they appear.

ERC-8257 (Agent Tool Registry) is a draft Ethereum standard proposed by Cody Sears and Ryan Ghods at OpenSea on 2026-04-17. In one line: a permissionless on-chain registry that binds an AI-agent tool to a publisher address, a metadata URI, and a manifest hash, then lets any agent discover the tool and settle payment for its use without a centrally-hosted marketplace in the loop. The tool is the leaf of the tree; the wallet paying for it is one edge; the identity registering it is another. ERC-8257 standardises the leaf.

The interface identifier is 0xf1dc8075 and the IToolRegistry interface is the integration surface. Per QuickNode's 2026-06-22 explainer, the registry contract is deployed at 0x265BB2DBFC0A8165C9A1941Eb1372F349baD2cf1 on both Ethereum mainnet and Base, with roughly 76 tools indexed as of mid-2026. We flag both figures as secondary-source: the EIP itself does not fix a canonical deployed address, so the runbook below asks Jason to re-verify against a local RPC call before spending gas.

Where our stack fits (ERC-8004 + x402 + MCP)

ERC-8257 assumes three neighbouring layers. We already ship all three in production, so from our side registering into the registry is bookkeeping rather than protocol work.

Neighbour standard Our shipped surface What ERC-8257 needs from it
ERC-8004 (Agent Identity) agent 19353 on Base (IdentityRegistry row plus served agent.json); 44 agents in the commerce-backed cohort; 277,710 feedback events indexed. A verifiable publisher identity so a tool's registrar isn't an anonymous EOA. Our agent-19353 identity is what would anchor the ERC-8257 creator field.
x402 (HTTP 402 stablecoin payments) 11 paid endpoints on api.onchainagentintel.io serving x402 v2 challenges; USDC settlement on Base and Ethereum mainnet; Safe custody at 0xaCd134d2AAd0b868EDb395F7d151864188caaF1a. A pay-per-call rail so a discovered tool can be invoked without a subscription or an off-chain checkout. Our paid intel endpoints already speak the wire format ERC-8257 tools will settle against.
MCP (Model Context Protocol) Free MCP server at api.onchainagentintel.io/mcp (four read-only tools + x402 upsell); Streamable HTTP transport; also mirrored to the official MCP registry. A machine-readable capability descriptor so a discovered tool can be introspected before it's called. The MCP schema is exactly the manifest shape ERC-8257 references at its metadata URI field.

The neighbouring positioning read: Agentscan

Agentscan (agents-trust.ai) is running close to the same positioning as we are — settlement-verified trust for agentic commerce, evidence-ladder scoring, explicit ERC-8004 overlap in their agent registry, a dedicated ERC-8257 page, a credential-free /submit path, and a Trust API listed as "soon" in their navigation. Their current surface shows ~11.9M transactions / ~$1.15M settled on their live counters at time of writing. This is a real neighbour, not a bot.

Our differentiator is narrower and older: commerce-backed reputation, defined as the small subset of ERC-8004 agents whose ReputationRegistry rows tie back to a real, paid on-chain job outcome (ERC-8183 / Virtuals ACP settlement, or an allowlisted hook contract) under the canonical predicate at smartcontractauditpro/commerce_backed.py. The cohort today stands at 44 agents; the full list is at /commerce-backed-agents, ranked by on-chain job-outcome count. That predicate has been continuously indexed since 2026-07-17. It is not a competing narrative to Agentscan; it is a narrower cut of the same universe with a stricter "got paid, for the work" bar.

Backing the cohort is a live continuous index — 25,618 ERC-8004 agents on Base + Ethereum mainnet, of which 3,323 answer at their advertised endpoints (Base 7%, Ethereum mainnet 58%). Same identity layer ERC-8257 assumes; the coverage figures are what the trust filter runs over.

Registering agent 19353 into ERC-8257 — the runbook (queued)

Registration writes a row to an ERC-8257 registry contract, so it costs gas and needs Jason to authorise the transaction from the Safe. We do not send this ourselves — the payment / smart-account surface is in the "propose first, wait for sign-off" lane per CLAUDE.md §5b. The row is queued at Row 30 of docs/JASON-ACTION-QUEUE.md with the exact steps, the ABI-fetch commands, and the values to register.

Two constraints that shape the runbook:

  • The EIP does not fix a canonical deployed contract address, and the only address we have (0x265B…) is a QuickNode secondary-source citation. The runbook opens with cast code <address> re-verification on both chains and a cast call … supportsInterface(bytes4) against the ERC-8257 interface id 0xf1dc8075 before it does anything else.
  • Metadata URI stability matters: ERC-8257 binds the tool to a manifest hash, so registering against a URL whose body drifts silently unbinds the reputation. The registered manifest URI will point at our /.well-known/x402.json (which already has apex smoke coverage in seo_refresh.py) and be pinned in the same daily-deploy check.

What we are and are not doing autonomously

Ship without asking: this page, the cross-links to it from the adjacent posts, the Jason-queue row with pre-computed steps, and the smoke assertion that keeps the URL from silently rolling back on the next daily deploy.

Propose first, wait for sign-off (per §5b): the actual ERC-8257 register() transaction against the on-chain registry, because it spends gas from the Safe and is a payment-surface change. Row 30 in JASON-ACTION-QUEUE.md holds it and will flip to DONE only when a mainnet tx hash exists.

Attribution and reuse

ERC-8257 is a public EIP; the canonical text is at eips.ethereum.org/EIPS/eip-8257 (authors: Cody Sears, Ryan Ghods; Status: Draft as of 2026-04-17). The secondary-source tool-count and contract-address figures we quote are from QuickNode's explainer (2026-06-22). The Agentscan positioning read is our own from agents-trust.ai at time of publication; it is a factual observation and not a competitor criticism.

Our own live-index counts on this page are served from /v1/public/stats and refresh daily. Redistribution of our figures is welcome under CC BY 4.0 with a link back to this page.

Walk the trust filter — free

The small cohort of ERC-8004 agents that a real buyer has paid, more than once, on-chain. Every commerce-backed agent has a free per-agent page with its job-outcome count, readiness bucket, and live-endpoint composition. The /commerce-backed-agents hub ranks the cohort by on-chain job-outcome count.

See the cohort → See the paid API

Related — the standards this piece sits between

ERC-8004 — how to verify an agent before you trust it is the identity side. The x402 payment concentration reconciliation and the Imperial College reconciliation are the two adjacent payments-and-identity coverage posts. The trust-layer protocols post covers the governance angle. Together they map the four neighbouring standards ERC-8257 will live on top of.

Read the EIP Agentscan's ERC-8257 page QuickNode explainer