Skip to content

v0.3.0

Choose a tag to compare

@holistis holistis released this 06 Sep 16:09
· 52 commits to main since this release

capacity-attest is the delivery-receipt layer for x402 agent payments. After a buyer agent pays a seller for capacity (gpu-hours, storage, api-credits, bandwidth), it leaves a signed, factual claim of what was actually delivered, and other agents can read that history before they pay. No reputation score, no token, no lending, no yield.

This release makes capacity-attest a good citizen of the wider agent-economy stack instead of a standalone island. One rule guided the whole release: cite other systems, never re-implement them and never vouch for them.

What is new

externalRefs: an optional block on a claim that can point to other agent-economy infrastructure without capacity-attest verifying it. Six pointer fields: sellerAgentRef and buyerAgentRef (for example an ERC-8004 agent id or a DID), mandateRef and mandateIssuerDid (an externally issued mandate, for example a Google AP2 mandate), intentRef (an external AP2 intent mandate), and disputeContext (for example a Legal Context Protocol reference). These are citations, not verified facts. Same preimage discipline as the measured block in 0.2.0: exactly one optional, never-defaulted key, so every claim recorded before 0.3.0 still hashes bit for bit identically. Enforced by a frozen regression anchor test.

resolve_agent_identity: a new read-only MCP tool that looks up an agent's on-chain identity in an ERC-8004 Identity Registry, using only the standard ERC-721 reads ownerOf and tokenURI. It requires the caller to supply both the registry reference and an RPC endpoint, because ERC-8004 has independent deployments per chain and the spec names no canonical address. It never fetches or trusts what the tokenURI points to. Tested against an injectable fake contract in the suite, and live against the real registry on Base mainnet.

Why we did not build more

We researched whether capacity-attest should build its own identity, authority, intent, execution, settlement, discovery or liability layer. For every one of them the answer was no. Each layer is already covered by better-resourced production infrastructure (ERC-8004, Google AP2, Microsoft Entra Agent ID, the x402 Foundation, the Legal Context Protocol, and more). Building our own would be a worse copy of work that already exists at a scale we cannot match. The full reasoning, per layer, with sources, is in packages/capacity-attest/DECISIONS.md, sections D-007 through D-013.

Also in this release

get_delivery_history now re-verifies every claim's signature when it reads the ledger, not just the shape of the fields. A claim written straight into the ledger file by anything other than record_delivery can no longer be served back as genuine. The tool response and its description now also say plainly that completeness of the shown set rests on the host's honesty, not on cryptography, and the README shows how a buyer can share their own signed claim directly, bypassing any host. See DECISIONS.md D-006.

Two known limits are documented with explicit trigger criteria rather than built ahead of real need: unmetered claim creation (D-014) and unbounded response size (D-015).

474 tests, typecheck and build green.