An agent that plans a trip, writes code or monitors a plant will soon buy things from other machines: a model call from one provider, a dataset from another, an hour of GPU time, a page from a publisher's site. Each purchase is small. Together they are a ledger that someone has to reconcile, audit and occasionally dispute.
Moving value between machines is the easy part. Card networks, bank transfers and stablecoins all move value. The hard parts are older and more boring: knowing exactly what each payment was for, proving what was delivered, keeping spending inside limits nobody can talk the agent out of, and settling many tiny charges without a fee or a signature per call. This post is about those parts.
The protocols arriving at the edge of the web
Several open efforts are giving machines a way to ask for and make payments. HTTP has always reserved status 402 Payment Required; x402 gives it a concrete flow, in which the server answers 402 with payment options, the client retries with a signed payment, and a facilitator verifies and settles it. Google's Agent Payments Protocol introduced signed mandates: an intent mandate recording what a user authorised, with conditions such as price limits, and a cart mandate locking the exact items and price. For identifying the agent itself, HTTP Message Signatures and the IETF's Web Bot Auth work let a site verify which automated client is calling.
These are complementary. None of them, on its own, answers the accounting questions.
Accounting: one record per payment, bound to the request
On Tenzro, every payment leaves exactly one record, keyed by a reference derived from the chain, the payee, a digest of the request, a digest of the payee's quote and a nonce. A payment id settles at most once and a reference is recorded at most once, so double-charging is structurally impossible rather than a reconciliation finding.
What the payer signs binds the payment to its purpose:
- a request digest naming the resource;
- a quote digest over the payee's quote, which lists the price, the accepted assets with ceilings, the licence, the content-usage terms and the cart lines it covers, so a checkout can pay only for lines the payee quoted;
- the price in a stable unit;
- any developer margin an application takes, to a named wallet within a governed maximum.
After delivery, the payee attaches delivery receipts to the record: a digest of the delivered body and, for AI work, the digest of the signed inference receipt. Request, quote, payment and receipts form one hash chain. History is the chain's event index, not a second database, so a finance team and an auditor read the same thing:
tenzro payment history # pages payment records in chain order
tenzro payment record # one record, with its delivery receiptsRefunds are first-class: the payee returns part or all of a payment, the refunded total never exceeds the amount, and the record shows it.
Receipts: evidence, not assertions
A payment record says money moved. The receipt says what was delivered. For inference, Tenzro's serving nodes sign a receipt with a hardware-certified key covering the model hash, the serving machine, the request nonce, input and output commitments and the billed units, with billing capped by what actually crossed the wire. An agent's evidence pack can include its payments, each proven against a certified checkpoint, and an offline verifier refuses a record proven at the wrong reference or made by an agent the pack does not cover.
Not every payment can be proven equally, and the record says so. There are three classes, never mixed:
| Class | Established by | Counts as proven |
|---|---|---|
| native | settlement on the ledger | yes |
| proven | an agent account's payment on another chain, proven through that chain's report route | yes |
| attested | a statement of a payment on an outside rail (card, bank, processor) | never |
Attested payments are enabled by default, labelled, and capped (10,000 USD at genesis, a governed value). Card and bank rails, which need a business relationship, run as operator plug-ins under the operator's own credentials. They are never required.
Limits: enforced where the agent cannot reach
An agent's spending authority is its Terms, approved by its root (a person's passkey or a machine's hardware key) and enforced in consensus: per-payment and daily limits per asset, counted at their price, allowed counterparties, optional KYC floors for counterparties, step-up approval above a threshold or for a new counterparty, and expiry. The serving node checks every payment before signing it for the agent, and the execution layer checks it again. Spend is counted in shared state, so no node can be persuaded that the agent has budget left when it does not.
Settlement: many calls, one claim
Per-call settlement does not scale to machine traffic. Tenzro uses three patterns.
Channels with cumulative vouchers. The payer locks a deposit in an escrow. Each request carries the next cumulative voucher; any number of requests leave one voucher for the payee to claim. A delegated agent's vouchers are signed by a serving node its Terms assign, honoured only while that assignment holds and only if signed before any revocation. A payee checking vouchers off-ledger runs the same check the ledger runs at the claim, so a revoked agent stops paying everywhere at once.
Streams. For rented capacity, the renter locks the term in a stream escrow that accrues per epoch. The provider draws only epochs that validators' service-level verdicts found available; a missed epoch stays with the renter.
Splits. A payee can set a standing split rule, so every settlement to it, direct or from an escrow, is divided among several parties in the same execution, with exact conservation. An app, an agent author and a model provider can each be paid from one payment.
In what people already use
Machines should not force their owners onto new tools. On Tenzro, a person signs with a passkey on the devices they already have, and standard EVM and Solana wallets can sign transactions directly. A payment settles in whatever the payee's quote accepts on the ledger, including stablecoins, each opt-in for the operator, the payee and the agent; the network's own token is used for the settlement fee. Delegated agents can also hold accounts on other chains that act only under short-lived, bounded grants. On the web, a publisher gate answers an unpaid agent request with 402 and the requirements and lets the handler run only after a facilitator has settled the payment; the node's facilitator holds no funds and no keys. Outgoing agent requests are signed in the Web Bot Auth profile of RFC 9421, so a site can tell which agent is calling.
What this means for builders and regulators
Design machine payments as accounting first. Bind each payment to a request and a quote, attach delivery evidence, label what cannot be proven, enforce limits where the agent cannot edit them, and batch settlement without batching accountability. For regulators, the useful property is a single record per payment that ties an automated purchase to an accountable root, a quoted price and a delivered result.
Where Tenzro fits
Built: one consensus record per payment bound to request and quote digests, delivery receipts and refunds, native, proven and attested classes with a governed cap, agent Terms with per-asset limits and step-up, escrow channels with cumulative vouchers, streams, payee split rules, an x402 facilitator and publisher gate, evidence packs, and Web Bot Auth request signing. Card and bank rails exist only as optional operator plug-ins. The network is live in preview; governance decides the steps to testnet and mainnet.
