Settlement

Settlement is how a payment for work becomes a balance change on the ledger. Tenzro Network 1 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, with the service proof checked inline where one is supplied: a TEE attestation or a Plonky3 STARK proof.

tenzro escrow settle --payer 0xPAYER --payee 0xPAYEE --amount 5
tenzro escrow get-settlement <settlement_id>

--amount on settle is in whole TNZO.

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 must be the signing payer. Release and refund check the escrow's state and expiry.
• The release condition is one of timeout, provider, consumer, both, verifier or custom.

tenzro escrow create --payer 0xPAYER --payee 0xPAYEE \
  --amount <wei> --expires-at <unix_ms> --release provider
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_listEscrowsByPayer and tenzro_listEscrowsByPayee.

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 deposits into the channel.
2. Update. Each payment is a new channel state, nonce, payer balance and payee balance, signed by the payer. The node verifies each update against the state it replaces.
3. Close. Either party closes the channel and the final balances settle on-chain.

tenzro escrow open-channel --counterparty 0xPAYEE --deposit 10
tenzro escrow close-channel <channel_id>

If the parties disagree, either one submits the highest-nonce state the other signed. The settlement engine decides by nonce and signature validity. 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).

Prepaid streams and billing on the chain's verdict

Compute rentals, compute claims and storage deals bill from a prepaid balance. The buyer deposits once; each epoch the network checks the provider's proof and returns a verdict.

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

tenzro escrow prepaid-deposit --renter 0xRENTER --amount <wei>
tenzro escrow prepaid-balance --renter 0xRENTER
tenzro escrow prepaid-withdraw --renter 0xRENTER --amount <wei>

Prepaid balances and any 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 through the API keys and service keys its operator issues, 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.xyz" });

const channelId = await client.settlement.openPaymentChannel("0xPAYEE", 10n * 10n ** 18n);
const balance = await client.settlement.prepaidBalance("0xRENTER");
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.