Draft ERC: Agentic Resource Discovery (ARD) Onchain — an address-rooted value registry whose records are ARD entries

What it claims

ARD (Agentic Resource Discovery), now an open spec under the ards-project working group with Microsoft, Hugging Face, GoDaddy and others, covers discovery only. It has no price, payment, settlement, escrow, credit or demand side, and it roots trust in DNS. This draft adds a value layer underneath ARD while keeping every record a valid ARD entry.

The central design choice is that authority over a record belongs to the address that would be paid, never to a domain. The code lives at garyyang-finchip/ard-onchain-framework on GitHub. The draft is ERCS/erc-9999.md, and 9999 is a placeholder number.

How it works

• Domain as endorsement. An address claims a domain onchain. The domain then acknowledges that address in its own /.well-known/ard.json. Publishers without a key stay discoverable as dormant L0 entries.
• Identity vs. name. The CAIP-19 or CAIP-10 anchor is the identity. The controller's URN is canonical only while a verified binding exists. 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.
• Kind vs. type. The four kinds are skill (an offer), task (a tender), agent (a subject) and registry (an index). They are orthogonal to ARD's type. task is the first ARD entry meant to be read by a supplier looking for work.
• Thin kernel. The kernel stores only:
• the kind
• the anchor
• a JCS + SHA-256 descriptor hash
• the canonical URN
• a status
• domain claims
• a write-once kind table

Prices, escrow balances, credit and identity states are read live from the anchored contracts through kind adapters. Controllers are derived, not stored.

• Hash scope. The descriptor hash excludes the ARD envelope (identifier, trustManifest, @context), so gateway aliases verify against the same commitment.

flowchart TD
  P[Publisher] --> K{Has key / address?}
  K -- no --> L0[Dormant L0 entry]
  K -- yes --> A[Address = root]
  A --> C[Onchain domain claim]
  D[Domain /.well-known/ard.json] --> E[Endorsement verified]
  C --> E
  E --> U[URN canonical]

Evidence

• Contract tests. There are 43 Foundry tests. They run against the real vendored skill-token, task-tender and agent-identity contracts.
• Cross-language vectors. Hashes from ethers v6 + RFC 8785 are checked against solc.
• End-to-end run on anvil. It covers:
• all four kinds
• a record whose hash does not match
• binding states
• a transfer that makes a canonical URN stale
• provenance drift
• a cancelled tender
• Conformance. The official ARD conformance CLI (vendored, schema mode) passes against the gateway with 0 errors and 0 warnings.

How to use it

The Node.js resolver/gateway indexes the kernel and serves:

• POST /search
• POST /explore
• GET /agents
• /.well-known/ard.json

The page gives no install or run commands.

Limits

• Not deployed. There is no Sepolia deployment yet. The ERC PR is not filed, and the upstream proposals to ARD are still pending.
• Partial conformance check. The conformance pass was run in schema mode only.
• Same chain only. v1 supports same-chain anchors only, and cross-chain duplicates become separate records.
• No path for domain-only publishers. A domain-only publisher cannot reach L1 without an address. The author lists this as an open question.
• Open design questions. The author is still asking whether the envelope should be committed in the hash, and what the application/ai-task+json payload is missing.