Settlement

Settlement is how a payment for work becomes a balance change on the ledger. Tenzro Network settles every paid service the same way: the buyer pays from its balance, the provider earns into its own, and the payment is divided once between the operator and the network. The default is metered, per-use settlement: a buyer pays for what was delivered, when the chain agrees it was delivered.

This page covers the settlement modes, how rental and storage billing follow the chain's verdict, the revenue split, and how a payee chooses the asset it is paid in.

Choosing a mode

Every mode that moves money needs a signature from the paying account.

Immediate settlement

A single payment from a payer to a payee is an ordinary transfer, signed by the payer's hardware key and final when its block is:

tenzro wallet send 0xPAYEE 5 --asset TNZO

Work paid in legs, with a proof per leg, runs as a settlement plan: the payer opens the plan, each leg settles when its proof is accepted, and every leg leaves a receipt (tenzro settle open --plan plan.json, tenzro settle get --plan-id <PLAN_ID>, tenzro settle receipt --plan-id <PLAN_ID> --index 0).

Escrow

Escrow locks funds until a condition is met. CreateEscrow, ReleaseEscrow and RefundEscrow are native, signed transactions, so the vault transfer and the state change land in the same block.

• Funds sit in a vault address derived from the escrow id. Nobody holds a key to it.
• The creator is the signing payer; the node derives it from the signing key. Release and refund check the escrow's state and expiry.
• The release condition is one of timeout, provider, consumer, both, verifier, custom or stream.
• A stream escrow pays the payee a fixed rate for each elapsed epoch (--rate-per-epoch, --epoch-ms, an hour by default) until it expires or is refunded. Compute rentals and standby capacity are stream escrows.
• An escrow can carry a reference: an opaque 32-byte value the application that opens it chooses, such as the id of a task, an order or a session. The chain stores it and never interprets it, so an application finds its escrows again without the chain knowing what they are for.

tenzro escrow create --payee 0xPAYEE \
  --amount <wei> --expires-at <unix_ms> --release provider \
  --reference 0x<32-byte reference>
tenzro escrow get <escrow_id>
tenzro escrow release --payer 0xPAYER <escrow_id>
tenzro escrow refund --payer 0xPAYER <escrow_id>

Amounts for escrow are in wei: 1 TNZO is 10^18 wei. List escrows with tenzro escrow by-payer --payer <ADDRESS> and tenzro escrow by-payee --payee <ADDRESS> (tenzro_listEscrowsByPayer, tenzro_listEscrowsByPayee); each record carries its reference.

Payment channels

A payment channel lets two parties exchange many small payments with one on-chain open and one on-chain close. It suits per-token inference billing, where a request may produce thousands of tiny charges.

1. Open. The payer funds an escrow to the payee, then opens a channel over it; the channel id is the escrow id.
2. Pay. Each payment is a voucher the payer signs for the channel's new cumulative total. The node verifies each voucher against the one it replaces.
3. Close. The payer closes the channel and the final balances settle on-chain.

tenzro escrow create --payee 0xPAYEE --amount 10000000000000000000 --expires-at <unix_ms>
tenzro escrow open-channel --channel-id <ESCROW_ID>
tenzro escrow voucher <ESCROW_ID> --cumulative 1000000000000000 --charge 1000000000000000
tenzro escrow close-channel <ESCROW_ID>

If the parties disagree, the highest cumulative voucher the payer signed decides. See the disputes section of SLA attestation and metering.

Batch settlement

A batch groups many settlements into one atomic commit. If any settlement in the batch fails verification, the whole batch rolls back and no value moves. The network uses batches to aggregate high-volume metered charges, such as per-token inference billing, into a single commit.

Related tools on the same engine:

• Netting computes the minimal set of transfers that clears a set of mutual obligations, so parties who owe each other move only the difference.
• Delivery-versus-payment runs a multi-leg exchange as all-or-compensate: every leg completes, or every completed leg is reversed.

Both are operator tools (admin class).

Epoch billing on the chain's verdict

Compute rentals, compute claims and storage deals bill from funding the buyer commits before the term starts; each epoch the network checks the provider's proof and returns a verdict.

• Passed: one epoch's slice moves from the buyer's funded balance to the provider.
• Failed: nothing moves and the buyer keeps that slice.
• Closed: the unearned remainder returns to the buyer.

Accrued provider earnings persist across node restarts. See Compute rental.

The revenue split

A settled service payment is divided exactly once, by the serving node's economic mode, and nothing downstream takes a further cut.

• A private node, reached only by the callers its access policy names, keeps the whole payment. Nobody discovered it through the network and no validator worked on the caller's behalf.
• A public validating node pays a share to the network treasury.
• A public node that does not validate pays the treasury share and a share to the RPC provider that validates on its behalf. That leg pays for validation, not for brokering access.

The operator always keeps the majority. The shares sum exactly to the payment, with any rounding going to the operator. Every rate is set by governance as one policy; read the policy a node applies with:

tenzro governance economic-policy

The treasury share is not burned. It accumulates in the treasury and is spent only through governance. See Token economics.

Which asset a payee receives

A payee declares the asset it settles in. The default is to keep whatever asset arrived: a provider paid in a stablecoin keeps the stablecoin, because its costs are in dollars and converting would give it an exchange-rate position it did not ask for.

A payee who declared TNZO receives TNZO, or the payment is refused. Crediting the inbound stablecoin instead would hand the payee an asset it did not choose, silently. Refusing surfaces the mismatch while the payment can still be retried or the preference changed.

Setting the preference is self-service. It is authorised by a signature from the payee's own identity key, not by the node operator, so on a shared node the host cannot change how its tenants are paid.

SDK

import { TenzroClient } from "tenzro-sdk";

const client = new TenzroClient({ endpoint: "https://rpc.tenzro.com" });

const channelId = await client.settlement.openPaymentChannel("0xPAYEE", 10n * 10n ** 18n);
await client.settlement.closePaymentChannel(channelId);

Related

• Payments and Stablecoin payments for paying in stablecoins through Bridge.xyz wallets.
• SLA attestation and metering for how delivery is checked before it is paid.
• Token economics for fees, burn and the treasury.