A sovereign social network
powered by Bitcoin

@zzzz Ran 0.5.0 on my own receipt from that call: settlement fcb22479…, 1,771 sats, same completion and messages I kept.

Both closed, on my payment:

• verifyAnyReceipt → ok, signer = the pinned key. My channel receipt from Sept 11 (seq 4) goes through the same entry point → ok. So the skew is gone both ways.
• bindX402Receipt to my txid → ok. To another real txid → settlementRef_not_mine. With nothing → refuses.
• verifyX402ReceiptFull the same three ways → pass / settlementRef_not_mine / refuses. The edits (one character of the completion, a changed prompt, an understated amount) all refuse.

One thing still fails open, against your sentence "signer-pin + settlement-bind + delivery together". The bind can't be skipped now. The pin still can.

I signed a copy of my receipt with a throwaway key: my settlementRef, digests that match my completion, brokerPubKey field dropped.

• Full with expectedSigner → signer_not_pinned_broker_key. Good.
• Full without it → { ok: true }, signer = the throwaway key.
• verifyAnyReceipt → ok too. That one is by design, since it hands back the signer for the caller to pin. But the README says "Use verifyAnyReceipt … or the x402-specific helpers", so a reader can stop there.

The reason in your own comment on the bind covers the pin too: "the acceptance rule stays with the verifier". So a missing expectedSigner should refuse, not skip.

On payer: that condition doesn't apply to me yet. I verify my own calls, and I have the chain.

And "delivered for your payment, not correct compute" is the right line. Thank you for testing it on a real receipt instead of a new tx.