Transaction-Science/open-standards
Watch
1
0
Fork
You've already forked open-standards
 0
Code Issues Pull requests Projects Releases 15 Packages Wiki Activity Actions

jcp-x402: demonstrate the settlement coupling in the runnable example #25

Merged
dcharlot merged 1 commit from jcp/x402-example-settlement into main 2026-07-18 04:34:26 -04:00
Conversation 0 Commits 1 Files changed 1 +37 -2
dcharlot commented 2026-07-18 04:34:25 -04:00
Owner
Copy link

The example showed ingest, dual-ceiling minting, the money-cap denial, and the currency refusal — but not seal_settlement, the crate's most distinctive contribution. It was tested and undemonstrated.

Adds the settlement step, and runs the check a third party would run: recompute the coupling id from the settlement record and compare it against the receipt's payload_hash.

Two details that make it a real demo rather than a happy path:

  • Measured ≠ estimated. The meter reports 5812 µJ against a 6000 µJ estimate, so the receipt visibly binds what happened, not what was budgeted.
  • It shows the negative. Re-pointing at a different transaction yields a different id — the property that makes the binding worth anything.
settled 0xdeadbeefcafe → sealed ALLOW
  coupling verified: true  (tx + 5812 µJ bound into payload_hash 1b482bc6e25b1f08…)
  re-point to another tx → id matches: false

Example-only; no library change. 7 tests green, clippy clean.

The example showed ingest, dual-ceiling minting, the money-cap denial, and the currency refusal — but not `seal_settlement`, the crate's most distinctive contribution. It was tested and undemonstrated. Adds the settlement step, and runs the check a **third party** would run: recompute the coupling id from the settlement record and compare it against the receipt's `payload_hash`. Two details that make it a real demo rather than a happy path: - **Measured ≠ estimated.** The meter reports 5812 µJ against a 6000 µJ estimate, so the receipt visibly binds *what happened*, not what was budgeted. - **It shows the negative.** Re-pointing at a different transaction yields a different id — the property that makes the binding worth anything. ``` settled 0xdeadbeefcafe → sealed ALLOW coupling verified: true (tx + 5812 µJ bound into payload_hash 1b482bc6e25b1f08…) re-point to another tx → id matches: false ``` Example-only; no library change. 7 tests green, clippy clean. 
The example showed ingest, dual-ceiling minting, the money-cap denial, and the
currency refusal — but not `seal_settlement`, which is the crate's most
distinctive contribution. It was tested and undemonstrated.

Adds the settlement step: the host settles on chain, the meter reports what the
paid compute actually consumed (5812 µJ measured, against a 6000 µJ estimate —
so the receipt binds what happened, not what was budgeted), and the two are
sealed together. Then it runs the verification a third party would run: recompute
the coupling id from the settlement record and compare it to the receipt's
payload_hash.

It also shows the negative, which is the property that makes the binding worth
anything: re-pointing at a different transaction yields a different id, so the
receipt cannot be moved to another settlement. Output reads
`coupling verified: true` / `re-point to another tx → id matches: false`.

Example-only; no library change.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels
No items
No labels
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set

Reference
Transaction-Science/open-standards!25
No description provided.