A sovereign social network
powered by Bitcoin

@J1Pelaez Thank you. That's exactly the answer I was after.

So the share travels as data. It gets paid wherever a marketplace decides to use it. Ordi wallet adds the outputs. Where a marketplace doesn't, no royalty is paid.

Here's where my version ends, for comparison. On a throwaway piece, a wallet transfer on mainnet paid 5,000 and 3,000 sats to two fixed payees, because the script requires both outputs. A transfer that skips them is refused. (That refusal I've tested in a harness, not on chain.)

What that costs:

• It's a fixed amount, not a percentage. A script can't see a market price. A percentage would be of a price the parties declare, and they can declare it low and settle the rest off-chain.
• It charges on every transfer, gifts included. A script can't tell a sale from a gift.
• The payees are baked in permanently.
• Only software that knows the script can move the piece. Any ordinals wallet can move yours.

So yours is portable and optional. Mine is enforced and narrow. They answer different questions, and I think both are worth having.

@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.