capacity-attest 0.1.2 → 0.3.0

package/README.md

@@ -1,85 +1,141 @@
-# capacity-attest
-
-MCP-server voor leverings-attestaties bij x402-capaciteitshandel tussen AI-agents.
-
-> Status: MVP, gepubliceerd op npm (`npm install capacity-attest`) en in het officiële MCP-register (`io.github.holistis/capacity-attest`).
-
-## Waarom dit bestaat
-
-Wanneer een AI-agent via het [x402-protocol](https://www.x402.org/) betaalt voor capaciteit (GPU-uren, opslag, API/inference-credits, bandbreedte) bij een andere agent of dienst, is er na de betaling geen bewijs dat het beloofde ook echt geleverd is. De kopende agent weet het zelf (hij zag de output, of zag hem niet), maar die kennis gaat verloren zodra de sessie eindigt. De volgende agent die met dezelfde verkoper zaken wil doen, begint weer blind.
-
-`capacity-attest` lost dat specifieke gat op: na afwikkeling laat de **betalende** agent een cryptografisch ondertekende, feitelijke claim achter (`delivered: yes/no/partial` + een hash van het bewijsmateriaal). Andere agents kunnen die geschiedenis opvragen **voordat** ze zelf met die verkoper in zee gaan.
-
-Geen oordeel. Geen reputatiescore. Geen "vonnis", puur een ondertekende bon-plus-claim, net zoals een afleverbon bij een fysieke levering.
-
-## Wat dit NIET is
-
-Dit is bewust en hardcoded **niet**:
-
-- **Geen reputatiescore of rating.** `get_delivery_history` retourneert de ruwe, chronologische lijst van claims, geen gemiddelde, geen percentage, geen "trust score". Het samenvatten tot één getal is impliciet een oordeel, en dat is expliciet afgewezen tijdens de besluitvorming voor dit project.
-- **Geen financieel product.** Geen rente, geen tijd-disconto op betalingen, geen yield op het ledger-saldo (er ís geen saldo, dit is geen escrow), geen lening, geen onderpand, geen invoice-financing/factoring. `assetType` is een gesloten enum van capaciteitssoorten (`gpu-hours`, `storage`, `api-credits`, `bandwidth`) en bevat bewust niets dat op een financieel instrument lijkt.
-- **Geen eigen token of munt.** Betalingen lopen via x402/USDC zoals gebruikelijk; dit project registreert alleen de *bon* van een afwikkeling die al ergens anders heeft plaatsgevonden.
-- **Geen krediet-verlening.** Een claim wordt pas gemaakt **na** een voltooide betaling. Dit project financiert niets, het documenteert een reeds afgeronde ijara (verhuur/dienst)-transactie.
-
-Dit is een bewuste, formeel getoetste ontwerpkeuze, niet een toevallige scope-beperking. Zie de guardrails-sectie in het project-brief als je overweegt hier iets aan toe te voegen: bij twijfel of een veld/functie hiertegenaan schuurt, laat het weg.
-
-## Hoe het werkt
-
-### 1. `record_delivery`
-
-De betalende agent (de koper) roept dit aan **na** een x402-afwikkeling, zodra bekend is of het beloofde is aangekomen. De claim bevat:
-
-| Veld | Betekenis |
-| --- | --- |
-| `sellerAddress` | 0x-adres van de partij die betaald werd |
-| `buyerAddress` | 0x-adres van de betalende agent, moet overeenkomen met het adres dat uit `signature` wordt teruggerekend |
-| `assetType` | `gpu-hours` \| `storage` \| `api-credits` \| `bandwidth` |
-| `promisedSpec` | Wat er beloofd was: vrije tekst of een gestructureerd object |
-| `delivered` | `yes` \| `no` \| `partial` |
-| `evidenceHash` | sha256-hex van bewijsmateriaal (logs, response-payload, ...), het bewijs zelf wordt niet opgeslagen |
-| `settlementRef` | x402-payment-ref of on-chain tx-hash van de onderliggende betaling |
-| `timestamp` | ISO-8601 tijdstip |
-| `claimId` | content-addressed sha256-hash van alle velden hierboven, zie `computeClaimId()` in `src/schema.ts` |
-| `signature` | EIP-191 personal-sign handtekening van de koper over `claimId` |
-
-De server valideert eerst het schema, dan of `claimId` echt de hash van de inhoud is, en dan of `signature` echt terugrekent naar `buyerAddress`. Alleen dan wordt de claim toegevoegd aan de append-only ledger (`data/claims.jsonl`). Een ongeldige handtekening of een claim die al eerder is opgeslagen (zelfde `claimId`) wordt geweigerd.
-
-### 2. `get_delivery_history`
-
-Gegeven een `sellerAddress`, retourneert dit alle bekende claims tegen die verkoper, chronologisch (oudst eerst). Puur feitelijk, geen samengevat getal. Een kopende agent roept dit aan **vóórdat** hij betaalt, om de ruwe leveringsgeschiedenis van een potentiële verkoper te zien en zelf te beoordelen.
-
-## Ondertekening
-
-De claim wordt ondertekend door de **koper** (de partij die betaalde en dus weet wat er wel/niet aankwam), niet door de verkoper. Dit is bewust eenvoudige EIP-191 `personal_sign` over `claimId` (via `ethers.Signer#signMessage`), geen EIP-712 typed data. Dat houdt het crypto-oppervlak van deze MVP klein en makkelijk te controleren. Een latere upgrade naar EIP-712 (zoals in `mcp-paywall/src/x402.mjs`) is additief mogelijk zonder bestaande claims ongeldig te maken.
-
-## Lokaal draaien
-
-```bash
-npm install
-npm run build      # tsc -> dist/
-npm run typecheck  # tsc --noEmit
-npm test           # vitest run
-npm run demo       # end-to-end lokale demo met TEST-sleutels, geen live infra
-npm start           # start de MCP-server over stdio (bijv. voor Claude Desktop/Code als lokale MCP-server)
-```
-
-De ledger-locatie is instelbaar via `CAPACITY_ATTEST_DATA_DIR` (default: `./data` in dit package). Tests en de demo gebruiken altijd een eigen, wegwerpbare tijdelijke map, nooit de echte `data/` map.
-
-## Architectuur
-
-```
-src/
-  schema.ts        DeliveryClaim zod-schema + content-addressing (computeClaimId, canonicalize)
-  signing.ts        sign/verify van een claim (ethers, EIP-191 personal-sign)
-  ledger.ts          append-only JSONL-opslag (data/claims.jsonl), nooit muteerbaar
-  tools.ts           de daadwerkelijke logica achter beide MCP-tools, transport-onafhankelijk
-  config.ts          waar de ledger-map leeft, lazy zodat tests 'm kunnen overriden
-  index.ts            MCP-server wiring (registreert record_delivery + get_delivery_history)
-examples/demo.ts   end-to-end lokaal voorbeeld met TEST-sleutels
-```
-
-`tools.ts` bevat de eigenlijke business-logica; `index.ts` vertaalt dat alleen naar MCP tool-calls. Zo kunnen tests en de demo dezelfde logica direct aanroepen zonder een stdio-transport op te tuigen.
-
-## Relatie tot x402
-
-Dit project verifieert of settelt zelf géén x402-betalingen, dat gebeurt al bij de betaalstap zelf (zie bijvoorbeeld `mcp-paywall/src/x402.mjs` in dit ecosysteem voor een volledige EIP-3009-verify/settle-implementatie). `settlementRef` verwijst simpelweg naar die reeds-voltooide afwikkeling. Dat betekent ook dat de MVP-koppeling met een echte x402-facilitator eenvoudig kan blijven: `settlementRef` is vrije tekst, met als aanname dat de koper 'm eerlijk invult. Een latere versie kan dat veld optioneel verifiëren tegen een echte facilitator (TODO, niet in deze MVP).
+# capacity-attest
+
+MCP-server voor leverings-attestaties bij x402-capaciteitshandel tussen AI-agents.
+
+> Status: MVP, gepubliceerd op npm (`npm install capacity-attest`) en in het officiële MCP-register (`io.github.holistis/capacity-attest`).
+
+## Waarom dit bestaat
+
+Wanneer een AI-agent via het [x402-protocol](https://www.x402.org/) betaalt voor capaciteit (GPU-uren, opslag, API/inference-credits, bandbreedte) bij een andere agent of dienst, is er na de betaling geen bewijs dat het beloofde ook echt geleverd is. De kopende agent weet het zelf (hij zag de output, of zag hem niet), maar die kennis gaat verloren zodra de sessie eindigt. De volgende agent die met dezelfde verkoper zaken wil doen, begint weer blind.
+
+`capacity-attest` lost dat specifieke gat op: na afwikkeling laat de **betalende** agent een cryptografisch ondertekende, feitelijke claim achter (`delivered: yes/no/partial` + een hash van het bewijsmateriaal). Andere agents kunnen die geschiedenis opvragen **voordat** ze zelf met die verkoper in zee gaan.
+
+Geen oordeel. Geen reputatiescore. Geen "vonnis", puur een ondertekende bon-plus-claim, net zoals een afleverbon bij een fysieke levering.
+
+## Wat dit NIET is
+
+Dit is bewust en hardcoded **niet**:
+
+- **Geen reputatiescore of rating.** `get_delivery_history` retourneert de ruwe, chronologische lijst van claims, geen gemiddelde, geen percentage, geen "trust score". Het samenvatten tot één getal is impliciet een oordeel, en dat is expliciet afgewezen tijdens de besluitvorming voor dit project.
+- **Geen financieel product.** Geen rente, geen tijd-disconto op betalingen, geen yield op het ledger-saldo (er ís geen saldo, dit is geen escrow), geen lening, geen onderpand, geen invoice-financing/factoring. `assetType` is een gesloten enum van capaciteitssoorten (`gpu-hours`, `storage`, `api-credits`, `bandwidth`) en bevat bewust niets dat op een financieel instrument lijkt.
+- **Geen eigen token of munt.** Betalingen lopen via x402/USDC zoals gebruikelijk; dit project registreert alleen de *bon* van een afwikkeling die al ergens anders heeft plaatsgevonden.
+- **Geen krediet-verlening.** Een claim wordt pas gemaakt **na** een voltooide betaling. Dit project financiert niets, het documenteert een reeds afgeronde ijara (verhuur/dienst)-transactie.
+- **Geen eigen identity-, autoriteits- of geschillenlaag.** `externalRefs` (zie hieronder) is puur een citaat naar een systeem van een ander (ERC-8004, AP2, Legal Context Protocol, ...). Dit project resolvet, verifieert of beoordeelt die verwijzing zelf nooit. Zie [DECISIONS.md](./DECISIONS.md) D-007 t/m D-013 voor waarom dit bewust geen eigen protocol is geworden.
+
+Dit is een bewuste, formeel getoetste ontwerpkeuze, niet een toevallige scope-beperking. Zie de guardrails-sectie in het project-brief als je overweegt hier iets aan toe te voegen: bij twijfel of een veld/functie hiertegenaan schuurt, laat het weg.
+
+Bewust uitgestelde features (verankering, tussentijdse status, formele conformance-vectoren), inclusief de precieze voorwaarde waaronder we ze alsnog zouden bouwen: zie [DECISIONS.md](./DECISIONS.md).
+
+## Hoe het werkt
+
+### 1. `record_delivery`
+
+De betalende agent (de koper) roept dit aan **na** een x402-afwikkeling, zodra bekend is of het beloofde is aangekomen. De claim bevat:
+
+| Veld | Betekenis |
+| --- | --- |
+| `sellerAddress` | 0x-adres van de partij die betaald werd |
+| `buyerAddress` | 0x-adres van de betalende agent, moet overeenkomen met het adres dat uit `signature` wordt teruggerekend |
+| `assetType` | `gpu-hours` \| `storage` \| `api-credits` \| `bandwidth` |
+| `promisedSpec` | Wat er beloofd was: vrije tekst of een gestructureerd object |
+| `delivered` | `yes` \| `no` \| `partial` |
+| `evidenceHash` | sha256-hex van bewijsmateriaal (logs, response-payload, ...), het bewijs zelf wordt niet opgeslagen |
+| `settlementRef` | x402-payment-ref of on-chain tx-hash van de onderliggende betaling |
+| `timestamp` | ISO-8601 tijdstip |
+| `claimId` | content-addressed sha256-hash van alle velden hierboven, zie `computeClaimId()` in `src/schema.ts` |
+| `signature` | EIP-191 personal-sign handtekening van de koper over `claimId` |
+| `externalRefs` | *(optioneel, sinds 0.3.0)* ongeverifieerde verwijzingen naar andere agent-economie-infrastructuur: `sellerAgentRef`/`buyerAgentRef` (bv. een ERC-8004-agent-id of DID), `mandateRef`+`mandateIssuerDid` (een extern uitgegeven AP2/AAE-mandaat), `intentRef` (een extern AP2 IntentMandate), `disputeContext` (`protocol`+`termsHash`+optioneel `resolutionRef`, bv. een Legal Context Protocol-verwijzing). Zie [DECISIONS.md](./DECISIONS.md) D-007 t/m D-013 |
+
+De server valideert eerst het schema, dan of `claimId` echt de hash van de inhoud is, en dan of `signature` echt terugrekent naar `buyerAddress`. Alleen dan wordt de claim toegevoegd aan de append-only ledger (`data/claims.jsonl`). Een ongeldige handtekening of een claim die al eerder is opgeslagen (zelfde `claimId`) wordt geweigerd.
+
+### 2. `get_delivery_history`
+
+Gegeven een `sellerAddress`, retourneert dit alle bekende claims tegen die verkoper op déze installatie, chronologisch (oudst eerst). Puur feitelijk, geen samengevat getal. Een kopende agent roept dit aan **vóórdat** hij betaalt, om de ruwe leveringsgeschiedenis van een potentiële verkoper te zien en zelf te beoordelen.
+
+Het antwoord bevat naast `sellerAddress`, `count` en `claims` ook `scope` (altijd `"local-ledger"`) en `note`: een vaste, feitelijke tekst die uitlegt dat dit resultaat alleen de lokale ledger van déze installatie weerspiegelt. Een lege of korte geschiedenis betekent niet dat de verkoper een schone staat van dienst heeft, het kan ook betekenen dat er hier simpelweg nog geen claims zijn vastgelegd. Zie [DECISIONS.md](./DECISIONS.md) (D-005) voor de bredere architectuurvraag hierachter: hoe vindt een koper claims die op een ándere installatie zijn vastgelegd.
+
+### 3. `resolve_agent_identity` *(sinds 0.3.0)*
+
+Read-only opzoeking tegen een ERC-8004 Identity Registry: wie bezit `agentId` (`ownerOf`) en waar staat zijn registratiebestand (`tokenURI`). Alleen de standaard ERC-721-interface wordt aangeroepen, niets ERC-8004-specifieks. Vereist van de aanroeper zowel `agentRegistryRef` (`"eip155:<chainId>:<registryAddress>"`) als een `rpcUrl` voor die chain: dit project bundelt bewust geen eigen RPC-provider en geen canoniek registry-adres, want ERC-8004 heeft onafhankelijke deployments per chain en de EIP-tekst zelf noemt geen vast adres. Haalt bewust NOOIT op wat `tokenURI` aanwijst (dat blijft een pointer die de aanroeper zelf desgewenst opvraagt); dat zou een SSRF-vormig risico zijn op aanroeper-gecontroleerde on-chain data.
+
+Getest tegen een injecteerbare `ContractFactory` (`src/erc8004.test.ts`, geen netwerkafhankelijkheid) én live tegen de echte, gedeployde registry op Base mainnet (`examples/verify-erc8004-live.mjs`, `npm run build && node examples/verify-erc8004-live.mjs`). Zie [DECISIONS.md](./DECISIONS.md) D-007 voor de volledige achtergrond.
+
+## Ondertekening
+
+De claim wordt ondertekend door de **koper** (de partij die betaalde en dus weet wat er wel/niet aankwam), niet door de verkoper. Dit is bewust eenvoudige EIP-191 `personal_sign` over `claimId` (via `ethers.Signer#signMessage`), geen EIP-712 typed data. Dat houdt het crypto-oppervlak van deze MVP klein en makkelijk te controleren. Een latere upgrade naar EIP-712 (zoals in `mcp-paywall/src/x402.mjs`) is additief mogelijk zonder bestaande claims ongeldig te maken.
+
+## Een claim onafhankelijk verifiëren
+
+Elke claim in de ledger is met alleen het npm-package en de rauwe claim-bytes na te rekenen, zonder toegang tot dit project of een netwerkoproep naar ons. Geen account, geen hosted call.
+
+```bash
+npm install capacity-attest@0.2.0
+```
+
+```js
+// verify.mjs, als ES module draaien (top-level await)
+import { verifyClaim } from "capacity-attest/dist/signing.js";
+
+const claim = JSON.parse(await (await fetch("<url naar een claim.jsonl-regel>")).text());
+console.log(verifyClaim(claim));
+// { ok: true } als claimId echt de hash van de inhoud is EN signature echt naar buyerAddress terugrekent
+```
+
+Let op: importeer `capacity-attest/dist/signing.js` rechtstreeks, niet het package-root. De root (`dist/index.js`) start bij het importeren meteen de MCP-server over stdio, wat een los verificatie-script laat hangen.
+
+`verifyClaim()` controleert precies twee dingen: dat `claimId` de content-addressed hash van de claim-velden is, en dat `signature` (EIP-191) terugrekent naar `buyerAddress`. Het controleert niet of de onderliggende afwikkeling (`settlementRef`) echt on-chain klopt, dat is een losse, aparte check tegen de betreffende chain, en het controleert niet of `delivered` waar is of of `evidenceHash` een echt bewijsstuk dekt, dat blijft de eigen verklaring van de kopende agent.
+
+Een werkend, extern gereproduceerd voorbeeld van deze exacte stappen staat in [github.com/YE-YI7/asm-spec, PR #18](https://github.com/YE-YI7/asm-spec/pull/18): een onafhankelijk project dat dit tegen een echte, live geregistreerde claim heeft gedraaid.
+
+## Je eigen ingediende claims delen, los van een host (D-006)
+
+`get_delivery_history` vertrouwt op de eerlijkheid van wie de MCP-server bedient: zie de `note` in dat tool-antwoord en [DECISIONS.md](./DECISIONS.md) (D-006). Elke getoonde claim is wel degelijk echt (ondertekening wordt sinds 2026-09-06 ook bij het lezen opnieuw gecontroleerd, niet alleen bij het schrijven), maar niets bewijst dat de host de VOLLEDIGE set laat zien die hij daadwerkelijk heeft.
+
+Als jij zelf de koper bent die een claim indiende, hoef je op die host niet te wachten: jij hebt die claim zelf al ondertekend, dus jij kan 'm rechtstreeks aan een wantrouwende tegenpartij laten zien, buiten elke host om.
+
+```js
+// export-my-claims.mjs
+import { claimsForSeller } from "capacity-attest/dist/ledger.js";
+
+const myAddress = "0x...";     // jouw buyerAddress
+const seller = "0x...";        // de verkoper waar het over gaat
+
+const mine = (await claimsForSeller(seller)).filter(
+  (c) => c.buyerAddress.toLowerCase() === myAddress.toLowerCase(),
+);
+console.log(JSON.stringify(mine, null, 2));
+```
+
+Elke claim in die lijst is zelfstandig verifieerbaar met `verifyClaim()` (zie hierboven), zonder dat de ontvanger jouw installatie of enige host hoeft te vertrouwen. Dit lost geen vindbaarheid op (D-005: hoe vindt iemand anders jouw claim zonder dat jij 'm deelt) en geen volledigheid over ALLE kopers samen (D-006: dit bewijst alleen wat JIJ indiende, niet wat een host verder mogelijk verzwijgt van andere kopers), maar het geeft een concrete, kosteloze manier om één specifiek geschil te bewijzen zonder een host te hoeven vertrouwen.
+
+## Lokaal draaien
+
+```bash
+npm install
+npm run build      # tsc -> dist/
+npm run typecheck  # tsc --noEmit
+npm test           # vitest run
+npm run demo       # end-to-end lokale demo met TEST-sleutels, geen live infra
+npm start           # start de MCP-server over stdio (bijv. voor Claude Desktop/Code als lokale MCP-server)
+```
+
+De ledger-locatie is instelbaar via `CAPACITY_ATTEST_DATA_DIR` (default: `./data` in dit package). Tests en de demo gebruiken altijd een eigen, wegwerpbare tijdelijke map, nooit de echte `data/` map.
+
+## Architectuur
+
+```text
+src/
+  schema.ts        DeliveryClaim zod-schema + content-addressing (computeClaimId, canonicalize)
+  signing.ts        sign/verify van een claim (ethers, EIP-191 personal-sign)
+  ledger.ts          append-only JSONL-opslag (data/claims.jsonl), nooit muteerbaar
+  tools.ts           de daadwerkelijke logica achter beide MCP-tools, transport-onafhankelijk
+  config.ts          waar de ledger-map leeft, lazy zodat tests 'm kunnen overriden
+  index.ts            MCP-server wiring (registreert record_delivery + get_delivery_history)
+examples/demo.ts   end-to-end lokaal voorbeeld met TEST-sleutels
+```
+
+`tools.ts` bevat de eigenlijke business-logica; `index.ts` vertaalt dat alleen naar MCP tool-calls. Zo kunnen tests en de demo dezelfde logica direct aanroepen zonder een stdio-transport op te tuigen.
+
+## Relatie tot x402
+
+Dit project verifieert of settelt zelf géén x402-betalingen, dat gebeurt al bij de betaalstap zelf (zie bijvoorbeeld `mcp-paywall/src/x402.mjs` in dit ecosysteem voor een volledige EIP-3009-verify/settle-implementatie). `settlementRef` verwijst simpelweg naar die reeds-voltooide afwikkeling. Dat betekent ook dat de MVP-koppeling met een echte x402-facilitator eenvoudig kan blijven: `settlementRef` is vrije tekst, met als aanname dat de koper 'm eerlijk invult. Een latere versie kan dat veld optioneel verifiëren tegen een echte facilitator (TODO, niet in deze MVP).

package/dist/erc8004.d.ts

@@ -0,0 +1,39 @@
+import * as z from "zod/v4";
+export declare const ResolveAgentIdentityInputSchema: z.ZodObject<{
+    agentRegistryRef: z.ZodString;
+    agentId: z.ZodString;
+    rpcUrl: z.ZodString;
+}, z.core.$strip>;
+export type ResolveAgentIdentityInput = z.infer<typeof ResolveAgentIdentityInputSchema>;
+export type ResolveAgentIdentityResult = {
+    ok: true;
+    chainId: string;
+    registryAddress: string;
+    agentId: string;
+    owner: string;
+    tokenUri: string;
+} | {
+    ok: false;
+    reason: string;
+};
+/** The minimal read surface this module needs — real ethers.Contract satisfies this shape structurally. */
+export interface Erc721ReadContract {
+    ownerOf(agentId: bigint): Promise<string>;
+    tokenURI(agentId: bigint): Promise<string>;
+}
+/**
+ * Dependency-injection seam so tests can supply a fake contract instead of
+ * making a real network call, without needing to fake ethers' own ABI
+ * encoding/decoding. Defaults to a real ethers Contract over a real
+ * JsonRpcProvider.
+ */
+export type ContractFactory = (registryAddress: string, rpcUrl: string) => Erc721ReadContract;
+/**
+ * Read-only lookup against an ERC-8004 Identity Registry: who owns
+ * `agentId` (`ownerOf`) and where its registration file lives (`tokenURI`).
+ * Never resolves, verifies, or trusts the content the returned `tokenUri`
+ * points to — see file header. This is the logic behind the
+ * `resolve_agent_identity` MCP tool.
+ */
+export declare function resolveAgentIdentity(input: ResolveAgentIdentityInput, contractFactory?: ContractFactory): Promise<ResolveAgentIdentityResult>;
+//# sourceMappingURL=erc8004.d.ts.map

package/dist/erc8004.d.ts.map

@@ -0,0 +1 @@
+{"version":3,"file":"erc8004.d.ts","sourceRoot":"","sources":["../src/erc8004.ts"],"names":[],"mappings":"AAiCA,OAAO,KAAK,CAAC,MAAM,QAAQ,CAAC;AA2B5B,eAAO,MAAM,+BAA+B;;;;iBAM1C,CAAC;AACH,MAAM,MAAM,yBAAyB,GAAG,CAAC,CAAC,KAAK,CAAC,OAAO,+BAA+B,CAAC,CAAC;AAExF,MAAM,MAAM,0BAA0B,GAClC;IAAE,EAAE,EAAE,IAAI,CAAC;IAAC,OAAO,EAAE,MAAM,CAAC;IAAC,eAAe,EAAE,MAAM,CAAC;IAAC,OAAO,EAAE,MAAM,CAAC;IAAC,KAAK,EAAE,MAAM,CAAC;IAAC,QAAQ,EAAE,MAAM,CAAA;CAAE,GACxG;IAAE,EAAE,EAAE,KAAK,CAAC;IAAC,MAAM,EAAE,MAAM,CAAA;CAAE,CAAC;AAwBlC,2GAA2G;AAC3G,MAAM,WAAW,kBAAkB;IACjC,OAAO,CAAC,OAAO,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,CAAC,CAAC;IAC1C,QAAQ,CAAC,OAAO,EAAE,MAAM,GAAG,OAAO,CAAC,MAAM,CAAC,CAAC;CAC5C;AAED;;;;;GAKG;AACH,MAAM,MAAM,eAAe,GAAG,CAAC,eAAe,EAAE,MAAM,EAAE,MAAM,EAAE,MAAM,KAAK,kBAAkB,CAAC;AAO9F;;;;;;GAMG;AACH,wBAAsB,oBAAoB,CACxC,KAAK,EAAE,yBAAyB,EAChC,eAAe,GAAE,eAAwC,GACxD,OAAO,CAAC,0BAA0B,CAAC,CA8BrC"}

package/dist/erc8004.js

@@ -0,0 +1,122 @@
+// erc8004.ts — read-only resolution against an ERC-8004 Identity Registry.
+//
+// ERC-8004 ("Trustless Agents") defines its Identity Registry as a standard
+// ERC-721 contract: an agent's on-chain identity IS an NFT, `agentId` IS the
+// tokenId. There is no bespoke `getAgent()` function in the spec — lookup is
+// exactly `ownerOf(agentId)` (who controls this identity) and
+// `tokenURI(agentId)` (a pointer to the agent's registration file: an IPFS/
+// HTTPS/data URI, per eips.ethereum.org/EIPS/eip-8004, confirmed 2026-09-06
+// against the spec text directly). This module calls only those two
+// standard, universal ERC-721 read functions — nothing ERC-8004-specific.
+//
+// Deliberately NOT done here: fetching or parsing what `tokenURI` points to.
+// That string is caller-controlled data embedded in on-chain state by
+// whoever registered the agent, and auto-fetching it (an ipfs:// gateway
+// call, or a fetch to an arbitrary https:// URL surfaced from someone
+// else's on-chain write) is a real SSRF-shaped risk this project does not
+// need to take on for a read-only identity check. Callers get the raw
+// tokenUri string back and decide for themselves whether and how to fetch
+// it — same "cite, never resolve further" posture as externalRefs
+// (DECISIONS.md D-007).
+//
+// Deliberately NOT hardcoded here: any specific registry contract address
+// or chain RPC endpoint. ERC-8004 is deployed independently on multiple
+// chains (mainnet, Base, and others per the EIP's own multi-chain design),
+// and the EIP text itself lists no canonical deployment address anywhere.
+// Guessing one would risk querying the wrong contract and returning
+// misleading data. Both the registry reference and the RPC endpoint are
+// therefore required, caller-supplied inputs — this module is a thin,
+// chain-agnostic resolver, never an authority on which deployment is "the"
+// one, and never a source of its own RPC credentials for a published
+// open-source package to leak or rate-limit on other people's behalf.
+import { ethers } from "ethers";
+import * as z from "zod/v4";
+// The EIP's own compound reference format: "{namespace}:{chainId}:
+// {identityRegistry}", namespace fixed to "eip155" for EVM chains
+// (CAIP-2/CAIP-10-style). Captures chainId and the registry contract
+// address separately; the address half accepts either case, normalized to
+// lower case in the result, same convention as sellerAddress/buyerAddress
+// in schema.ts.
+const AGENT_REGISTRY_REF_RE = /^eip155:(\d+):(0x[0-9a-fA-F]{40})$/;
+// ERC-721's two standard read functions. This is the ENTIRE interface this
+// module depends on — see the file header for why nothing ERC-8004-specific
+// is needed.
+const ERC721_READ_ABI = ["function ownerOf(uint256 tokenId) view returns (address)", "function tokenURI(uint256 tokenId) view returns (string)"];
+// uint256's maximum value (2^256 - 1) has exactly 78 decimal digits. A
+// longer digit string can never be a valid ERC-721 tokenId; bounding the
+// length before BigInt() parses it avoids handing an unboundedly large
+// digit string to the runtime's bignum parser.
+const MAX_AGENT_ID_DIGITS = 78;
+const CALL_TIMEOUT_MS = 8_000;
+// Mirrors the plain-TS validation below in isValidAgentId/isHttpUrl at the
+// MCP tool-input boundary (index.ts's inputSchema), so a caller gets a
+// schema-shaped rejection before resolveAgentIdentity() is even called.
+// The runtime function still re-checks everything itself, since it is
+// also callable directly (tests, examples), not only through the MCP tool.
+export const ResolveAgentIdentityInputSchema = z.object({
+    agentRegistryRef: z
+        .string()
+        .describe('Compound ERC-8004 registry reference: "eip155:<chainId>:<registryAddress>", e.g. "eip155:1:0x1234567890123456789012345678901234567890"'),
+    agentId: z.string().describe("The ERC-721 tokenId / ERC-8004 agentId, as a decimal string"),
+    rpcUrl: z.string().describe("JSON-RPC endpoint (http:// or https://) for the chain named in agentRegistryRef — never assumed or defaulted"),
+});
+function isValidAgentId(v) {
+    return v.length <= MAX_AGENT_ID_DIGITS && /^(0|[1-9][0-9]*)$/.test(v);
+}
+function isHttpUrl(v) {
+    try {
+        const protocol = new URL(v).protocol;
+        return protocol === "http:" || protocol === "https:";
+    }
+    catch {
+        return false;
+    }
+}
+function withTimeout(p, ms) {
+    return Promise.race([
+        p,
+        new Promise((_, reject) => {
+            setTimeout(() => reject(new Error(`timed out after ${ms}ms`)), ms);
+        }),
+    ]);
+}
+const defaultContractFactory = (registryAddress, rpcUrl) => {
+    const provider = new ethers.JsonRpcProvider(rpcUrl);
+    return new ethers.Contract(registryAddress, ERC721_READ_ABI, provider);
+};
+/**
+ * Read-only lookup against an ERC-8004 Identity Registry: who owns
+ * `agentId` (`ownerOf`) and where its registration file lives (`tokenURI`).
+ * Never resolves, verifies, or trusts the content the returned `tokenUri`
+ * points to — see file header. This is the logic behind the
+ * `resolve_agent_identity` MCP tool.
+ */
+export async function resolveAgentIdentity(input, contractFactory = defaultContractFactory) {
+    const match = AGENT_REGISTRY_REF_RE.exec(input.agentRegistryRef);
+    if (!match) {
+        return {
+            ok: false,
+            reason: 'agentRegistryRef must match "eip155:<chainId>:<registryAddress>", e.g. "eip155:1:0x1234567890123456789012345678901234567890"',
+        };
+    }
+    const chainId = match[1];
+    const registryAddress = match[2];
+    if (!isValidAgentId(input.agentId)) {
+        return { ok: false, reason: "agentId must be a non-negative decimal integer string (no leading zeros, no sign, at most 78 digits)" };
+    }
+    if (!isHttpUrl(input.rpcUrl)) {
+        return { ok: false, reason: "rpcUrl must be an http:// or https:// URL" };
+    }
+    let owner;
+    let tokenUri;
+    try {
+        const contract = contractFactory(registryAddress, input.rpcUrl);
+        const agentIdBig = BigInt(input.agentId);
+        [owner, tokenUri] = await withTimeout(Promise.all([contract.ownerOf(agentIdBig), contract.tokenURI(agentIdBig)]), CALL_TIMEOUT_MS);
+    }
+    catch (e) {
+        return { ok: false, reason: `on-chain lookup failed: ${e.message}` };
+    }
+    return { ok: true, chainId, registryAddress: registryAddress.toLowerCase(), agentId: input.agentId, owner, tokenUri };
+}
+//# sourceMappingURL=erc8004.js.map

package/dist/erc8004.js.map

@@ -0,0 +1 @@
+{"version":3,"file":"erc8004.js","sourceRoot":"","sources":["../src/erc8004.ts"],"names":[],"mappings":"AAAA,2EAA2E;AAC3E,EAAE;AACF,4EAA4E;AAC5E,6EAA6E;AAC7E,6EAA6E;AAC7E,8DAA8D;AAC9D,4EAA4E;AAC5E,4EAA4E;AAC5E,oEAAoE;AACpE,0EAA0E;AAC1E,EAAE;AACF,6EAA6E;AAC7E,sEAAsE;AACtE,yEAAyE;AACzE,sEAAsE;AACtE,0EAA0E;AAC1E,sEAAsE;AACtE,0EAA0E;AAC1E,kEAAkE;AAClE,wBAAwB;AACxB,EAAE;AACF,0EAA0E;AAC1E,wEAAwE;AACxE,2EAA2E;AAC3E,0EAA0E;AAC1E,oEAAoE;AACpE,wEAAwE;AACxE,sEAAsE;AACtE,2EAA2E;AAC3E,qEAAqE;AACrE,sEAAsE;AAEtE,OAAO,EAAE,MAAM,EAAE,MAAM,QAAQ,CAAC;AAChC,OAAO,KAAK,CAAC,MAAM,QAAQ,CAAC;AAE5B,mEAAmE;AACnE,kEAAkE;AAClE,qEAAqE;AACrE,0EAA0E;AAC1E,0EAA0E;AAC1E,gBAAgB;AAChB,MAAM,qBAAqB,GAAG,oCAAoC,CAAC;AAEnE,2EAA2E;AAC3E,4EAA4E;AAC5E,aAAa;AACb,MAAM,eAAe,GAAG,CAAC,0DAA0D,EAAE,0DAA0D,CAAC,CAAC;AAEjJ,uEAAuE;AACvE,yEAAyE;AACzE,uEAAuE;AACvE,+CAA+C;AAC/C,MAAM,mBAAmB,GAAG,EAAE,CAAC;AAC/B,MAAM,eAAe,GAAG,KAAK,CAAC;AAE9B,2EAA2E;AAC3E,uEAAuE;AACvE,wEAAwE;AACxE,sEAAsE;AACtE,2EAA2E;AAC3E,MAAM,CAAC,MAAM,+BAA+B,GAAG,CAAC,CAAC,MAAM,CAAC;IACtD,gBAAgB,EAAE,CAAC;SAChB,MAAM,EAAE;SACR,QAAQ,CAAC,wIAAwI,CAAC;IACrJ,OAAO,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,CAAC,6DAA6D,CAAC;IAC3F,MAAM,EAAE,CAAC,CAAC,MAAM,EAAE,CAAC,QAAQ,CAAC,8GAA8G,CAAC;CAC5I,CAAC,CAAC;AAOH,SAAS,cAAc,CAAC,CAAS;IAC/B,OAAO,CAAC,CAAC,MAAM,IAAI,mBAAmB,IAAI,mBAAmB,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;AACxE,CAAC;AAED,SAAS,SAAS,CAAC,CAAS;IAC1B,IAAI,CAAC;QACH,MAAM,QAAQ,GAAG,IAAI,GAAG,CAAC,CAAC,CAAC,CAAC,QAAQ,CAAC;QACrC,OAAO,QAAQ,KAAK,OAAO,IAAI,QAAQ,KAAK,QAAQ,CAAC;IACvD,CAAC;IAAC,MAAM,CAAC;QACP,OAAO,KAAK,CAAC;IACf,CAAC;AACH,CAAC;AAED,SAAS,WAAW,CAAI,CAAa,EAAE,EAAU;IAC/C,OAAO,OAAO,CAAC,IAAI,CAAC;QAClB,CAAC;QACD,IAAI,OAAO,CAAI,CAAC,CAAC,EAAE,MAAM,EAAE,EAAE;YAC3B,UAAU,CAAC,GAAG,EAAE,CAAC,MAAM,CAAC,IAAI,KAAK,CAAC,mBAAmB,EAAE,IAAI,CAAC,CAAC,EAAE,EAAE,CAAC,CAAC;QACrE,CAAC,CAAC;KACH,CAAC,CAAC;AACL,CAAC;AAgBD,MAAM,sBAAsB,GAAoB,CAAC,eAAe,EAAE,MAAM,EAAE,EAAE;IAC1E,MAAM,QAAQ,GAAG,IAAI,MAAM,CAAC,eAAe,CAAC,MAAM,CAAC,CAAC;IACpD,OAAO,IAAI,MAAM,CAAC,QAAQ,CAAC,eAAe,EAAE,eAAe,EAAE,QAAQ,CAAkC,CAAC;AAC1G,CAAC,CAAC;AAEF;;;;;;GAMG;AACH,MAAM,CAAC,KAAK,UAAU,oBAAoB,CACxC,KAAgC,EAChC,kBAAmC,sBAAsB;IAEzD,MAAM,KAAK,GAAG,qBAAqB,CAAC,IAAI,CAAC,KAAK,CAAC,gBAAgB,CAAC,CAAC;IACjE,IAAI,CAAC,KAAK,EAAE,CAAC;QACX,OAAO;YACL,EAAE,EAAE,KAAK;YACT,MAAM,EAAE,8HAA8H;SACvI,CAAC;IACJ,CAAC;IACD,MAAM,OAAO,GAAG,KAAK,CAAC,CAAC,CAAE,CAAC;IAC1B,MAAM,eAAe,GAAG,KAAK,CAAC,CAAC,CAAE,CAAC;IAElC,IAAI,CAAC,cAAc,CAAC,KAAK,CAAC,OAAO,CAAC,EAAE,CAAC;QACnC,OAAO,EAAE,EAAE,EAAE,KAAK,EAAE,MAAM,EAAE,sGAAsG,EAAE,CAAC;IACvI,CAAC;IAED,IAAI,CAAC,SAAS,CAAC,KAAK,CAAC,MAAM,CAAC,EAAE,CAAC;QAC7B,OAAO,EAAE,EAAE,EAAE,KAAK,EAAE,MAAM,EAAE,2CAA2C,EAAE,CAAC;IAC5E,CAAC;IAED,IAAI,KAAa,CAAC;IAClB,IAAI,QAAgB,CAAC;IACrB,IAAI,CAAC;QACH,MAAM,QAAQ,GAAG,eAAe,CAAC,eAAe,EAAE,KAAK,CAAC,MAAM,CAAC,CAAC;QAChE,MAAM,UAAU,GAAG,MAAM,CAAC,KAAK,CAAC,OAAO,CAAC,CAAC;QACzC,CAAC,KAAK,EAAE,QAAQ,CAAC,GAAG,MAAM,WAAW,CAAC,OAAO,CAAC,GAAG,CAAC,CAAC,QAAQ,CAAC,OAAO,CAAC,UAAU,CAAC,EAAE,QAAQ,CAAC,QAAQ,CAAC,UAAU,CAAC,CAAC,CAAC,EAAE,eAAe,CAAC,CAAC;IACrI,CAAC;IAAC,OAAO,CAAC,EAAE,CAAC;QACX,OAAO,EAAE,EAAE,EAAE,KAAK,EAAE,MAAM,EAAE,2BAA4B,CAAW,CAAC,OAAO,EAAE,EAAE,CAAC;IAClF,CAAC;IAED,OAAO,EAAE,EAAE,EAAE,IAAI,EAAE,OAAO,EAAE,eAAe,EAAE,eAAe,CAAC,WAAW,EAAE,EAAE,OAAO,EAAE,KAAK,CAAC,OAAO,EAAE,KAAK,EAAE,QAAQ,EAAE,CAAC;AACxH,CAAC"}

package/dist/index.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AASA,OAAO,EAAE,WAAW,EAAE,gBAAgB,EAA2C,MAAM,aAAa,CAAC;AAwDrG,OAAO,EAAE,WAAW,EAAE,gBAAgB,EAAE,CAAC"}
+{"version":3,"file":"index.d.ts","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AASA,OAAO,EAAE,WAAW,EAAE,gBAAgB,EAA2C,MAAM,aAAa,CAAC;AAkGrG,OAAO,EAAE,WAAW,EAAE,gBAAgB,EAAE,CAAC"}

package/dist/index.js

@@ -7,6 +7,7 @@ import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
 import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
 import { ASSET_TYPES, DELIVERED_VALUES, ClaimContentSchema, DeliveryClaimSchema } from "./schema.js";
 import { recordDelivery, getDeliveryHistory } from "./tools.js";
+import { resolveAgentIdentity, ResolveAgentIdentityInputSchema } from "./erc8004.js";
 const server = new McpServer({
     name: "capacity-attest",
     version: "0.1.0",
@@ -34,15 +35,52 @@ server.registerTool("record_delivery", {
 });
 server.registerTool("get_delivery_history", {
     title: "Get a seller's delivery history",
-    description: "Return every known, signature-verified delivery claim recorded against a given sellerAddress, oldest first. " +
-        "Purely factual — no aggregate score, rating, or reputation judgment is computed. A buying agent can call this " +
-        "BEFORE paying a seller to see that seller's raw delivery history for gpu-hours, storage, api-credits, and " +
-        "bandwidth claims.",
+    description: "Return every signature-verified delivery claim recorded against a given sellerAddress in THIS installation's " +
+        "local ledger, oldest first. Purely factual — no aggregate score, rating, or reputation judgment is computed. " +
+        "IMPORTANT, two separate caveats, both repeated in the response's own `note` field: (1) this is scoped to the " +
+        "local ledger only — a different installation may hold other claims against the same seller that this call " +
+        "cannot see, so an empty or short result does NOT mean the seller has a clean record elsewhere, only that no " +
+        "claims have been recorded here; (2) even within this installation, a shown claim's signature is genuinely " +
+        "verified, but nothing proves this is the COMPLETE set of claims the operator actually holds — completeness " +
+        "depends on the operator's honesty, not cryptography. " +
+        "A buying agent can call this BEFORE paying a seller to see that seller's raw delivery history for gpu-hours, " +
+        "storage, api-credits, and bandwidth claims.",
     inputSchema: {
         sellerAddress: ClaimContentSchema.shape.sellerAddress,
     },
 }, async ({ sellerAddress }) => {
-    return textResult(await getDeliveryHistory(sellerAddress));
+    // NINTH FIX (2026-09-06, found by the same adversarial audit as the
+    // ledger.ts SEVENTH/EIGHTH fixes): every other handler/entry point in
+    // this codebase (record_delivery below, recordDelivery() in tools.ts)
+    // is deliberately wrapped so untrusted-input-triggered errors degrade to
+    // the tool's normal {ok:false}/errorResult contract instead of an
+    // uncaught exception — this handler was the one place that discipline
+    // was not applied. A real fs error surfaced from getFreshCache()/
+    // resyncFromDisk() (e.g. a transient EACCES/EBUSY, deliberately made
+    // non-swallowed by an earlier fix in ledger.ts) would otherwise escape
+    // this handler unhandled instead of returning a normal error result.
+    try {
+        return textResult(await getDeliveryHistory(sellerAddress));
+    }
+    catch (e) {
+        return errorResult(e.message);
+    }
+});
+server.registerTool("resolve_agent_identity", {
+    title: "Resolve an ERC-8004 agent identity (read-only, on-chain)",
+    description: "Look up an agent's on-chain identity registration in an ERC-8004 Identity Registry: who owns the agentId " +
+        "(ownerOf) and where its registration file lives (tokenURI). Read-only — never writes anything, never touches " +
+        "the delivery ledger. Requires the caller to supply BOTH the registry reference (chain + contract address) AND " +
+        "an RPC endpoint for that chain: this tool does not assume, default, or bundle its own RPC provider or a " +
+        "canonical registry address, since ERC-8004 has independent deployments on multiple chains. This tool does NOT " +
+        "fetch or parse what tokenURI points to — it returns that pointer as-is for the caller to resolve themselves. " +
+        "capacity-attest never verifies or endorses what an ERC-8004 registration claims; see DECISIONS.md D-007.",
+    inputSchema: ResolveAgentIdentityInputSchema.shape,
+}, async (args) => {
+    const result = await resolveAgentIdentity(args);
+    if (!result.ok)
+        return errorResult(result.reason);
+    return textResult(result);
 });
 // Re-exported so callers embedding this package can reference the same enums
 // / schema the tools validate against without duplicating them.

package/dist/index.js.map

@@ -1 +1 @@
-{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AACA,yEAAyE;AACzE,2EAA2E;AAC3E,oDAAoD;AACpD,uDAAuD;AAEvD,OAAO,EAAE,SAAS,EAAE,MAAM,yCAAyC,CAAC;AACpE,OAAO,EAAE,oBAAoB,EAAE,MAAM,2CAA2C,CAAC;AAEjF,OAAO,EAAE,WAAW,EAAE,gBAAgB,EAAE,kBAAkB,EAAE,mBAAmB,EAAE,MAAM,aAAa,CAAC;AACrG,OAAO,EAAE,cAAc,EAAE,kBAAkB,EAAE,MAAM,YAAY,CAAC;AAEhE,MAAM,MAAM,GAAG,IAAI,SAAS,CAAC;IAC3B,IAAI,EAAE,iBAAiB;IACvB,OAAO,EAAE,OAAO;CACjB,CAAC,CAAC;AAEH,SAAS,UAAU,CAAC,KAAc;IAChC,MAAM,IAAI,GAAG,OAAO,KAAK,KAAK,QAAQ,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,IAAI,CAAC,SAAS,CAAC,KAAK,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC;IAChF,OAAO,EAAE,OAAO,EAAE,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,CAAC,EAAE,CAAC;AAC/C,CAAC;AAED,SAAS,WAAW,CAAC,OAAe;IAClC,OAAO,EAAE,OAAO,EAAE,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,UAAU,OAAO,EAAE,EAAE,CAAC,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC;AACnF,CAAC;AAED,MAAM,CAAC,YAAY,CACjB,iBAAiB,EACjB;IACE,KAAK,EAAE,yBAAyB;IAChC,WAAW,EACT,oHAAoH;QACpH,qGAAqG;QACrG,4GAA4G;QAC5G,2GAA2G;QAC3G,4BAA4B;IAC9B,WAAW,EAAE,mBAAmB,CAAC,KAAK;CACvC,EACD,KAAK,EAAE,IAAI,EAAE,EAAE;IACb,MAAM,MAAM,GAAG,MAAM,cAAc,CAAC,IAAI,CAAC,CAAC;IAC1C,IAAI,CAAC,MAAM,CAAC,EAAE;QAAE,OAAO,WAAW,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC;IAClD,OAAO,UAAU,CAAC,EAAE,EAAE,EAAE,IAAI,EAAE,OAAO,EAAE,MAAM,CAAC,OAAO,EAAE,CAAC,CAAC;AAC3D,CAAC,CACF,CAAC;AAEF,MAAM,CAAC,YAAY,CACjB,sBAAsB,EACtB;IACE,KAAK,EAAE,iCAAiC;IACxC,WAAW,EACT,8GAA8G;QAC9G,gHAAgH;QAChH,4GAA4G;QAC5G,mBAAmB;IACrB,WAAW,EAAE;QACX,aAAa,EAAE,kBAAkB,CAAC,KAAK,CAAC,aAAa;KACtD;CACF,EACD,KAAK,EAAE,EAAE,aAAa,EAAE,EAAE,EAAE;IAC1B,OAAO,UAAU,CAAC,MAAM,kBAAkB,CAAC,aAAa,CAAC,CAAC,CAAC;AAC7D,CAAC,CACF,CAAC;AAEF,6EAA6E;AAC7E,gEAAgE;AAChE,OAAO,EAAE,WAAW,EAAE,gBAAgB,EAAE,CAAC;AAEzC,KAAK,UAAU,IAAI;IACjB,MAAM,SAAS,GAAG,IAAI,oBAAoB,EAAE,CAAC;IAC7C,MAAM,MAAM,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;AAClC,CAAC;AAED,IAAI,EAAE,CAAC,KAAK,CAAC,CAAC,CAAC,EAAE,EAAE;IACjB,OAAO,CAAC,KAAK,CAAC,6CAA6C,EAAE,CAAC,CAAC,CAAC;IAChE,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;AAClB,CAAC,CAAC,CAAC"}
+{"version":3,"file":"index.js","sourceRoot":"","sources":["../src/index.ts"],"names":[],"mappings":";AACA,yEAAyE;AACzE,2EAA2E;AAC3E,oDAAoD;AACpD,uDAAuD;AAEvD,OAAO,EAAE,SAAS,EAAE,MAAM,yCAAyC,CAAC;AACpE,OAAO,EAAE,oBAAoB,EAAE,MAAM,2CAA2C,CAAC;AAEjF,OAAO,EAAE,WAAW,EAAE,gBAAgB,EAAE,kBAAkB,EAAE,mBAAmB,EAAE,MAAM,aAAa,CAAC;AACrG,OAAO,EAAE,cAAc,EAAE,kBAAkB,EAAE,MAAM,YAAY,CAAC;AAChE,OAAO,EAAE,oBAAoB,EAAE,+BAA+B,EAAE,MAAM,cAAc,CAAC;AAErF,MAAM,MAAM,GAAG,IAAI,SAAS,CAAC;IAC3B,IAAI,EAAE,iBAAiB;IACvB,OAAO,EAAE,OAAO;CACjB,CAAC,CAAC;AAEH,SAAS,UAAU,CAAC,KAAc;IAChC,MAAM,IAAI,GAAG,OAAO,KAAK,KAAK,QAAQ,CAAC,CAAC,CAAC,KAAK,CAAC,CAAC,CAAC,IAAI,CAAC,SAAS,CAAC,KAAK,EAAE,IAAI,EAAE,CAAC,CAAC,CAAC;IAChF,OAAO,EAAE,OAAO,EAAE,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,CAAC,EAAE,CAAC;AAC/C,CAAC;AAED,SAAS,WAAW,CAAC,OAAe;IAClC,OAAO,EAAE,OAAO,EAAE,CAAC,EAAE,IAAI,EAAE,MAAM,EAAE,IAAI,EAAE,UAAU,OAAO,EAAE,EAAE,CAAC,EAAE,OAAO,EAAE,IAAI,EAAE,CAAC;AACnF,CAAC;AAED,MAAM,CAAC,YAAY,CACjB,iBAAiB,EACjB;IACE,KAAK,EAAE,yBAAyB;IAChC,WAAW,EACT,oHAAoH;QACpH,qGAAqG;QACrG,4GAA4G;QAC5G,2GAA2G;QAC3G,4BAA4B;IAC9B,WAAW,EAAE,mBAAmB,CAAC,KAAK;CACvC,EACD,KAAK,EAAE,IAAI,EAAE,EAAE;IACb,MAAM,MAAM,GAAG,MAAM,cAAc,CAAC,IAAI,CAAC,CAAC;IAC1C,IAAI,CAAC,MAAM,CAAC,EAAE;QAAE,OAAO,WAAW,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC;IAClD,OAAO,UAAU,CAAC,EAAE,EAAE,EAAE,IAAI,EAAE,OAAO,EAAE,MAAM,CAAC,OAAO,EAAE,CAAC,CAAC;AAC3D,CAAC,CACF,CAAC;AAEF,MAAM,CAAC,YAAY,CACjB,sBAAsB,EACtB;IACE,KAAK,EAAE,iCAAiC;IACxC,WAAW,EACT,+GAA+G;QAC/G,+GAA+G;QAC/G,+GAA+G;QAC/G,4GAA4G;QAC5G,8GAA8G;QAC9G,4GAA4G;QAC5G,6GAA6G;QAC7G,uDAAuD;QACvD,+GAA+G;QAC/G,6CAA6C;IAC/C,WAAW,EAAE;QACX,aAAa,EAAE,kBAAkB,CAAC,KAAK,CAAC,aAAa;KACtD;CACF,EACD,KAAK,EAAE,EAAE,aAAa,EAAE,EAAE,EAAE;IAC1B,oEAAoE;IACpE,sEAAsE;IACtE,sEAAsE;IACtE,yEAAyE;IACzE,kEAAkE;IAClE,sEAAsE;IACtE,kEAAkE;IAClE,qEAAqE;IACrE,uEAAuE;IACvE,qEAAqE;IACrE,IAAI,CAAC;QACH,OAAO,UAAU,CAAC,MAAM,kBAAkB,CAAC,aAAa,CAAC,CAAC,CAAC;IAC7D,CAAC;IAAC,OAAO,CAAC,EAAE,CAAC;QACX,OAAO,WAAW,CAAE,CAAW,CAAC,OAAO,CAAC,CAAC;IAC3C,CAAC;AACH,CAAC,CACF,CAAC;AAEF,MAAM,CAAC,YAAY,CACjB,wBAAwB,EACxB;IACE,KAAK,EAAE,0DAA0D;IACjE,WAAW,EACT,2GAA2G;QAC3G,+GAA+G;QAC/G,gHAAgH;QAChH,0GAA0G;QAC1G,gHAAgH;QAChH,+GAA+G;QAC/G,0GAA0G;IAC5G,WAAW,EAAE,+BAA+B,CAAC,KAAK;CACnD,EACD,KAAK,EAAE,IAAI,EAAE,EAAE;IACb,MAAM,MAAM,GAAG,MAAM,oBAAoB,CAAC,IAAI,CAAC,CAAC;IAChD,IAAI,CAAC,MAAM,CAAC,EAAE;QAAE,OAAO,WAAW,CAAC,MAAM,CAAC,MAAM,CAAC,CAAC;IAClD,OAAO,UAAU,CAAC,MAAM,CAAC,CAAC;AAC5B,CAAC,CACF,CAAC;AAEF,6EAA6E;AAC7E,gEAAgE;AAChE,OAAO,EAAE,WAAW,EAAE,gBAAgB,EAAE,CAAC;AAEzC,KAAK,UAAU,IAAI;IACjB,MAAM,SAAS,GAAG,IAAI,oBAAoB,EAAE,CAAC;IAC7C,MAAM,MAAM,CAAC,OAAO,CAAC,SAAS,CAAC,CAAC;AAClC,CAAC;AAED,IAAI,EAAE,CAAC,KAAK,CAAC,CAAC,CAAC,EAAE,EAAE;IACjB,OAAO,CAAC,KAAK,CAAC,6CAA6C,EAAE,CAAC,CAAC,CAAC;IAChE,OAAO,CAAC,IAAI,CAAC,CAAC,CAAC,CAAC;AAClB,CAAC,CAAC,CAAC"}

package/dist/ledger.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"ledger.d.ts","sourceRoot":"","sources":["../src/ledger.ts"],"names":[],"mappings":"AAYA,OAAO,EAAuB,KAAK,aAAa,EAAE,MAAM,aAAa,CAAC;AAoftE;;;GAGG;AACH,wBAAsB,WAAW,CAAC,KAAK,EAAE,aAAa,GAAG,OAAO,CAAC,aAAa,CAAC,CA0D9E;AAED,4DAA4D;AAC5D,wBAAsB,eAAe,CAAC,aAAa,EAAE,MAAM,GAAG,OAAO,CAAC,aAAa,EAAE,CAAC,CAQrF;AAED,mFAAmF;AACnF,wBAAsB,SAAS,IAAI,OAAO,CAAC,aAAa,EAAE,CAAC,CAG1D"}
+{"version":3,"file":"ledger.d.ts","sourceRoot":"","sources":["../src/ledger.ts"],"names":[],"mappings":"AAYA,OAAO,EAAuB,KAAK,aAAa,EAAE,MAAM,aAAa,CAAC;AA0hBtE;;;GAGG;AACH,wBAAsB,WAAW,CAAC,KAAK,EAAE,aAAa,GAAG,OAAO,CAAC,aAAa,CAAC,CA0D9E;AAED,4DAA4D;AAC5D,wBAAsB,eAAe,CAAC,aAAa,EAAE,MAAM,GAAG,OAAO,CAAC,aAAa,EAAE,CAAC,CAQrF;AAED,mFAAmF;AACnF,wBAAsB,SAAS,IAAI,OAAO,CAAC,aAAa,EAAE,CAAC,CAG1D"}

package/dist/ledger.js

@@ -10,6 +10,7 @@ import { readFileSync, appendFileSync, openSync, closeSync, unlinkSync, statSync
 import { join } from "node:path";
 import { dataDir, ensureDataDir } from "./config.js";
 import { DeliveryClaimSchema } from "./schema.js";
+import { verifyClaim } from "./signing.js";
 function claimsFile() {
     return join(dataDir(), "claims.jsonl");
 }
@@ -100,7 +101,18 @@ async function acquireLock(path) {
                 continue;
             }
             if (Date.now() > deadline) {
-                throw new Error(`ledger_lock_timeout: could not acquire lock at ${path}`);
+                // EIGHTH FIX (2026-09-06, found by the same adversarial audit as the
+                // SEVENTH FIX above): this used to interpolate the full resolved
+                // `path` (== CAPACITY_ATTEST_DATA_DIR + "/claims.jsonl.lock") into the
+                // thrown message. That propagates unchanged through appendClaim() ->
+                // recordDelivery()'s `{ok:false, reason: e.message}` -> the MCP
+                // tool's error text (index.ts's errorResult) — a caller who simply
+                // triggers ordinary lock contention (trivial: a few concurrent
+                // record_delivery calls) gets the server's absolute filesystem path
+                // handed back, which on a real deployment can reveal the install
+                // location and, on Windows, the operating user's name. No caller
+                // needs that path to understand or retry the failure.
+                throw new Error("ledger_lock_timeout: could not acquire the ledger lock in time");
             }
             // Non-blocking backoff: await a real timer instead of spinning, so the
             // event loop stays free to process other work (timers, other
@@ -387,8 +399,34 @@ async function resyncFromDisk(file) {
         const line = lines[i];
         try {
             const claim = DeliveryClaimSchema.parse(JSON.parse(line));
-            decorated.push({ claim, ts: timestampMs(claim) });
-            claimIdSet.add(claim.claimId.toLowerCase());
+            // SEVENTH FIX (2026-09-06, found by an adversarial audit): until this
+            // fix, a line only had to match DeliveryClaimSchema's SHAPE (claimId a
+            // 0x+64-hex string, signature a 0x+130-hex string — see schema.ts's
+            // claimIdField/signatureField, both plain regexes) to be accepted into
+            // the cache and served back out through get_delivery_history. Neither
+            // claimId (does it really hash the claim's own content?) nor signature
+            // (does it really recover to buyerAddress?) was ever recomputed on
+            // this READ path — only appendClaim()'s caller (recordDelivery() in
+            // tools.ts) verifies before writing. That is airtight for claims that
+            // only ever arrive via record_delivery, but this ledger's own header
+            // comment documents a deployment shape this package is explicitly
+            // built for — multiple OS processes sharing one
+            // CAPACITY_ATTEST_DATA_DIR — where nothing stops a second writer (or a
+            // corrupted/hand-edited file) from appending a well-shaped but entirely
+            // fabricated line directly to claims.jsonl, bypassing recordDelivery()
+            // and its verifyClaim() gate completely. Before this fix such a line
+            // would resync into the cache and get returned as if genuine,
+            // contradicting both get_delivery_history's own tool description
+            // ("every SIGNATURE-VERIFIED delivery claim") and DECISIONS.md D-006's
+            // reasoning, which assumed authenticity of every shown claim was never
+            // in question — it was, on this exact path. Fix: reuse the same
+            // verifyClaim() the write path already trusts, and treat a claim that
+            // fails it exactly like a corrupt/truncated line below — silently
+            // excluded, ledger stays readable, no new error surface.
+            if (verifyClaim(claim).ok) {
+                decorated.push({ claim, ts: timestampMs(claim) });
+                claimIdSet.add(claim.claimId.toLowerCase());
+            }
         }
         catch {
             // A corrupt/partial line (e.g. a truncated write) must not take down