v0.4.0
This release answers, in code, the question goun7 raised on x402-foundation/x402#3379: can a dishonest host hide delivery claims?
The honest framing first. Fully preventing omission from a single answer is not achievable by anyone, and this release does not pretend otherwise. Even Certificate Transparency, the largest system built for this, saw its split-view gossip layer declared dead in 2018 and leans in practice on a handful of funded monitors, not on a proof inside the log. What is achievable for a small package is to make an omission leave a trace that a reader can find without trusting the host.
What is new
priorClaimId: a new optional, signed field. Each buyer links their successive claims about the same seller into a chain, where each claim carries the claimId of that buyer's previous claim about that seller. Because the link sits inside the signed content, a host cannot strip or alter it without breaking the signature, and the read path re-verifies every claim. Same optional and never-defaulted discipline as the measured and externalRefs fields, so no claim recorded before 0.4.0 changes its claimId. A buyer's first claim about a seller simply omits the field.
analyzeCompleteness, surfaced as a completeness field on get_delivery_history. It reads the per-buyer chains in a result and flags, in possibleOmissions, any shown claim whose priorClaimId points to a claim that is not in the result. That is the concrete signal that a host may be hiding a middle claim.
The one thing to understand before you rely on it
The completeness field is computed by the same server that returns the claims. If you do not run that server yourself, do not trust the field: a dishonest host can put a rosy report in it. The trust lives in the signed priorClaimId links inside the claims, which a host cannot forge, not in the derived report. A suspicious reader recomputes analyzeCompleteness locally over the returned, independently verified claims. This is stated in the tool description, the README (with a recompute recipe), the source, and DECISIONS.md D-006.
Prove it yourself
A public, reproducible fixture ships with the package: docs/COMPLETENESS-FIXTURE.md, runnable with npm run fixture. It builds one buyer's chained claims about one seller, simulates a host that hides the negative middle claim, and checks nine controls: five GREEN properties that must hold and four RED tamper negatives that must be rejected. The same controls run as a test on every push. It is modeled on the transparency discipline goun7 published for Tamga Protocol: deterministic from a fixed test key, every value labeled by source, and tamper cases you can run rather than take on faith.
Honest limits
This catches a hidden claim in the middle of a buyer's chain. It does not catch a hidden most-recent claim, nor a hidden entire buyer, and a dangling link can also just mean the prior claim was recorded on a different installation. For assurance beyond middle-claim detection, cross-check against the buyer's own retained copy of their claims and the on-chain payment the settlementRef points to. The separate question of finding claims across independent installations (D-005) is not solved here and stays open, pointed at existing infrastructure like EAS and ERC-8004, waiting for a real multi-installation case.
494 tests, typecheck and build green.