Source-Token Agent Binding for ERC-8004

Source-Token Agent Binding for ERC-8004 — companion to ERC-8217 (Agent NFT Identity Bindings, @nxt3d). Co-authored with @TMerlini.

The gap. ERC-8004 assumes an agent is minted fresh. In practice the most natural agents are derived from NFTs people already hold — a PFP, a membership token, a game character. Existing standards conflate two facts that need to stay separate: which token an agent was derived from (must be immutable — permanent provenance) and whether the current agent holder still owns that token (must be live and re-checkable — mutable). This standard draws that line explicitly: getSourceNFT for the former, isSourceNFTOwnershipValid for the latter.

Reference implementation is live on Ethereum mainnet, not hypothetical — dinamic.eth resolves through this stack, and the separation is directly observable via eth_call. Verified independently before posting (not taking the numbers on faith):

Pixel Goblins registry: 0xe0454dFA17a57a84c3E0E2DBFdA5318CBBE91e2c

agent #1:  getSourceNFT(1)  -> (0x6559807F..., 85)   isSourceNFTOwnershipValid(1)  -> true
agent #14: getSourceNFT(14) -> (0x6559807F..., 577)  isSourceNFTOwnershipValid(14) -> false

Agent #14’s provenance is permanent (still resolves to Goblin #577) but the source token has since changed hands, so the live check correctly reports false — the immutable and mutable facts report independently, which is the whole point of keeping them as separate views rather than one conflated ownerOf.

ERC-165 interface id 0x27eba962 is the XOR of the five function selectors, independently recomputed and confirmed to match. A fully-conformant reference instance is deployed on Sepolia (0x01B014fc69d823FfEb80C313C29Bb6ead3978CEe) advertising supportsInterface(0x27eba962) == true for anyone who wants a from-scratch conformant deployment to test against, since the mainnet registries predate the finalized interface id and only implement the functional surface.

The isSourceNFTOwnershipValid sovereignty case (an ERC-6551 token-bound account holding the source token, not just the agent owner directly) is spelled out precisely in the interface doc — a bare ownerOf(sourceToken) == ownerOf(agentId) check is non-conformant, since it force-fails the TBA custody pattern.

Full spec + interface: Source-Token Agent Binding — live-ownership view + consumer requirements, additive to ERC-8217 (Agent NFT Identity Bindings). Authors: TMerlini, babyblueviper1. TBA sovereignty case: cody. · GitHub

This is the identity layer of the Agent-Service Consultation Flow composition note — the live-ownership re-check is the premise a downstream verdict and settlement depend on — but the interface here stands on its own and depends on none of that composition. Feedback welcome, especially on the sovereignty/TBA custody framing.

1 Like

Co-author here, adding the part that makes @babyblueviper1 point checkable rather than asserted: every claim in this is a public eth_call, recompute it, don’t take our word.

The two facts the standard separates, live on mainnet (Pixel Goblins registry 0xe0454dFA17a57a84c3E0E2DBFdA5318CBBE91e2c):

  • still-held (agent #1): getSourceNFT(1)(0x6559807F…, 85), and isSourceNFTOwnershipValid(1)true

  • diverged (agent #14): getSourceNFT(14)(0x6559807F…, 577) still resolves (provenance is permanent), but isSourceNFTOwnershipValid(14)false — the source token changed hands

The immutable fact and the mutable fact report independently. That’s the whole contribution, and you can watch it be true.

On ERC-165: the mainnet registries above predate the finalized IAgentSourceBinding id, so they carry the full functional surface but don’t advertise 0x27eba962. A fully-conformant instance is live on Sepolia at 0x01B014fc69d823FfEb80C313C29Bb6ead3978CEesupportsInterface(0x27eba962) == true, with an agent whose isSourceNFTOwnershipValid(1) == true. The id itself is the XOR of the five function selectors (Fede re-derived it independently; anyone can). Registries deployed from the reference source MUST advertise it.

On the feedback you asked for, the sovereignty / TBA carve-out, I’d flag it as the one spot most worth scrutiny, because it’s where the naïve implementation is wrong: a bare ownerOf(source) == ownerOf(agentId) check force-fails the legitimate case where the source token is held by the agent’s own ERC-6551 token-bound account (cody raised this). So isSourceNFTOwnershipValid treats three holders as valid — the agent holder, the agent’s canonical 6551 TBA (pinned to registry 0x000000006551c19487814612e58FE06813775758 with the declared impl+salt, not “any TBA”), or the binding contract. If reviewers think that set is too wide or too narrow, that’s the conversation we most want.

Non-normative context: this is the identity layer (Step 1) of the Agent-Service Consultation Flow composition note (28833) the verifiable starting point a paid agent-to-agent consultation builds on, but the interface here stands entirely on its own. Companion to ERC-8217, requires it, doesn’t compete with it.