OpenSea Agents (ERC-8217 agent binding) — why we’re not listed + checklist

Research, 2026-06-30. Corrected diagnosis of why DePunks / Agents4.fun does not appear on OpenSea’s “Agents” surface. This supersedes the earlier ERC-8257 note, which named the wrong standard: the relevant standard is ERC-8217 “Agent NFT Identity Bindings” (binding an NFT collection to an on-chain ERC-8004 agent identity), not the ERC-8257 tool registry.

Correction notice

An earlier version of this doc diagnosed the problem in terms of ERC-8257 (Agent Tool Registry) — the “app store of agent tools.” That was the wrong standard for the “Agents” question. ERC-8257 is about registering tools/skills; it never makes a collection show as agent-bound. The standard that governs whether a collection is recognised as agent-backed is ERC-8217 — Agent NFT Identity Bindings, which links an NFT contract+token to an ERC-8004 agent identity. This doc re-diagnoses on that basis.

TL;DR

DePunks is already bound. The DePunks app implements the full ERC-8217 binding flow against the live mainnet Adapter8004 contract — it calls register(standard, tokenContract, tokenId, agentURI) to bind a DePunk ERC-721 token to a new ERC-8004 agent identity, which writes the canonical agent-binding metadata on-chain. Our own Agents4.fun discovery backend reads that exact registry (0xde152afb…) to list agent-bound DePunks. So the binding is not the blocker.

The reason DePunks/Agents4 may not appear on OpenSea’s Agents surface is downstream of the binding:

1. OpenSea reads the binding per-token, not per-collection, and only on the NFT detail endpoint — and only for the sparse subset of tokens that are actually bound. A collection only “becomes” agent-bound on OpenSea once specific tokens carry the binding and OpenSea has indexed/cached it. If only a handful of DePunks have been promoted (registered) — or none on the production chain — there is little or nothing for OpenSea to surface.
2. It’s a draft standard with early/partial marketplace support. ERC-8217 ships via the Adapter8004 singleton (deployed on Ethereum mainnet, Base, Sepolia) with some OpenSea support, but the “Agents” treatment is new and may be early-access or incompletely rolled out. Whether OpenSea exposes a browsable “Agents” list (vs. only a per-token agent_binding field on the detail API) is an external unknown we cannot confirm from here.
3. The separate “Agent” metadata trait is best-effort and can be stale. Distinct from the on-chain binding, the app also nudges OpenSea to cache an “Agent” trait on each token (via the refresh/get_nft API). That trait is metadata only — it does not create the binding — and OpenSea’s refresh endpoint occasionally drops requests, leaving a token bound on-chain but stale in OpenSea’s cache.

So the honest reading is: the binding mechanism is built and pointed at the right chain; the gap is (a) how many tokens are actually registered on the production chain, and (b) external/unverifiable OpenSea-side indexing and rollout of the draft standard. This is the opposite of the earlier ERC-8257 diagnosis, which wrongly said “nothing was ever registered.”

What ERC-8217 actually is (and how it differs)

ERC-8217 — Agent NFT Identity Bindings is a draft ERC that binds an external token (ERC-721 / ERC-1155 / ERC-6909) to an ERC-8004 agent-identity record. Mechanism:

• A singleton Adapter8004 contract (the “binding registry”) mints/holds an ERC-8004 identity and records a binding from that agentId to one external token.
• On registration it writes canonical binding metadata under a reserved agent-binding metadata key — exactly 20 bytes, the binding contract’s address.
• A marketplace verifies by reading agent-binding (20 bytes) → decoding it as the binding contract address → calling bindingOf(agentId) on that contract to get the canonical {standard, tokenContract, tokenId} record. Whoever controls the external NFT controls the identity.
• Deployed (per the Adapter8004 project) on Ethereum mainnet, Base, and Sepolia, with stated OpenSea support.

How it differs from the two things it’s easy to confuse it with:

The earlier doc cited ERC-8257; that governs tools, not whether a collection is agent-bound. The “Agent” trait the app pokes onto OpenSea lives in the get_nft column — metadata, not a binding.

What the code already has vs. what’s missing

Already built (DePunks app, app/src/app/):

• abi/adapter8004.ts — hand-written ABI for the ERC-8004 Adapter (the ERC-8217 binding registry). ADAPTER8004_ADDRESSES: mainnet 0xde152AfB7db5373F34876E1499fbD893A82dD336, Sepolia 0x7621630cB63a73a194f45A3E6801B8C6A7eC2f92. Includes register, bindingOf, setMetadata/getMetadata, isController, ownerOf, tokenURI, identityRegistry.
• components/club/FoundationClient.tsx — the promotion wizard that calls register(TOKEN_STANDARD_ERC721, contractAddress, tokenId, agentUri) to bind a DePunk to a fresh agent identity.
• lib/agents/identity.ts — serves the ERC-8004 agent card (registration.json) at the agentURI, including a registrations[] entry with agentRegistry: eip155:<chainId>:<adapter>, tokenContract, tokenId. Also serves soul.md, A2A card, MCP manifest.
• lib/agents/agentOpenseaSync.ts + agentTrait.ts — best-effort reconciler that GETs OpenSea and POSTs a refresh so the “Agent” trait is cached on each bound token (nudgeOpenseaRefresh).
• pages/club/foundationFunctions.ts — startPromotion / confirmPromotion server flow that records agentId, adapterAddress, and confirmed status.
• Agents4.fun (agent-wl) apps/backend/src/domain/agents/agentDiscovery.ts — reads the same binding registry logs (0xde152afb…, agent registry 0x8004a169…, binding event topic) to enumerate bound tokens, then hydrates images from OpenSea. DePunks (depunks-club, 0xce7a61d1…) is in AGENT_COLLECTIONS.

Chain config: the app supports chain IDs 1 (mainnet), 31337 (anvil mainnet fork), 11155111 (Sepolia); production VITE_CHAIN_ID=1 (mainnet). Base (8453) is commented out in .env and the adapter has no Base mapping in ADAPTER8004_ADDRESSES.

Missing / unconfirmed:

• No verified count of tokens actually registered on the production (mainnet) chain. If few/zero DePunks have completed the promotion wizard on mainnet, there is little for OpenSea to surface.
• No Base deployment path in code — if OpenSea’s Agents surface favours/needs Base, we have no adapter mapping or chain config for it.
• The binding ≠ the “Agent” trait. Both exist, but they are separate; a token can be bound on-chain yet show no trait on OpenSea (stale cache), and vice-versa.
• OpenSea-side indexing/rollout is external and unverifiable from here (see Unknowns).

Checklist to get listed (impact-ordered)

1. Confirm how many DePunks are actually bound on mainnet. Query the binding registry (bindingOf / binding-event logs) for the DePunk contract 0xce7a61d1… on chain 1, and count confirmed registrations in the app DB. If the number is ~0, that alone explains absence from any Agents surface — the fix is simply to run the promotion/register flow for real tokens on mainnet.
2. Verify OpenSea’s per-token agent_binding is populated for those tokens. Use the OpenSea NFT detail endpoint (/chain/ethereum/contract/<addr>/nfts/<id>) for a known-bound DePunk and check for the agent_binding field. (Needs the x-api-key header — see Unknowns; can’t be done from this sandbox.)
3. Re-run the “Agent” trait reconciler (reconcileAgentOpenseaMetadata, force) so OpenSea’s cached metadata reflects the trait, and confirm OpenSea actually refreshed.
4. Decide on Base. If OpenSea’s Agents surface is Base-first, add a Base (8453) adapter mapping + chain config and bind there; otherwise document that mainnet is intentional.
5. Accept the draft-standard caveat. ERC-8217 is a draft; OpenSea’s “Agents” treatment may be early-access/partial. Even with everything correct on our side, listing may depend on OpenSea finishing rollout — treat external listing as not fully in our control.

Honest unknowns

• Live OpenSea API status could not be queried from here. An OPENSEA_API_KEY exists in depunks/app/.env, but the sandbox blocks curl to api.opensea.io and web_fetch can’t send the required x-api-key header. So we could not verify, live: whether DePunks tokens carry agent_binding on OpenSea, whether the “Agent” trait is cached, or whether OpenSea exposes a browsable “Agents” list at all.
• Whether OpenSea has a public “Agents list” (vs. only a per-token agent_binding field on the detail API) is unconfirmed. Our own code comments say OpenSea exposes the binding “only on the detail endpoint and only for the sparse subset that is bound.”
• Exact OpenSea support level for ERC-8217 (which chains, browsable surface, early-access gating) is external and changes over time.
• Actual mainnet registration count was not measured in this pass (no live RPC/DB query run here).