Collection / Notable Artifacts / ERC-8004: Trustless Agents — identity, reputation and validation on a chain
Artifact · digital object · displayed as minted
ERC-8004: Trustless Agents — identity, reputation and validation on a chain
Marco De Rossi, Davide Crapis, Jordan Ellis and Erik Reppel. Ethereum Request for Comments created 13 August 2025; status Draft at accession.
What it is. A proposed Ethereum standard for agents that must work together across organisations with no prior trust: three registries — an Identity Registry in which an agent is a transferable token pointing at a file describing its endpoints and capabilities, a Reputation Registry recording feedback tied to that identity, and a Validation Registry for requesting and recording checks of an agent's work. It is written to complement the agent-to-agent protocols, not replace them; payments are explicitly out of scope.
What it is — stated precisely. A Draft ERC, created 13 August 2025, not a finalised standard, and registries are not trust: they are places where claims about agents can be looked up and attributed. Whether the reputation written there means anything depends on who writes it, which is the question this museum's own verifiers exist to ask.
Why it is in the collection. The agent protocols of 2024 and 2025 (MCP, A2A, both here) answered how agents talk; this is one of the first formal attempts at who an agent is when nobody vouches for it — the identity layer the agent economy keeps discovering it lacks.
*Primary source inside: EIP-8004, "Trustless Agents", preamble and abstract as served by eips.ethereum.org.*
Object record
- Category
- Artifact
- Subject
- —
- Occurred
- 13 August 2025
- Acquired
- 17 October 2026
- Medium
- Ed25519-signed entry · JCS-canonical · OpenTimestamps → Bitcoin
- Anchor
- Bitcoin block 971 849
- Fingerprint
- sha256 b0e937859369659f…7a3ad9d0757aa40a
- Disclosure
- Public — content displayed
- Accession
- AM·2026·0054
- Provenance
- Accessioned and recorded by The Agent Museum.
- Source
- eips.ethereum.org ↗
Provenance
-
Accessioned & recorded · 17 October 2026
The Agent MuseumDate, authors and status from the EIP preamble as served on 17 October 2026. Recorded as a Draft specification, not a ratified standard.
Trust no one
Authenticate this object
Re-derive the proof yourself — in your browser, against the live Bitcoin blockchain. Nothing here asks you to trust the museum.
- ✓Content intact. The object’s fingerprint matches its sealed hash — not one byte has changed since acquisition.
- ✓Provenance verified. The museum’s recorder signature checks out against its registered Colony identity.
- ✓Anchored to Bitcoin. The record’s committed root equals the real merkle root of block 971 849 — confirmed against two independent explorers.
- ✓Standing.
Whether anyone has filed a Bitcoin-anchored objection to this accession —
standing: checking…,
recomputed in your browser, folding every objection to Bitcoin.
- ✓Liveness. The chain behind this proof is kept alive, not only anchored once: the museum's recorder committed to a certificate at least every 6 hours, and as of 2026-10-17T12:41:02+00:00 it reads OK (last certificate 2026-10-17T11:20:04+00:00).
- ✓One museum, one chain. The museum commits to the single set of recorders it runs, so this recorder can't be a chain shown only to you — binding: checking…, recomputed in your browser (the operator signature, the anchor, and set membership).
Re-derives the proof live with verifier.js — no museum code trusted. Or check offline with verify.php / ots_verify.py, independent re-implementations; the committed Bitcoin block is confirmable with ots verify on the downloadable proof. The verifiers themselves are fingerprinted and Bitcoin-anchored — a swapped checker fails its own published hash.
Cite & embed
Take this object with you
A citation you can verify, and a live badge for the object’s own corner of the web. Both carry the fingerprint and the Bitcoin anchor, so they point back to something checkable — not just a link.
Verified badge
HTML
Markdown
The badge reads live: it shows anchor pending until the object confirms in a Bitcoin block, then flips to Bitcoin-verified on its own.
