open-standards/jcp/extensions/metered-settlement.md

Metered Settlement

Authorize a maximum. Settle on what was measured. Seal the measurement.

Status	Draft 0.1
Position	A JCP capability (../SPEC.md §4.8, §8.1, §8). It introduces no new cryptography: the receipt is a JCR-1 receipt, signed and verified exactly as every other JCP receipt is.
Canonical home	jcp.transaction.science · source at git.transaction.science/Transaction-Science/open-standards
License	Specification text: CC-BY-4.0 · Reference implementation: Apache-2.0 (jcp/jcp-rs/)
Reference implementation	jcp-runtime (hold_priced, settle_priced), jcp-receipt (held_minor, settles), jcp-x402 (metered_usage, the x402 projection)

---

1. The problem, stated once

When a buyer and a seller agree a price before the work, settlement is simple: the amount is a term of the deal, and a dispute is about whether the deal happened.

Machine-initiated payment is mostly not that. The amount is computed after the work, from something the seller measured: tokens generated, bytes moved, seconds of compute, joules burned. The buyer authorizes a ceiling, the work runs, and the seller names a number inside it.

That moves the unit of dispute. It is no longer "did you authorize this?" — a question signatures answer well, and have for decades. It becomes "was this measured correctly?" — a question no payment rail asks, because no payment rail has ever had to. A card network can tell you an authorization was genuine and a capture was within it. It cannot tell you the meter was running.

Metered Settlement is that missing half: a settlement whose measurement is a first-class, graded, signed object, bound to the amount it produced and the payment that moved — enforced before the spend, not reconciled after it.

2. What it is

Three obligations, in order. A conforming deployment does all three; doing two of them is the state of the art and is not this.

(1) Bound it in advance, in both dimensions. The payer's authorization is an upper bound, never an estimate: an estimate is a figure the work may exceed, so admitting work against one is not a bound at all. A grant carries a money ceiling and a joule ceiling, enforced independently, with no rate invented between them (§4.8) — because the two have different sources of authority. The payment mandate bounds the money; the operator bounds the energy. A charge that fits the budget but would burn a datacentre is refused on energy, and the receipt says so.

(2) Reserve, then resolve. A hold reserves the authorized maximum without debiting it, the work runs, and the resolution debits what it actually cost — the remainder released by the hold's removal (§8.1). The reservation has a life, not one event: it can be captured in parts as work is billed, it can carry a deadline past which the payer reclaims it without anyone's cooperation, and what it paid can be refunded, by the party whose money it is and nobody else. Reserving matters because a reservation that does not bind the next decision is not a reservation: two concurrent calls that each read the spend before either hold is counted each see the whole remainder. Releasing matters because without it a ceiling is consumed by the worst case of every call, and a session settling at a tenth of its maxima exhausts its ceiling ten times too fast.

(3) Seal the measurement with the payment. The resolution seals one receipt committing to the measured figure, the grade of the meter that produced it, the amount settled, the maximum it was settled against, and the transaction that paid. This is the object neither party can produce alone: a payment rail knows the transaction and not the energy; a meter knows the energy and not the transaction. Sealing them together is a claim that could not have been assembled afterwards from either side's records.

3. What this does not claim

• It does not prove a measurement honest. It makes the measurement a signed, content-addressed commitment, so a seller who later reports different usage for the same transaction contradicts a signature rather than an invoice line. Detection after the fact, not prevention. That is the strongest claim available to anyone who is not inside the meter, and pretending otherwise would be the one thing that makes the receipt worthless.
• It does not grade a meter. The grade is the measurer's own declaration of how the figure was obtained. What is required is that the grade be present, committed, and not stronger than the figure supports (§5).
• It does not convert between joules and money. Two ceilings, no rate.
• It does not replace the rails. Every projection in §6 keeps its own transport, its own clearing, and its own finality.

4. The shape, concretely

  payer                      enforcement point                    seller
    │                                │                              │
    │  authorize: max M, ceiling J   │                              │
    ├───────────────────────────────►│  hold: reserve (M, J)        │
    │                                │  debits nothing              │
    │                                ├─────────────────────────────►│
    │                                │           work runs, metered │
    │                                │◄─────────────────────────────┤
    │                                │  resolve: settled m ≤ M,     │
    │                                │  measured j, graded          │
    │                                │  debit (m, j); release M−m   │
    │                                │  seal one receipt binding    │
    │                                │  m, M, j, grade, transaction │
    │◄───────────────────────────────┤                              │
    │  receipt: checkable offline    │                              │

Every arrow is a decision made outside any model, and both the allow and the deny seal.

5. Grades, and what a grade may not claim

The measurement carries its provenance and its coverage, from JCP's energy model (../SPEC.md §5), unchanged:

provenance	Means
HwShunt	A hardware energy interface, or a live vendor counter, read the work. Requires a measured figure.
ModelBased	A model calibrated on the host, or a real reading apportioned by a model.
Estimator	A figure derived from a proxy, such as a token count. Carries no measured figure.

coverage	Means
Whole	The figure accounts for the whole of the paid work.
Partial	Part of the work is unaccounted for. The remainder is unmeasured, which is not zero.

A grade MUST NOT claim more than the figure supports. A HwShunt provenance with no reading behind it, or an Estimator presented with one, is incoherent; a conforming issuer demotes such a figure to Estimator before sealing, so the receipt commits the grade it can defend. A verifier refuses an incoherent receipt rather than reading it at the stronger grade.

This is the rule that keeps the whole design from becoming a laundering device. A signed estimate is useful — it is an estimate someone signed. A signed estimate labelled a hardware reading is worse than no receipt at all.

6. Projections onto the rails

Metered Settlement is the general case. Each rail below already implements part of it, and none implements the third obligation. A projection maps the rail's own wire onto the capability; the rail keeps its transport and its finality.

6.1 Card: authorization and capture

The card rails have done obligations (1) and (2) for decades. An authorization reserves an amount and moves nothing; a capture settles at or below it; the difference is released. That is a money hold, by another name, and it is the strongest evidence that this shape is right rather than novel: the largest payment network on earth is built on it.

What a card authorization cannot do is (3). It carries no measurement, so a capture for 83% of an authorization is a number the acquirer relays and nobody can check. Projection: the authorization is the hold, the capture is the resolution, and the receipt adds the measurement the message set has no field for.

6.2 Instant rails: credit-push with no capture

FedNow, Pix, UPI and SEPA Instant are credit-push and irrevocable in seconds. There is no authorization-then-capture: the payment is the settlement. So obligation (2) cannot live on the rail, and it moves before it — the hold is placed at the enforcement point, the work runs, and the push is issued for the resolved amount. This is strictly better suited to a metered charge than it first appears: the amount is known before anything irrevocable happens, which is exactly the order a measured charge wants, and the receipt is the only record that connects the pushed amount to what was measured.

6.3 Stablecoin: the HTTP 402 wire's three metered schemes

The open HTTP payment wire implements obligations (1) and (2) on chain, three ways, and each maps onto the hold's life directly:

Scheme	What it is	Maps to
upto	Sign a maximum; one settlement at what was used	hold → one resolution
auth-capture	Hold, then capture in parts, void the rest, refund later; the client reclaims past a capture deadline	hold with a deadline → captures → void or reclaim → refund
batch-settlement	A commitment per request against a channel; value moves later, in a batch	holds resolved as a running total; settlement deferred to the rail

All three bound the money. None carries a measurement. upto's specification says usage travels "without requiring additional fields or a separate settlement type"; auth-capture captures an amount the server names; batch-settlement reports a chargedAmount. In each, the figure the buyer pays is a number the seller produced, bounded above and otherwise unexplained — obligation (3) is outside all three.

That is the whole of what this capability adds on that wire, and it is stated that narrowly on purpose: the reservation lifecycle there is as complete as ours. What it does not have is the second ceiling — nothing bounds the energy the paid work burns — or the sealed measurement that makes the charged figure checkable. The measurement rides as an extension, keyed metered-usage, specified in x402-metered-usage.md; that document is a wire mapping, not where the capability lives.

6.4 Agent mandates: AP2 payment constraints

An AP2 payment mandate constrains spend with payment.amount_range and payment.budget — a ceiling in advance, which is obligation (1) expressed as a credential. Its budget constraint is explicitly a total across repeated presentations, which is a session ceiling in the sense of §4.8. Projection: the mandate's constraints become the grant's money ceiling; the agent's compute ceiling remains the operator's, and no rate is invented between them.

7. Why this is the forcing function

Payment is becoming digital and machine-initiated, and the two changes together move the amount from quoted to computed. Once the amount is computed, the measurement is the commercial substance of the transaction, and everything the rails were built to protect — identity, authorization, finality — sits on one side of a question none of them asks.

The consequence is already visible in how usage-based bills are defended today: with append-only logs the seller writes, kept by the seller, shown to the buyer on request. That is an invoice with better typesetting. It fails the one test that matters, which is whether a disinterested third party can check it a year later without asking the seller anything.

A sealed, graded, bound measurement passes that test. It is also a tighter constraint on the seller than any audit: a figure committed at settlement cannot be restated, because restating it produces a different receipt id, and the old one is signed.

8. Conformance

A deployment conforms when:

1. every metered charge is admitted against an upper bound in both dimensions, never an estimate (§4.8, C22);
2. the reservation counts against concurrent decisions and the remainder is released on resolution (§8.1, C31); where it is drawn in parts, reclaimed past a deadline, or refunded, each follows its rule (§8.1, C32) — a capture refuses cleanly over what is left, a reclaim releases money and never joules, and only the issuer records a refund;
3. a resolution above its reservation debits and denies, rather than capping silently (C31);
4. every resolution seals a receipt committing to the measured figure, its grade, both amounts, and the transaction, and the grade is coherent with the figure (§5);
5. a verifier can perform every check offline, from the receipt and the settlement record alone.

Published vectors live in ../conformance/v1/.

9. Amendment

This draft is content-addressed by the digest of its published text. A new version is an attributed, reasoned amendment chained to the digest of the version it amends, per the self-hosting discipline of ../../joulecontract/SPEC.md.