Payments

Payments on Tenzro Network 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.com, without an access token.
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 a DPoP-bound access token or payment per request over HTTP 402. See OpenAI-compatible APIs and RPC access.

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 terms set by the human or organisation that controls them. The terms are recorded in consensus and 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.

The controller sets and changes an agent's terms with its passkey approval (tenzro_updateAgentTerms); read them back with tenzro agent terms --agent-did <DID>. See Agents.

On-chain, every node enforces the same limits from the agent's Terms in consensus state. See Agents.

Signed payment credentials

A payment over MPP or x402 is a credential the payer signs in answer to a challenge. The challenge names the resource, amount, asset and payee; the credential names the challenge it answers and is signed by the paying account's hardware key; the payee verifies it before serving.

# Payee: issue a challenge for a resource
tenzro payment challenge /v1/chat/completions --amount 50000 --asset USDC --protocol x402 \
  --recipient did:tenzro:human:<payee> > challenge.json

# Payer: sign and pay it, never more than the ceiling
tenzro payment pay --challenge @challenge.json --max-amount 50000

# Payee: verify a credential it received
tenzro payment verify --credential "$(cat credential.json)"

The JSON-RPC methods are tenzro_createPaymentChallenge, tenzro_payMpp, tenzro_payX402 and tenzro_verifyPayment.

Card networks

Agents can also pay on card rails. Visa Trusted Agent Protocol verifies the agent with HTTP message signatures (RFC 9421), and Mastercard Agent Pay with agentic tokens bound to a know-your-agent credential:

tenzro payment visa-tap https://merchant.example/checkout --amount 1999
tenzro payment mastercard https://merchant.example/checkout --amount 1999

The JSON-RPC methods are tenzro_payVisaTap and tenzro_payMastercard. Both count against the agent's terms like any other payment.

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 hour by hour against the validators' 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.com -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.

From the CLI: tenzro payment info, tenzro payment protocols and tenzro x402 list-schemes.

Access classes

See RPC access.