Per-byte x402 pricing: deterministic workload bands in atomic USDC

Per-byte x402 pricing: deterministic workload bands in atomic USDC

An x402 seller can price a call by the size of its input without a quote token, a price table or a second round trip, provided the price is a pure function of the admitted request body. The Red Cup seller charges $0.0012 for the first 4,096 bytes of canonical JSON and 100 atomic USDC units ($0.0001) for each further started 4,096-byte band, and the same body therefore produces the same amount on the unpaid probe and on the paid retry. We tested this against the live 402 responses on 2026-10-22 and tabulate the measurements below.

What is the pricing rule?

The 69 standards and conversion offers in the market catalog (JSON, CSV, CBOR, XML, HTML, TOML, YAML, URI templates, MIME types, HTTP dates, multihash and more) publish a workload tariff in their catalog entry. For the JSON Pointer offer the live catalog says:

"pricing": {
  "mode": "canonical-json-byte-bands",
  "includedBytes": 4096,
  "additionalUnitBytes": 4096,
  "additionalUnitAtomic": "100",
  "maximumAtomic": "9600",
  "minimumAtomic": "1200",
  "priceBasis": "starting-price",
  "settlementDecimals": 6,
  "quote": "native-x402-payment-required",
  "metering": "UTF-8 bytes of canonical JSON after input admission; whitespace and alternate escaping do not change the price"
}

In words: the minimum is 1,200 atomic units, which is $0.0012 because USDC has six decimals. Each started band of 4,096 bytes beyond the included 4,096 adds 100 atomic units. The quote field says the amount is delivered in the standard x402 payment requirement, not in a custom header. For a body of n canonical bytes:

amount = 1200 + 100 × ceil(max(0, n − 4096) / 4096) atomic units.

What do the live quotes show?

We sent unpaid POST /v1/data/json-pointer requests with a string value of increasing length and decoded accepts[0].amount from the PAYMENT-REQUIRED header. No payment was signed. The n column is the exact request body size in bytes (compact JSON).

Every row matches the formula. Two more probes tested the "canonical" claim:

• A 5,033-byte body pretty-printed with indentation and padded with 20,000 trailing spaces, 25,061 bytes on the wire, quoted 1,300, the same as the compact version.
• The same value with each a written as the escape a, 30,033 bytes on the wire, also quoted 1,300.

So neither whitespace nor alternate escaping moves the price. The meter reads canonical bytes after the body has been admitted, not the Content-Length header and not the raw bytes.

Why derive the price from the body at all?

A fixed price is simple, but a JSON conversion of 20 bytes and one of 60,000 bytes do not cost the seller the same. A per-call dynamic price solves it, but only if the buyer can still know the price before signing. In x402 the amount in the challenge is what the buyer signs. If the seller computes a different amount when the signed request returns, the verification fails or, worse, the buyer pays more than it saw. The Red Cup seller avoids that failure in three ways:

1. The body is admitted before the quote. The seller reads the request through the bounded canonical JSON codec (Refuse before you charge), and only the admitted body enters the x402 adapter's getBody method. The official SDK's dynamic price function resolves from that body before verification.
2. No ambient inputs. The price is not derived from a buyer-supplied Content-Length, an unsigned price field, a traffic counter or a clock. Two identical requests at different times quote identically.
3. A small-request signature does not buy a large request. The signed amount covers the exact band; the source documents that a small-request authorization does not buy a larger-request tariff. A 60,000-byte body is quoted at 2,600, and a signature for 1,200 does not satisfy it.

There is no separate quote token, repayment loop, price worker or synthetic settlement protocol. The standard 402 is the quote.

What is the maximum a buyer can be charged?

The catalog declares a maximumAtomic of 9,600 ($0.0096) for these offers. In practice the input limit is lower than the point where that cap binds: the JSON offers cap input at 64 KiB, which by the formula costs at most 2,700 atomic units ($0.0027). The 65,033-byte probe above was the largest we sent. House capability offers carry the maximum tariff as their spending bound, and a buyer library should compare the challenge's amount against its own configured ceiling before signing, whatever the catalog says. The Red Cup buyer takes maximumAmount in atomic units, never a floating-point dollar amount.

Why use atomic integers instead of dollars?

The catalog's price field is a human string ("$0.0012") and the challenge's amount is an integer string ("1200"). The seller treats the integer as authoritative and derives every displayed price from it. Atomic prices and workload bands are exact integers with no dollar conversion and no assumed token decimal count in the engine; a seller may quote an exact native consideration as { amountAtomic: "3", asset: "eip155:5615611/erc20:0x…" }. Floating-point price math in a payment path accumulates rounding error, and a buyer that parses "$0.0012" as a float can mis-sum a budget. The engine's spending ceilings are parsed as exact atomic units, and an excess decimal is refused instead of rounded.

Is this a measurement of cost?

No, and the seller says so. The tariff is a commercial workload tariff, not a benchmark of CPU consumption, provider monetary cost, physical energy or demand elasticity. The catalog's own evidenceScope field reads: "commercial-workload-tariff; no measured CPU, monetary-cost, physical-energy or customer-demand claim". We have not measured a margin and do not report one. The settlement journal does retain the canonical input byte count and the quoted amount for each paid call, so a future cost study has the denominator it needs.

Can price depend on usage after the fact?

The engine also supports the official upto scheme, where the route price is a ceiling the buyer authorizes and the handler reports the actual consideration afterwards (through the Settlement-Overrides header in the fetch transport). The shared before-settle hook refuses a non-canonical amount or one above the signed ceiling before any facilitator call, and the internal override header is stripped from every delivered response so a request header can never control settlement. That mode is source-tested with SDK doubles; the market catalog itself remains on the fixed exact scheme until an owning declaration and a real meter exist. An elapsed interval is not CPU usage, so we do not bill by one.

How do I reproduce this?

python3 - <<'PY'
import json, urllib.request, base64
def amount(body):
    req = urllib.request.Request("https://market.561.group/v1/data/json-pointer",
        data=body, headers={"content-type": "application/json"}, method="POST")
    try: urllib.request.urlopen(req)
    except urllib.error.HTTPError as e:
        return json.loads(base64.b64decode(e.headers["payment-required"]))["accepts"][0]["amount"]
for n in (10, 5000, 9000, 60000):
    body = json.dumps({"value": {"x": "a" * n}, "pointer": "/x"}, separators=(",", ":")).encode()
    print(len(body), amount(body))
PY

The script signs and pays nothing; it reads the 402 and prints the quote. For the rest of the seller's behaviors, see what an x402 seller should do beyond the spec, and for a complete decoded challenge, How an x402 payment works.