ERC-8444: Agentic Resource Discovery (ARD) Onchain

What it claims

ERC-8444 is a draft standard that adds pricing, payment and settlement underneath Google's ARD discovery spec while keeping every record a valid ARD entry. ARD itself stops at discovery. It has no price, escrow, credit or demand side, and its trust is rooted in DNS. This draft makes the paid address the only authority over a record. A domain can only endorse an address. The proposal is pre-filing: the PR link reads "to be added after filing", the draft file uses the placeholder number ERCS/erc-9999.md, and the Sepolia deployment and upstream proposals come only after the discussion thread exists.

How it works

• Kernel state: kind, anchor, descriptor hash, canonical URN and status. It also holds domain claims and a write-once kind table. Controllers are derived and never stored. Prices, escrow balances, credit and identity states are not kept in the kernel; kind adapters read them live from the anchored contracts.
• Identity: the CAIP-19 / CAIP-10 anchor is the identity. The controller's URN is canonical only under a verified binding, and every gateway serves every record under its own alias. When a record is transferred, the controller changes, the canonical URN goes stale, and the anchor stays the same.
• Hash scope: the JCS + SHA-256 descriptor hash excludes the ARD envelope (identifier, trustManifest, @context). This lets gateway aliases verify against the same commitment.
• Kinds vs types: the four kinds (skill = offer, task = tender, agent = subject, registry = index) are separate from ARD's type field. The task payload is designed so it could be adopted upstream with no onchain member.

flowchart TD
  P[Publisher] --> K{Has key / address?}
  K -- no --> L0[Dormant L0 entry, discoverable]
  K -- yes --> A[Address controls record]
  A --> C[Claims domain onchain]
  D[/.well-known/ard.json/] -- acknowledges --> C
  C --> E[Domain = endorsement]

Publishers without a key remain discoverable as dormant (L0) entries but have no authority over the record.

Evidence

• 43 Foundry tests run against the real vendored skill-token, task-tender and agent-identity contracts.
• Cross-language hash vectors match between ethers v6 + RFC 8785 and solc.
• An end-to-end run on anvil covers all four kinds, a hash-mismatch record, binding states, a transfer that makes a canonical URN stale, a provenance drift and a cancelled tender.
• The vendored official ARD conformance CLI, in schema mode, reports 0 errors and 0 warnings against the gateway.

How to use it

The repository is garyyang-finchip/ard-onchain-framework on GitHub. It contains:

• the draft text,
• the Solidity kernel and four adapters, built with Foundry,
• a Node.js resolver/gateway that indexes the kernel and serves POST /search, POST /explore, GET /agents and /.well-known/ard.json.

The page gives no install or run commands.

Limits

• Not deployed anywhere public. Sepolia comes later, and all testing so far is local (anvil).
• v1 supports same-chain anchors only. A resource deployed on two chains becomes two separate records.
• Conformance was checked in schema mode only.
• The author has listed four open questions, so these parts may change:
• whether domain-only publishers should have some other path to L1,
• whether the envelope should be committed in the hash,
• the same-chain restriction,
• completeness of the application/ai-task+json payload.
• Companion drafts are referenced only descriptively.