Payments

Payments on Tenzro Network 1 are built for the Machine Economy. An agent that finds a model, a GPU or a dataset on the network pays for it per request or per unit of use, in TNZO or in stablecoins, with no account to open and no contract to sign first. Every payment is bound to the identity that pays and to the spending limits that identity carries, and every payment settles on the Tenzro ledger in TNZO.

What you can pay with

Whatever the rail, TNZO pays all network fees and settles every transaction underneath. A stablecoin payment is recorded and settled on the same ledger as a TNZO transfer.

The HTTP 402 flow

Every HTTP rail follows the same three steps:

1. The client requests a paid resource, for example POST /v1/chat/completions on https://rpc.tenzro.xyz, without an API key.
2. The server answers 402 Payment Required with a challenge: the price or ceiling, the asset, the payee and the protocol and schemes it accepts.
3. The client signs a payment credential with the paying account's key and retries. The node verifies the credential, settles the payment on the ledger, serves the request and returns a receipt.

A challenge is bound to the resource, the payee and the amount it was issued for. A credential cannot be replayed against another resource or redirected to another payee, and a receipt is issued only once the settlement transaction has landed in a finalised block.

The OpenAI-compatible routes accept either an API key in the X-Tenzro-Api-Key header or payment per request over HTTP 402. See OpenAI-compatible APIs and API keys.

Identity and spending limits

A payment is only valid if it is signed by the account that pays. The node derives the debited account from the key that signed the credential, so no request can name someone else as the payer. Keys are hardware-rooted: a passkey for a person, a TPM 2.0 or Secure Enclave key for a machine. See Hardware-rooted keys.

Agents and machines pay under a delegation scope set by the human or organisation that controls them. The scope is checked on every payment, whichever protocol or entry point it arrives through:

• a maximum value per transaction and a maximum daily spend;
• the operations the agent may perform, such as inference or transfer;
• the payment protocols it may use, such as x402 or mpp;
• the chains it may operate on, and an optional validity window.

Set a scope for a machine identity with the CLI. This is an owner call, signed by the controlling account:

tenzro identity set-delegation did:tenzro:machine:<agent> \
  --max-tx-value 5 \
  --max-daily-spend 50 \
  --allowed-ops inference,transfer

On-chain, smart accounts enforce the same limits at signing time through validator modules. See Smart-account policies.

AP2 mandates

AP2 is an open protocol for agent payments. A mandate is a signed statement from a person that an agent may buy something on their behalf, within stated limits. Tenzro uses two mandates:

• Checkout mandate: what the user agreed to buy, from which merchant, at what maximum amount, until when.
• Payment mandate: the payment the agent makes to complete that checkout. It carries the hash of the checkout mandate it belongs to.

Before a mandate-backed payment settles, three checks must all pass:

1. The mandate pair is consistent: the payment matches its checkout mandate, stays within its amount and has not expired or been used up.
2. The signer is who they claim to be: the signing key is listed in the signer's DID document.
3. The agent's delegation scope and spending policy allow the payment.

Each mandate carries a use count that is consumed at settlement, so a single-use mandate pays once.

# Sign a checkout mandate with your wallet
tenzro ap2 sign-mandate --kind checkout \
  --mandate-file checkout.json \
  --signer-did did:tenzro:human:<you> \
  --out checkout.vdc.json

# Check a payment mandate against its checkout mandate
tenzro ap2 validate-pair \
  --checkout-file checkout.vdc.json \
  --payment-file payment.vdc.json

# List the mandates agents currently hold under your DID
tenzro ap2 list-mandates --controller-did did:tenzro:human:<you>

The equivalent JSON-RPC methods are tenzro_ap2SignMandate, tenzro_ap2VerifyMandate, tenzro_ap2ValidateMandatePair and tenzro_listMandates. A wallet uses tenzro_listMandates to show a person which agents hold their consent, and with what limits.

Metered settlement

Most Machine Economy purchases are priced by use: tokens generated, GPU epochs, bytes stored. Per-use settlement is the default. The buyer authorises a ceiling once, the provider serves and meters, and only the amount used is captured, never more than the ceiling. For long-running work such as rentals and storage, payment is released per epoch against the chain's verdict on availability. See SLA attestation and metering.

Discovering what a node supports

These methods are open and need no signature:

curl -s https://rpc.tenzro.xyz -H 'content-type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tenzro_paymentGatewayInfo","params":[]}'

• tenzro_paymentGatewayInfo and tenzro_listPaymentProtocols: protocols, assets and settlement options.
• tenzro_listX402Schemes: x402 schemes the node verifies.
• tenzro_getPaymentReceipt: a receipt by id.

From the CLI: tenzro payment info, tenzro payment protocols and tenzro payment receipt.

Access classes

See RPC access.