Payment rails for machines

The payment systems most businesses use were designed around a person buying from a company. A card payment assumes a cardholder who can be asked to confirm, a merchant with an account, and an amount large enough that a fixed processing cost is a small fraction of it. An invoice assumes a relationship, a billing period and someone who reads it.

Machines buying AI work fit none of those assumptions. The buyer is software. The seller may be one of many operators chosen a moment before the call. The amount of a single call can be a fraction of a cent, and the same agent may make thousands of calls in a task. This article describes the rails Tenzro provides for AI work at that scale, per-call settlement, payment channels and delegated spending, and how they sit underneath the open agent payment protocols rather than replacing them.

Per-call settlement over HTTP

The web has had a placeholder for this for a long time. RFC 9110 defines 402 Payment Required and reserves it "for future use". x402 gives it a working shape: the server answers an unpaid request with 402 and its payment requirements, the client pays one of the offered options and retries, and a facilitator verifies and settles the payment. The x402 project sets out a design rule that matters for machine buyers: payment schemes "must not allow for the facilitator or resource server to move funds, other than in accordance with client intentions".

Per-call settlement solves the unit problem. Each call has its own price and its own payment. It does not, on its own, solve the cost problem: if every call is a separate settlement, very small calls are still dominated by the cost of settling them.

Payment channels for high-frequency work

A payment channel separates paying from settling. The payer locks funds in an escrow once. Each subsequent call is paid by a signed voucher for the cumulative amount owed so far. The payee holds the latest voucher and claims it when it chooses, so any number of calls over one channel settle as one claim.

Channels change what is economical. A stream of sub-cent calls becomes one settlement. They also change what can go wrong: a payee accepting vouchers off the ledger must be sure each voucher would be honoured when claimed. That requires the voucher check to be the same check the ledger will run at claim time, with no separate copy of the rules that could drift.

Delegated spending

The third rail is authority. A person or organisation wants an agent to pay for work without approving every payment, and wants hard limits on what it can do. AP2 records this as mandates: a checkout mandate for the specific items and terms an agent negotiated, and a payment mandate authorising payment against a specific instrument. Its authors describe the sequence as creating "a non-repudiable audit trail" of authorisation.

Mandates describe a purchase. For AI work, where an agent buys continuously rather than in discrete checkouts, delegated spending also needs standing limits: how much per payment, per hour and per day, in which assets, to which counterparties, until when. And it needs a way to stop: one action that ends the agent's ability to pay everywhere, including through channels it has already opened.

Identity on the request

A server deciding whether to serve an agent's request needs to know which agent is asking, not just that a payment arrived. RFC 9421 defines HTTP message signatures, and the IETF web bot authentication work profiles them for automated clients, with a published key directory the server can check. Signed requests let a server tie a payment, a rate limit or a licence term to a specific agent.

What this means for agent builders

Choose rails by the shape of the work. One-off calls to a paid API fit per-call settlement over HTTP 402. Sustained, high-frequency calls to the same provider fit a channel. Anything an agent does without a person watching needs standing limits that are enforced where the agent cannot change them, and a revocation that reaches every rail the agent uses. Check the cost of settling on each rail against your typical charge: a rail that cannot carry a small payment economically will push you towards channels either way.

Where Tenzro fits

Tenzro is the settlement layer for AI work, and it speaks the open agent payment protocols rather than replacing them. What is built, per the Tenzro repository documentation:

Per-call settlement. Every node serves an HTTP 402-gated route for paid chat completions alongside its OpenAI-compatible routes. A model a node forwards to another provider is never free: a caller with no credential is asked for payment over x402. Every payment leaves one record binding the request digest, the quote digest and the USD price the payer signed, with refunds by the payee and standing payee splits settled against the same record. An application can carve a developer margin out of the amount at settlement, within a governed maximum.

x402 schemes. A node accepts x402 payments in Tenzro's own schemes, a direct payer-signed payment, an upto ceiling, batch settlement against cumulative vouchers on an escrow and delivery-versus-payment where the seller is paid when it reveals the key to a sealed delivery, and in the EVM schemes EIP-3009, Permit2 and ERC-7710, settling those through the facilitator its operator names. Every Tenzro scheme ends in consensus state.

Payment channels. An agent opens an escrow from its wallet; the lock counts against its limits when it opens. Vouchers on it are signed by a serving node the agent's terms assign. A payee accepting vouchers off the ledger runs the same check the ledger runs at the claim, so any number of requests over one channel leave one voucher to claim.

Delegated spending. An agent holds no key of its own. Its authority is its terms, set by its root, a person's passkey or a machine's TPM or Secure Enclave key: per-transaction, hourly and daily limits, per-asset limits, allowed counterparties, chains, payment protocols and models, and an expiry. Every payment entry point, including x402 and the HTTP 402 gates, runs the same check against consensus state. A revoked agent's channels stop paying everywhere at once.

Signed agent requests. A serving node signs an agent's outgoing requests in the web bot authentication profile of RFC 9421, and every node serves the agent's key directory, rendered from its terms. A revoked, quarantined or expired agent's directory is empty from the next block.

Clear payment classes. Payments settled on the Tenzro ledger, payments proven from another chain, and payments on card, bank or processor rails are kept apart. A payment on card, bank or processor rails enters the ledger only as an attested record from a bonded attestor, labelled, capped and never counted as proven. Tenzro is not a licensed payment provider; regulated functions at the fiat boundary stay with the licensed parties that perform them.

Agents on other chains. An agent's account on another chain holds no key and pays only as an action under a grant its terms allow; Tenzro records such a payment as proven only when that chain's report route proves it.