x402's upto Scheme: Metered Agent Billing with Permit2

The exact scheme answers one question: pay this precise amount, get the resource. But the cost of an LLM call is not known until the last token is generated. The upto scheme is x402's answer to metered billing — the agent authorizes a maximum, the server settles the actual amount, and Permit2 enforces the cap on-chain.

We closed the exact SVM deep dive with a prediction: whichever chain ships a usable metered scheme first becomes the most interesting settlement rail for a gateway that bills by the token. The scheme exists today, and it lives where the rest of the protocol lives — two spec files in the coinbase/x402 repository, scheme_upto.md for the chain-agnostic contract and scheme_upto_evm.md for the EVM implementation. The spec's own first use case, verbatim: "Paying for LLM token generation (charge per token generated)." This is a scheme written for exactly the workload an inference gateway carries.

It is also already in production. Apify runs it across more than 20,000 Actors, charging actual usage against a client-signed allowance. Before getting there, the mechanics.

The problem exact cannot price

The exact scheme — EIP-3009 on EVM, partially signed transactions on Solana — settles a fixed amount that both sides know before the request runs. That fits a per-article paywall or a flat per-call API. It does not fit usage-based pricing, and the upto spec names the shapes it was written for: LLM token generation, bandwidth metering charged per byte transferred in a single request, and dynamic compute priced on actual resources consumed.

Without upto, a seller of metered work has two bad options. Charge the worst case up front and refund the difference — which means every request over-locks the client's funds and the seller takes on refund plumbing. Or run the work first and invoice afterwards — which means extending credit to an anonymous wallet. The upto scheme splits the difference cryptographically: at verification time the client's signature covers a maximum; at settlement time the server names the actual amount, and the chain refuses anything above the cap.

That phase-dependent reading of one field is the heart of the scheme. The amount in PaymentRequirements means "maximum the client authorizes" during verification and "actual amount to charge" during settlement. In the spec's words, the settled amount "is communicated by the resource server to the facilitator via the amount field in the settlement-time PaymentRequirements" — and the facilitator MUST verify it does not exceed the authorized maximum from the client's signed authorization.

Five invariants

The chain-agnostic spec is short because it is mostly a list of MUSTs. Five of them define the scheme.

Single-use. Each authorization settles at most once. Once settled — for any amount — it is consumed. The spec justifies the choice plainly: a clear audit trail, a simpler mental model, and a match for x402's request-response pattern. There is no running tab; one authorization maps to one request.

Time-bound. Every authorization carries an explicit validity window: a validAfter before which it is invalid and a deadline after which it expires. This limits the exposure window for unused authorizations and forces timely settlement.

Recipient-bound. The authorization cryptographically binds the recipient address, which prevents a malicious facilitator from redirecting funds. On EVM this is the job of the Permit2 witness pattern — more below.

Capped. The settled amount MUST be less than or equal to the authorized maximum — and MAY be zero. Zero matters: if no usage occurred, no charge occurs, and on EVM a zero settlement requires no on-chain transaction at all.

Replay-protected. On EVM, Permit2's nonce mechanism enforces the single-use rule; the spec requires any other network to implement equivalent replay protection before an upto implementation can exist there.

Why Permit2, not EIP-3009

EIP-3009 cannot carry this scheme. A transferWithAuthorization signature bakes the exact value into the signed message — the token contract will move that amount or nothing. There is no way to settle less than what was signed. A maximum-with-variable-settlement needs a different primitive, and the EVM spec reaches for one that has been sitting in production since 2022: Uniswap's Permit2, deployed at the same canonical address (0x000000000022D473030F116dDEE9F6B43aC78BA3) across chains.

Permit2's SignatureTransfer half does precisely what upto needs. The client signs a PermitTransferFrom naming a token and a permitted amount; the spender can then execute a transfer of up to that amount, once, before the deadline. Nonces are unordered — a bitmap rather than a counter — so an agent can hold many open authorizations in parallel without sequencing them. And the witness variant, permitWitnessTransferFrom, folds extra typed data into the EIP-712 digest the client signs, so arbitrary scheme-specific constraints become part of the signature itself.

The upto EVM spec uses that witness slot for three fields: to (the recipient, closing the redirect attack), facilitator (the address allowed to execute settlement), and validAfter (the start of the validity window — Permit2 natively carries only the deadline). The payment payload the client sends is the signature plus the full authorization it covers:

{
  "x402Version": 2,
  "payload": {
    "signature": "0x…",  // EIP-712, permitWitnessTransferFrom
    "permit2Authorization": {
      "permitted": {
        "token": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913",  // USDC on Base
        "amount": "250000"  // the MAXIMUM: $0.25
      },
      "from": "0x…",       // client wallet
      "spender": "0x…",    // the x402 Permit2 proxy
      "nonce": "0x…",      // unordered, single-use
      "deadline": "1753142400",
      "witness": {
        "to": "0x…",          // recipient, bound in the signature
        "facilitator": "0x…", // from the facilitator's /supported extra
        "validAfter": "1753138800"
      }
    }
  }
}

One prerequisite sits outside the flow: the client's wallet must have approved the canonical Permit2 contract as a spender of the token, once per token. The spec offers three routes — a direct approve transaction where the client pays gas, a sponsored ERC-20 approval where the facilitator covers it, or an EIP-2612 permit where the token supports one. It is one-time setup, but it is the one place the upto scheme loses the pure "signature is the payment, no gas ever" property that makes EIP-3009 walk-up payments so clean for fresh wallets.

The proxy and the verifier's checklist

Permit2 alone does not enforce the facilitator binding, so the spec introduces a thin contract between facilitator and Permit2: x402UptoPermit2Proxy, deployed at 0x4020A4f3b7b90ccA423B9fabCc0CE57C6C240002 — a vanity address that opens and closes with 402. The proxy carries the facilitator field in its witness struct for access control, and its settle function is where the variable amount becomes concrete:

x402Permit2Proxy.settle(permit, actualAmount, owner, witness, signature)
// requires: actualAmount <= permit.permitted.amount

Attempting to settle above the cap fails with the scheme's dedicated error, invalid_upto_evm_payload_settlement_exceeds_amount. Settling zero skips the chain entirely — the settlement response returns success: true with an empty transaction hash. And every settlement response carries a required amount field reporting what was actually charged, in atomic units, so the client learns the real cost the moment the resource returns.

Verification is heavier than exact's, and the spec walks the facilitator through the checks: recover the signer from the EIP-712 signature and match it to permit2Authorization.from; confirm the client's ERC-20 allowance to Permit2 covers the maximum — and if it does not, return 412 Precondition Failed with PERMIT2_ALLOWANCE_REQUIRED rather than a generic failure, so clients can trigger the one-time approval; confirm balance; confirm the permitted amount equals the requirements' amount; check deadline and validAfter; match token and network; and finally simulate the worst case — a full-amount settle call — before answering that the payment is valid. The simulation matters because verification happens before usage is known: the only amount worth simulating is the cap.

Production proof: 20,000 Actors

This is not a paper spec. On June 30, 2026, Apify put more than 20,000 Actors on x402, settling USDC on Base, with upto as the primary scheme for variable-cost runs and exact alongside it. The flow is the spec verbatim: the client sends a signed allowance, Apify starts the Actor run, and the final charge is actual usage — anywhere from zero up to the approved cap. Their published price anchors give the scheme a concrete texture: one dollar buys roughly 380 Instagram profiles, 250 Google Maps places, 165 Amazon products, or 2,500 X posts, with the exact figure depending on what each run consumed.

Scraping runs and inference calls are economically the same shape — variable work, cost known only at completion, too small to invoice. A production deployment at this scale, reachable through Coinbase's Agentic Wallet CLI and an x402-aware MCP client, is the strongest signal yet that capped-authorization metering is becoming the default way agents buy variable-cost work.

The allowance pattern is converging

Step back and upto looks familiar. The Agentic Commerce Protocol's delegated payment attaches an allowance — max_amount, expires_at, single-use — to a vaulted card token. ERC-7715 permissions and session keys grant an agent a scoped, capped spending budget at the wallet layer. And upto binds a per-request cap into a Permit2 signature. Three rails — custodial card, smart account, stablecoin transfer — independently landed on the same primitive: never give an agent open-ended spending authority; give it a cryptographically enforced ceiling and charge actuals underneath it.

The differences are scope and granularity. A session key is a standing budget across many requests; an ACP allowance covers one checkout; an upto authorization covers exactly one x402 request-response. For machine-to-machine metered work, the per-request cap is the tightest of the three — the blast radius of a compromised or confused agent is one request's maximum, not a day's budget.

What it means for LLM4Agents

Per-token billing is this platform's native unit, and upto is the first x402 scheme whose semantics match it exactly. Our reserve → proxy → settle pipeline already implements upto's lifecycle internally: reserve a worst-case amount against the agent's deposited balance, run the inference, settle the actual token cost, release the difference. The upto scheme is that same state machine pushed down to the settlement rail — permitted.amount is the reservation, the settlement-time amount is the metered actual, and the zero-settlement rule covers the failed-request refund path with no transaction at all.

That correspondence cuts both ways. It means the gateway could offer a true walk-up metered tier: an agent with no deposit signs an upto authorization capped at, say, max_tokens times the per-token price, and pays only for tokens actually generated — no account, no prepaid balance, no refund flow. It also means the deposit model keeps a real advantage: no Permit2 approval prerequisite, no per-request signature, no on-chain settlement latency in the request path. The platforms that win will offer both and let the agent's wallet posture decide.

The competitive read is equally direct. Apify proved the scheme at scale for scraping; inference is the larger market with the same cost structure. A gateway that can quote a 402 with an upto requirement, meter the generation, and settle actuals has a strictly better story for one-shot agent traffic than any prepaid-only competitor.

Staying on the frontier

Concrete steps, in order. First, prototype the seller side on Base testnet: expose one gateway endpoint whose 402 response offers scheme: "upto" with a cap derived from the request's max_tokens, verify against a facilitator that implements the checklist above, and settle the metered actual from the existing billing pipeline. The internal reservation machinery already computes every number the scheme needs.

Second, handle the approval prerequisite as onboarding, not as a mid-request failure. Detect PERMIT2_ALLOWANCE_REQUIRED and return actionable guidance — including the sponsored-approval route for wallets that hold USDC but no gas, which is the normal condition of an agent wallet.

Third, publish per-settlement metering evidence. The scheme's trust delta is the seller's burden; a settlement response whose amount is accompanied by a token-count breakdown the client can check against the response body turns "trust us within the cap" into something auditable — and into a selling point.

Fourth, watch the specs directory. Today upto has a chain-agnostic contract and one concrete implementation, EVM via Permit2. There is no SVM variant yet — Solana's transaction model has no Permit2 equivalent, so a metered scheme there will need a different primitive, exactly the kind of divergence the exact schemes already showed. Whoever tracks that gap closes it first.