agent-receipt-verify 0.0.0-stage → 0.2.1

package/CONFORMANCE.md

@@ -0,0 +1,110 @@
+# x402 receipt conformance, edition 1
+
+Dated 2026-10-17. This file defines a unit of measurement, not a score. If you
+publish a different number for the same population, the useful conversation is
+about which level you laid differently, and that is what this file exists to make
+possible.
+
+## Why a definition comes before a number
+
+Measurements of the x402 population are already in circulation: counts of live
+resources, and the observation that none of a sampled set declared the
+offer-receipt extension. None of them says what was counted. Without a stated
+unit, percentages are not comparable, and two honest people measuring the same
+thing will disagree for reasons neither can see.
+
+Two specific ways that goes wrong, both of which we walked into before writing
+this down:
+
+- **Counting endpoints instead of operators.** One operator with several hundred
+  paths then outweighs several hundred operators with one path each. Our own first
+  pass produced a headline figure that was almost entirely one party's paths. The
+  unit below is the operator, by host.
+- **Treating "works" as one thing.** Returning 402 at all, declaring the receipt
+  extension, signing the offer, and actually emitting a linkable receipt are four
+  different claims with four different costs. A single pass/fail hides which one
+  an implementer still owes.
+
+## The unit
+
+**One operator**, identified by the host of its resource URL. Where an operator
+exposes many paths, one is measured and the operator counts once.
+
+## The ladder
+
+Each level requires every level below it. A level is recorded as reached, not
+reached, or **not measured**, and the third is not a failure: levels 3 to 5 cannot
+be observed without paying, so an unpaid measurement reports them as unmeasured
+rather than as absent.
+
+| Level | Claim | Requirement | Observable without paying |
+|---|---|---|---|
+| 0 | asks for payment the way x402 says | HTTP 402 carrying `accepts[]` with `scheme`, `network`, `payTo` and an amount, in the body or in the `Payment-Required` header | yes |
+| 1 | declares the offer-receipt extension | the 402 carries an `offer-receipt` entry in `extensions` | yes |
+| 2 | signs its offer, and the signature verifies | `extensions["offer-receipt"].info.offers[0]` is a signed artifact whose signature verifies: an `eip712` artifact recovering to an address, or a `jws` with an EdDSA signature over the offer payload whose key resolves from its `kid` | yes |
+| 3 | emits a receipt that verifies | after payment, the settlement response carries a receipt whose signature recovers to the same signer | no |
+| 4 | receipt is version 2, and the salt arrives where §5.6.3 says | `payload.version` is 2 with both commitment fields, and the salt is at `extensions["offer-receipt"].info.authorizationSalt` | no |
+| 5 | the commitment opens against the chain to exactly one settlement | §5.6.4 run against live chain state resolves to exactly one `AuthorizationUsed` nonce | no |
+
+Levels 4 and 5 cite sections 5.6 and later of the offer-receipt extension. Those do
+not exist on `main`: they live only in pull request 3827, which is open, pinned here
+to commit `0e492d6`. Both levels are marked as citing a proposal in
+[profiles/x402-deployed-ladder-v1.json](profiles/x402-deployed-ladder-v1.json), and
+the tool repeats that in its output.
+
+Level 0 deliberately fails a 402 that carries no requirements. A payment demand
+that does not say what to pay cannot be acted on, and treating it as conforming
+would make the level meaningless.
+
+Level 2 requires the signature to verify, not merely to be present. A declaration
+with an unverifiable signature is a claim about a claim.
+
+Level 2 accepts either signature form. A signature that cannot be checked because
+this checker does not implement its algorithm is recorded as not measured, never as
+not reached: not supported and not valid are different answers, and only one of them
+is about the operator.
+
+## How to reproduce it
+
+```sh
+node src/x402-conformance-check.mjs <url> [url ...]
+```
+
+Levels 0 to 2 are measured. Levels 3 to 5 are reported as not measured, with the
+reason. Every verdict comes with the evidence it rests on, so a different result
+is traceable to a different observation rather than to a different opinion.
+
+Conduct, because this touches other people's endpoints: one request per endpoint,
+the same request an ordinary buyer makes, never a payment, never a repeat to force
+an outcome, a user agent that says who is calling, and a pause between endpoints.
+
+## What this does not measure, on purpose
+
+- **Whether an operator is honest.** These are checks on the form of a response.
+- **Whether the paid resource delivered anything.** That is the other half of a
+  delivery record and is out of scope here.
+- **Whether a receipt is counted by any consumer.** §5.6.5 says a consumer
+  counting settlements may count only opened commitments; whether a given consumer
+  does so is its own business and not observable from the seller side.
+- **Levels 3 to 5 without a payment.** An endpoint can be at level 2 here and at
+  level 5 in reality. The measurement says what was observed, never what was
+  assumed.
+
+## Changing the ladder changes the edition
+
+The levels live as data in `src/x402-conformance-treden.mjs`. If a level is added,
+removed or reworded, that is a new edition with a new date, and the old one stays
+readable. A measurement whose unit silently moved is worse than no measurement,
+because it looks comparable and is not.
+
+### 2026-10-17, level 2 widened
+
+Level 2 required an `eip712` artifact. Measuring live endpoints found an operator
+that does sign its offer, in `jws` with an EdDSA signature and a `did:web` key, and
+this ladder scored that as a failure. That was a defect in the unit, not in the
+operator: a ladder that does not know a valid form measures that party wrongly and
+would have made a published number false. Level 2 now asks for a signed offer whose
+signature verifies, in either form, and names the forms it cannot check.
+
+The results that led to this are in `editions/2026-10-17/`, including the live
+measurement that produced the wrong score before the fix.

package/LICENSE

@@ -0,0 +1,201 @@
+Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS
+
+   APPENDIX: How to apply the Apache License to your work.
+
+      To apply the Apache License to your work, attach the following
+      boilerplate notice, with the fields enclosed by brackets "[]"
+      replaced with your own identifying information. (Don't include
+      the brackets!)  The text should be enclosed in the appropriate
+      comment syntax for the file format. We also recommend that a
+      file or class name and description of purpose be included on the
+      same "printed page" as the copyright notice for easier
+      identification within third-party archives.
+
+   Copyright [yyyy] [name of copyright owner]
+
+   Licensed under the Apache License, Version 2.0 (the "License");
+   you may not use this file except in compliance with the License.
+   You may obtain a copy of the License at
+
+       http://www.apache.org/licenses/LICENSE-2.0
+
+   Unless required by applicable law or agreed to in writing, software
+   distributed under the License is distributed on an "AS IS" BASIS,
+   WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+   See the License for the specific language governing permissions and
+   limitations under the License.

package/NOTICE

@@ -0,0 +1,39 @@
+agent-receipt-verify
+Copyright 2026 Abdellah Ouadoudi (github.com/holistis)
+
+Licensed under the Apache License, Version 2.0. See LICENSE.
+
+This repository redistributes test material published by the protocols it verifies,
+so that anyone can reproduce the results without trusting this repository:
+
+- vectors/inam/vectors.json and vectors/inam/BRON-README.md
+  from inamprotocol/inam-protocol, interop/countersigned, at commit
+  d5e5f4555e7fd2ca8dedfa28bbfcddb0e6eb991d. Apache-2.0. Unmodified.
+  Those files contain test keys and made-up addresses only, as their own README states.
+
+- vectors/inam/canonical-vectors.json
+  from inamprotocol/inam-protocol, interop/canonical/vectors.json, at commit
+  d4a2940f936af5353a9a9bf89db1097ca91bdd3c. Apache-2.0. Unmodified.
+  Key-order and escaping cases with characters beyond U+FFFF and lone surrogates.
+  Their maintainer published these after the ones above and pointed us at them, since
+  they are where two implementations written from the same text most easily diverge:
+  they exposed a real bug in their own Python canonicalizer, which sorted keys by code
+  point instead of by UTF-16 code unit.
+
+- The worked example in src/x402-offer-receipt.mjs (asset, authorizer, nonce, salt and
+  the expected commitment) is quoted from x402-foundation/x402,
+  specs/extensions/extension-offer-and-receipt.md section 5.6.2, on the branch
+  receipt-authorization-commitment at commit 0e492d6. Apache-2.0.
+
+Neither project has reviewed or endorsed this repository. The verifiers here were
+written against the published specifications, not against those projects' source code,
+which is the point: two implementations that have not seen each other agreeing on the
+same vectors is evidence, and one implementation agreeing with itself is not.
+
+- vectors/kanon/*.json
+  from iamonuwa/kanon, vectors/x402/exact/evm/eip3009/, at commit 0d5a7461e996,
+  Apache-2.0, redistributed unmodified. Ten EIP-3009 payment-authorization vectors,
+  each carrying its own expected verdict and reason code. src/eip3009-autorisatie.mjs
+  is an independent implementation written against those vectors and against EIP-3009
+  and EIP-712, never against that project's source. That project has not reviewed or
+  endorsed this repository.

package/README.md

@@ -1,3 +1,257 @@
-# Temporary Holding Version
+# agent-receipt-verify
 
-This version is a temporary placeholder for this package. An operational version to replace this has been submitted for review and is awaiting a staged release.
+Independent verification of payment- and outcome-proof receipts used by AI agents.
+
+An agent economy has two kinds of receipt. One says **who was allowed to act**
+(delegation: UCAN, Authproof, Agent Passport). The other says **what was paid for
+and whether the output matches** (settlement and outcome: x402 offer-receipt, INAM
+countersigned receipts, and the proofs ERC-8004 consumers count).
+
+`receipt-commons/receipt-interop` covers the first kind. This covers the second.
+
+## Use it from an agent: the MCP server
+
+Both checks are also a Model Context Protocol server, so an agent can run them itself
+instead of a person running a command. It speaks MCP over stdio, protocol version
+2025-11-25. The framing, `initialize`, `tools/list` and `tools/call` are implemented
+directly in `src/mcp-server.mjs`, with no MCP SDK and no required dependency at all.
+
+Two tools, for the two moments where an agent actually needs an answer.
+
+`check_x402_endpoint`, before paying. Sends one request and reports which levels of the
+ladder in [CONFORMANCE.md](CONFORMANCE.md) the endpoint reaches. Levels that need a real
+settlement come back as not measured, never as failed.
+
+`link_receipt_to_settlement`, after paying. Takes the receipt, the authorization salt and
+the asset that was paid, resolves the salted commitment against live chain state, and
+answers linked, not linked, or could not check. Those are three different answers and it
+never collapses them into two.
+
+Add it to a client:
+
+```json
+{
+  "mcpServers": {
+    "agent-receipt-verify": {
+      "command": "npx",
+      "args": ["-y", "github:holistis/agent-receipt-verify", "mcp"]
+    }
+  }
+}
+```
+
+No account, no API key, nothing published to npm. If you would rather not run Node from a
+git ref, there is a Dockerfile:
+
+```sh
+docker build -t agent-receipt-verify . && docker run -i --rm agent-receipt-verify
+```
+
+The server opens no port and writes nothing to disk. Anything that is not a protocol
+frame goes to stderr, because stdout belongs to the client. `npm test` drives the server
+over real frames in 21 cases, including an unknown tool name, a notification that must
+not get a reply, and a network it does not know, which has to answer could not check
+rather than not linked.
+
+`ethers` is an optional dependency, used for one signature check inside
+`check_x402_endpoint`. Without it that single check reports not measured instead of
+passing, and everything else works unchanged.
+
+## Why independent implementations matter
+
+A receipt signed by a seller is a statement by an interested party. It only becomes
+evidence when someone who was not the signer can recompute it and reach the same
+conclusion. So every verifier here is written against the published specification,
+never against the reference implementation's source, and is tested against the
+vector files published by the protocol's own authors.
+
+If two implementations that have not seen each other's code agree on the same
+vectors, that is interop. One implementation agreeing with itself proves nothing.
+
+## Status
+
+| Format | Vectors by | Cases | Our verdicts match |
+|---|---|---|---|
+| INAM countersigned | inamprotocol/inam-protocol @ d5e5f45 | 4 | 4 / 4, identical failed-check sets |
+| x402 offer-receipt (commitment §5.6, proposed in PR 3827) | x402-foundation/x402 @ 0e492d6, not on main | 1 published example plus 6 own edge cases | yes, byte-identical |
+| x402 settlement link (§5.6.4, same proposal) | own tests plus three live settlements | 22 offline, 3 live | yes, each resolves to its own settlement |
+
+```sh
+npm test      # all of the above, no network, no keys
+```
+
+Node built-ins only, apart from keccak256. Only the settlement link below touches
+the network, and then only a public read-only RPC.
+
+Confirmed from the other side, which matters more than the table: the author of
+the x402 specification ran their own implementation, which shares no code with
+this one, against all three live receipts below and reached the same three
+settlements, starting from the receipt, the salt and the asset as §5.6.4
+requires. Their result and ours are in
+[x402#3827](https://github.com/x402-foundation/x402/pull/3827#issuecomment-6230063003).
+
+## Linking a receipt to its settlement
+
+A receipt with an empty `transaction` field can be matched to a payment only by
+payer, payee, amount and time. Two payments with the same terms in the same block
+cannot be told apart at all. Section 5.6 of the x402 offer-receipt extension fixes
+that with a salted commitment to the ERC-3009 nonce: whoever holds the salt can
+recompute the link to exactly one settlement, and everyone else learns nothing.
+
+Where section 5.6 lives, because it is not where a reader would assume. Sections 5.6
+through 5.6.5 do not exist in the version of the offer-receipt extension on `main`.
+They exist only in pull request 3827, which is open. Everything here that cites 5.6 is
+therefore measured against a proposal, pinned to commit `0e492d6` on that pull request,
+which is four commits ahead of `main` and fetchable by anyone. The numbering can still
+move before it merges. Levels 4 and 5 of the ladder carry this in the profile, and the
+tool says so in its own output, so a result is never quietly presented as measured
+against published text.
+
+Section 5.6.5 is the part that makes this matter in practice. A commitment that
+nobody has opened is still only a statement by the signer: they can issue two
+receipts with different salts for one settlement, or a commitment that opens to
+nothing at all. So a consumer that counts settlements, for a deduplicated or
+Sybil-resistant count, may count only the commitments that someone has opened.
+
+Here are three payments with identical terms: same payer, same payee, same
+amount, same resource, minutes apart on Base Sepolia. Without a commitment those
+receipts could not be told apart. Each one still resolves to its own settlement:
+
+```sh
+npm run link-example
+```
+
+```
+commitment  : 0x5c35a61a09a566a9c284fad18a70ac2ddfff34d01d2a3ce776ce94e8d5b38ff8
+candidates  : 2 nonce(s) consumed by this payer in that window
+LINKED      : yes, to exactly one settlement
+  tx        : 0xed87b09bfb20a8c8b69908e163fcea6432d193d389640c0465afcb5561dfeb30
+
+commitment  : 0xfecee93e1aec7d6858a218bf324f23e2a4eed07925d8d4542b9662c5026e3d22
+candidates  : 3 nonce(s) consumed by this payer in that window
+LINKED      : yes, to exactly one settlement
+  tx        : 0x2898d0ceb97ddf60af98e19c94fc0adddbdf1e64f9032e62454085e37acfe36b
+
+commitment  : 0xea8dd34b8beac90f021a4e8d893a689c25249f86947770c8e6647c1cde206008
+candidates  : 2 nonce(s) consumed by this payer in that window
+LINKED      : yes, to exactly one settlement
+  tx        : 0x2a9e95d63a5af8210767baa69143b364dad51caffc29a152c77e03bc508d7199
+```
+
+Each window is centred on its own receipt's `issuedAt`, which is why the
+candidate counts differ: the middle receipt's window covers all three payments
+and it still picks out exactly one. That is the ambiguity section 5.6.1
+describes, resolved against live state.
+
+Two things in that output move and the verdict does not. The candidate count
+rises as that payer consumes more nonces, and the upper block number is capped
+at the current chain head until the head passes it. The transaction each receipt
+resolves to is fixed.
+
+The three files in `examples/` hold exactly what section 5.6.4 says a later verifier
+has: the receipt, its salt, and the asset that was paid. The nonces and the
+transaction hashes are deliberately kept out of them. Those come out of
+`AuthorizationUsed(address,bytes32)` logs on the token contract, and the tool
+accepts an answer only when exactly one candidate opens the commitment. Zero
+matches and more than one match are both reported as not linked, never as a best guess.
+
+Point it at your own receipt with `--receipt=<file>`, and add `--salt=` and
+`--asset=` if they are not stored alongside it. All three are required: a receipt
+and a salt without the asset cannot link, which is section 5.6.4's own warning.
+
+Those payments went to a live x402 seller that issues version 2 receipts, and it
+publishes these cases itself, with the settlement each one should resolve to, at
+`https://api.tokenizen.nl/api/x402/conformance`. Point your own implementation at
+that and compare, or call its paid route and link a receipt you obtained yourself.
+A fixture cannot tell you whether the salt arrives at the location §5.6.3 names,
+inside a real settlement envelope; only a paid call can.
+Buyer and seller are both us, so this shows the chain closes end to end. It does
+not show that anyone else is using it.
+
+## Honest limits
+
+The format checks test the **form** of a receipt: signatures, content addressing,
+and whether the hashes match the bytes a counterparty observed. They do not tell
+you whether an operator is honest, or whether a registry holds a receipt as
+finalized.
+
+The settlement link does read live chain state, and these are its real edges:
+
+- It searches a window around the receipt's `issuedAt`, not the whole chain,
+  because the public Base Sepolia RPC caps `eth_getLogs` at 200 blocks per call
+  (measured, not read in documentation). The window it searched is always printed,
+  so "not found" reads as "not in this window" and never as "does not exist".
+  Widen it with `--window=`.
+
+  A receipt may be signed before its settlement lands, since the seller holds the
+  nonce first, so the window is centred rather than backward-looking. What that
+  costs, measured against a live receipt, with the reach derived from the measured
+  block time:
+
+  | `--window` | reach around `issuedAt` | RPC calls | wall clock |
+  |---|---|---|---|
+  | 50 | 1.7 min | 1 | 0.7s |
+  | 200 | 6.7 min | 3 | 0.8s |
+  | 400 (default) | 13 min | 5 | 1.3s |
+  | 1000 | 33 min | 11 | 1.7s |
+  | 2000 | 67 min | 21 | 2.9s |
+
+  Calls grow linearly with the window and not with the payer's history, which is
+  the trade the window buys: an hour of tolerance for 21 requests. Searching a
+  payer's full set of consumed nonces instead needs no `issuedAt` at all and
+  cannot miss on skew, at a cost that grows with how much that payer has ever
+  spent.
+- A refused RPC call raises an error instead of returning an empty result. A search
+  that could not run must never be reported as a search that found nothing.
+- Only `eip3009` is implemented, because that is the only method the specification
+  currently defines.
+- It confirms that a receipt commits to one settlement. It does not confirm that
+  the amount or the payee were the agreed ones; read the matching transaction for
+  that.
+- Receipt version 2 is defined in a pull request that is still open, so its
+  preimage can still change. The commit it was built against is pinned in the
+  source and in the status table above.
+
+## Provenance and license
+
+Apache-2.0, the same licence both verified projects use. Their published test material is
+redistributed unmodified with attribution; see NOTICE for the exact commits. Neither
+project has reviewed or endorsed this repository.
+
+## Check your own endpoint, in one command
+
+No install, no account, nothing published to npm:
+
+```sh
+npx github:holistis/agent-receipt-verify https://your-endpoint.example/paid
+```
+
+The ladder itself is a versioned file, [profiles/x402-deployed-ladder-v1.json](profiles/x402-deployed-ladder-v1.json),
+which names the clause behind every level, the input each check needs, and what to
+report when a check cannot decide. The tool reads that file rather than carrying the
+rules in code, so a second implementation can measure the same thing without reading
+ours.
+
+It measures levels 0 to 2 of the ladder in [CONFORMANCE.md](CONFORMANCE.md) without
+paying. Levels 3 to 5 need a real settlement and come back as not measured, never as
+failed. What it deliberately does not measure is listed in that same file.
+
+## A badge for an endpoint that was measured
+
+If an edition covered your endpoint, there is a badge for it:
+
+```md
+[![x402 receipt](https://api.tokenizen.nl/api/x402/badge?url=https%3A%2F%2Fyour-endpoint.example%2Fpaid)](https://github.com/holistis/agent-receipt-verify/blob/main/CONFORMANCE.md)
+```
+
+The same data as JSON is at `/api/x402/badge.json?url=...`.
+
+Two things about that badge, because both are deliberate. It never measures live: it
+answers from a dated measurement, so nobody can use that endpoint to probe arbitrary
+hosts, and the number does not change on every hiccup. And the measurement date is
+rendered inside the badge, so a badge that has gone stale is visibly old rather than
+quietly wrong.
+
+An endpoint no edition has covered comes back as `measured: false`, not as level 0.
+Those are different claims: one says we looked and found nothing, the other says we
+never looked.