Settlement for the Machine Economy

Abstract

Machines that buy inference, compute, storage and data from each other need a settlement layer that prices work fairly, proves it was delivered and pays for exactly what was used. Tenzro Network 1 provides one. A compute price index, built from metered and attested usage, is committed to consensus. Compute claims standardise capacity so it can be bought ahead, delivered or settled against the index. SLA attestation lets the chain decide whether a provider delivered, and rental billing follows that verdict. Settlement is metered and per-use by default. Payments run in TNZO or in stablecoins through Bridge.xyz wallets, x402 and MPP, including gas paid in stablecoins. Agents act under AP2 mandates and buy from merchants through the ACP buyer side.

1. Introduction

Human commerce settles in large, infrequent payments between parties who know each other. Machine commerce is the opposite: many small payments, per request or per second, between parties that met a moment ago. Four things follow.

1. Prices must be discoverable and grounded in real transactions, not in self-reported list prices.
2. Delivery must be provable. A buyer who rents a GPU for an hour needs the network, not the seller, to say whether the hour was delivered.
3. Payment must be metered. A buyer should pay for the tokens, seconds or bytes it used, not a flat subscription.
4. Payment must fit the buyer's authority. An agent spends under a mandate and scope its owner signed, and every payment must fit inside them.

2. Parties and instruments

Settlement instruments:

3. The compute price index

The compute price index is a public record of what compute actually costs on the network.

• Inputs. Settled, metered usage: signed receipts from providers for inference, rental and storage, each naming the resource, the hardware class, the quantity and the price paid. Receipts from attested hardware carry the attestation that identifies the platform.
• Aggregation. For each class of resource (a model on a class of hardware, a GPU class, storage by durability tier) validators compute the index from the receipts settled in the period.
• Commitment. The index is committed to consensus. Every node derives the same value from the same settled history, and anyone can recompute it.

Because the index is built from settled transactions rather than asked-for prices, a provider cannot move it by advertising. Wash trading is costly: every receipt corresponds to a settled payment that paid fees.

Agents use the index to decide what a fair price is before they buy. Providers use it to price competitively. Compute claims use it for cash settlement.

4. Compute claims

A compute claim is a standardised claim on capacity. Its terms are:

Two settlement modes are supported.

• Physical delivery. The provider reserves the capacity. Usage is metered and proven by the provider's signed receipts and, on attested hardware, by attestation. The claim settles as the SLA is attested.
• Cash settlement. At the end of the window, the claim settles in cash against the compute price index for that class.

Claims are transferable, so a buyer that no longer needs capacity can pass it on. Standard terms make claims comparable, so an agent can buy capacity ahead of demand and a provider can sell its future capacity with certainty.

The hard part of any claim on compute is proving delivery. On Tenzro, delivery is proved by the chain's SLA verdict.

5. SLA attestation

A provider that sells capacity or a service level commits to it with a bond. The network checks delivery.

1. Probes. Validators issue challenge probes to providers at unpredictable times. A probe asks the provider to prove it holds the capacity or data it claims, or to answer a request within its service level.
2. Proofs. Providers answer with signed availability proofs. For storage, the answer is a proof of retrievability over challenged data. For compute, it is a signed availability proof from the provider's hardware-rooted key, with attestation where the hardware supports it.
3. Verdict. Validators record the results. For each epoch, the chain reaches a verdict: delivered or missed.
4. Billing. Rental billing follows the verdict. Streaming rental escrow releases an epoch's payment to the provider only when the verdict for that epoch is delivered. A missed epoch is not paid and feeds slashing of the provider's bond.

The buyer does not have to monitor the provider, and the provider does not have to trust the buyer's word. Both rely on the chain.

6. Metered settlement by default

Most machine purchases are metered. Tenzro makes metered, per-use settlement the default path.

1. Authorisation. The buyer signs a ceiling: the most it will pay for this session or request, under its mandate and delegation scope.
2. Service. The provider serves and meters usage: tokens in and out, seconds of compute, bytes stored or transferred.
3. Usage record. The provider signs a usage record naming the request, the model's manifest root and the quantities. On attested hardware, the record is bound to the attestation.
4. Capture. The payment captured is the metered amount, never more than the ceiling.
5. Dispute. The buyer can dispute a usage record within a window. The provider's bond backs the record.

Metering runs for every access mode, including prepaid and subscription access, so operators can price the next term from real consumption.

For long-running or streaming work, metered sessions settle incrementally through stream escrow or micropayment channels. Parties exchange signed balance updates off the ledger and settle the latest state periodically or on dispute. Small settlements are batched and netted, so the ledger records the result rather than every step.

7. Payment rails

7.1 TNZO

TNZO pays all network fees and transaction settlement. A settlement in TNZO is final when the block that carries it is final. See TNZO.

7.2 Stablecoins

Many buyers hold stablecoins, not TNZO. Network 1 supports stablecoin payments directly.

• Wallets. Stablecoin wallets are provided through Bridge.xyz, bound to the holder's hardware-rooted identity.
• Payments. Services can be priced and paid in stablecoins through x402 and MPP.
• Gas in stablecoins. A payer can fund gas in stablecoins through the same rails, so an agent that holds only stablecoins can transact. The network's fees are accounted in TNZO.

7.3 HTTP 402: x402 and MPP

HTTP 402 Payment Required turns any HTTP resource into a paid one. Tenzro's OpenAI-compatible routes, model endpoints and other paid resources use it.

1. The client requests a resource.
2. The server answers 402 with a payment challenge: the price, the asset, the payee and the terms.
3. The client's wallet signs a payment credential bound to its DID and retries the request with it.
4. The server verifies and settles the payment, serves the response and returns a receipt.

x402 covers stateless, one-shot payments. MPP adds sessions for streaming and per-token billing. Both are open protocols, and a client that speaks either can pay a Tenzro service without an account or an API key.

# An unpaid request to a paid route returns a 402 challenge.
curl -i https://rpc.tenzro.xyz/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"<model-id>","messages":[{"role":"user","content":"Hello"}]}'

7.4 AP2 mandates

AP2 mandates let an owner pre-authorise an agent's purchase: what may be bought, up to what amount, before when. Tenzro signs and verifies mandates, validates the pair of mandates for a checkout and payment, and records violations as reportable evidence.

7.5 ACP buyer side

The ACP buyer side lets agents on Tenzro buy from merchants that accept agent checkout through ACP. The agent runs the checkout under its mandate and scope; payment settles through the rails above.

7.6 Other networks

Settlements can involve assets on other networks through bridges and ERC-7683 cross-chain intents. The payer states the outcome; the network routes it. Bridges act on certified finality.

8. Three ceilings on every agent payment

An agent payment clears only if it fits inside three independent ceilings:

1. The protocol mandate or challenge, such as the AP2 mandate's items and maximum, or the ceiling signed for a metered session.
2. The delegation scope the owner signed for the agent: maximum per transaction, daily ceiling, allowed operations, counterparties, payment protocols and chains, and a time bound.
3. The account's spending policy, enforced on-chain by the smart account's validator modules at signing time.

Every ceiling must pass. A compromised agent key can do no more than its scope allows, and only until the owner revokes it. See Hardware-rooted identity.

9. The settlement split

A settled service payment is divided once, according to the serving node's mode:

• A private node, reached only through keys its operator issued, keeps the whole payment.
• A public node that validates pays the treasury's share.
• A public node that does not validate pays the treasury's share and a share to the RPC provider that validates on its behalf.

Every rate is set by governance in one policy. Nothing in the split is destroyed; the treasury's share accumulates for governance to disburse. Gas is separate: it follows an EIP-1559-style base fee split between burn and treasury, with priority fees to validators.

10. Receipts, reputation and disputes

Every settled service produces a receipt signed by the provider. Receipts do several jobs.

• They are the buyer's proof of what was delivered and paid.
• They feed the compute price index.
• They feed provider reputation. Reputation grounded in settled payments is expensive to fake: every point of it cost a real payment and its fees. Receipts can be written as ERC-8004 feedback so reputation is visible on other chains.
• They are evidence. A receipt that contradicts an operator's signed policy proves a breach and slashes the operator's bond. See Trust and provenance.

Disputes over judgement, such as quality, go through the dispute process, which can release or refund escrow and slash bonds.

11. Security

• Signed by the payer. Anything that moves money needs a signature from the paying account's hardware-rooted key. No node operator can move a buyer's funds.
• Replay-safe. Credentials and mandates are bound to a nonce, a payee and a time window.
• Exact arithmetic. Amounts are integers in the smallest unit; splits conserve the total.
• Bonded providers. Every provider that sells capacity or a service level has a bond that the chain can slash on a provable fault.
• Final on consensus. Settlement state lives on the ledger and is final with the block that carries it.

12. Conclusion

Network 1 settles the Machine Economy on its own terms: prices from settled transactions, capacity as standardised claims, delivery judged by the chain, payment metered to the unit and paid in TNZO or stablecoins through open protocols, all under the authority an owner signed. For hands-on detail, see Machine Economy, Compute claims and price index, SLA attestation and metering, Stablecoin payments, x402, MPP and Agent commerce.