Settlement.

One-shot settlements with cryptographic proof verification (Plonky3 STARKs, TEE attestations). The network share follows the node's economic mode.

BatchProcessor atomically processes multiple settlements with rollback on failure.

MicropaymentChannelManager handles off-chain per-token billing with Ed25519-signed state updates. Channel signature hardening verifies against ChannelState::canonical_message().

The revenue split routes the treasury leg to the treasury; the settlement engine takes no further fee. Producer rewards are paid in TNZO.

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 — connected but not advertising itself, reached through the API keys and service keys its operator issues — keeps the whole payment: nobody discovered it and no validator was engaged on the caller's behalf. A public validating node pays 10% to the treasury. A public node that does not validate pays 10% to the treasury and 10% to the RPC provider validating on its behalf.

The operator's majority is enforced at construction, not merely documented, and against governance too. The shares sum to exactly the payment, with rounding dust going to the operator by subtraction.

That RPC-provider leg pays for validation performed on this node's behalf, and comes out of the operator's share because the node is buying validation it does not perform. It is not payment for brokering external networks — an RPC provider bills their own tenants for that, the way every other chain's RPC operators do. Charging in both places would be charging twice for two different things. Every rate is one governance-set policy block.

A payee declares what they settle in, and it is theirs to declare. The default is to keep whatever asset arrived: a provider earning USDC generally wants spendable USDC, since their costs are denominated in dollars and converting to TNZO would hand them an FX position they did not ask for.

A payee who declared TNZO gets TNZO or the payment is refused. Quietly crediting them the inbound stablecoin instead would give them an asset they did not choose, and the discrepancy would be silent exactly where it matters. Refusing surfaces it while the payment can still be retried or the preference changed.

Setting the preference is permissionless and self-service: it is authorized by a signature from the payee's own identity key over a domain-separated preimage, not by the node operator's admin token. A settlement preference belongs to the payee, and on a shared node the host must not be able to change how their tenants get paid.

tenzro_setSettlementPreference   # signed by the payee's identity key
tenzro_getSettlementPreference