> ## Documentation Index
> Fetch the complete documentation index at: https://docs.b3iq.org/llms.txt
> Use this file to discover all available pages before exploring further.

# Historical — Receipts And Settlement

Signed receipts, payout batches, settlement roots, payout proofs, and public-safe commitment boundaries.

**Historical pilot reference — retired October 3, 2026**

This page preserves earlier public protocol and request-payout pilot
  descriptions. It is not the current service contract, a current availability
  report, or instructions to restart a public serving pool. Public explorer
  pages and third-party provider fallback are retired. Historical records
  remain; owner inference is free and optional current earnings come from
  capacity rented by the hour. Read [current operating evidence](/protocol/overview)
  and [current status](/operations/current-status) first.


Receipts and settlement turn completed work into public-safe evidence without
publishing private payloads.

## Receipt commitments

Receipts can commit to:

- Node ID.
- Model ID.
- Usage totals.
- Payout rate references.
- Receipt hash.
- Receipt status.
- Optional attestation hash for future verified-confidential jobs.

Receipts must not publish raw prompts, model outputs, customer identity, API
keys, customer tokens, exact private routes, raw request logs, or raw TEE quotes.

## Payout batches

Payout batches aggregate node payout rows into a public-safe root. The batch can
include counts, total amount, merkle root, transaction hash, block reference,
status, and timestamps.

| Field | Public-safe? | Notes |
| --- | --- | --- |
| ` batch_id ` | Yes | Opaque batch identifier |
| ` payout_count ` | Yes | Number of payout rows included |
| ` total_amount_wei ` | Yes | Aggregate amount only |
| ` merkle_root ` | Yes | Commitment root, not raw private metadata |
| ` transaction_hash ` | Yes | Public settlement transaction reference |
| ` settlement_chain_id ` | Yes | Chain the transaction was broadcast to: pick the explorer from this, not the current network |
| ` customer_id ` | No | Keep customer identity out of public settlement payloads |
| ` prompt/output ` | No | Never include raw request or response content |

**Payouts are per machine, not per request**

A served request is metered and receipted; it does not itself pay the
  machine's owner. Owner earnings are a revenue share on what the machine makes
  under B3IQ's offtake arrangements, accrued to that machine's deal ledger and
  paid in USD. The payout ledger and its settled batches below are the durable,
  independently checkable record of what was paid.

## Current settlement pilot

The `B3IQSettlement` payout-proof reference emits canonical payout batch proof
logs on the settlement network. The control plane can finalize payout batches
from real settlement receipt evidence.

The public settlement surface publishes live counts: finalized payout batches
and rows, and accepted receipts. Pending rows are expected between settlement
batches.

## Verify a payout batch yourself

A receipt is only evidence if someone outside B3IQ can check it. Both networks
below are public, so a payout batch can be verified without asking us for
anything and without us being online.

| What | Network | Chain ID | Explorer |
| --- | --- | --- | --- |
| Node registry (B3IQRegistry) | Base mainnet | ` 8453 ` | ` base.blockscout.com ` |
| Payout proofs (B3IQSettlement), moving to Base | Base mainnet | ` 8453 ` | ` base.blockscout.com ` |
| Payout proofs settled before the move | B3 mainnet | ` 8333 ` | ` explorer.b3.fun ` |

Take the `transaction_hash` from a finalized payout batch, open it on the
explorer for that batch's own chain, and read the `PayoutBatchSettled` log. The
`merkle_root` in that log is the same root the batch published, so the aggregate
it commits to can be checked against the public counts without any private
payload being exposed.

Each batch carries its chain as `settlement_chain_id`, so the right explorer can
be picked from the batch itself rather than inferred from whichever network is
current. Match it against the table above.

Payout proofs are moving to Base mainnet. Batches settled before that cutover
  are on B3 mainnet and stay there. A payout batch records the chain it was
  broadcast to, so an older proof keeps pointing at the explorer where its
  transaction actually exists. Check a batch's own chain rather than assuming
  the current one; looking up a B3-era batch on Base finds nothing, because the
  transaction was never written there.

## Settlement flow

**Accept receipts**

Completed work submits signed receipt evidence to the control plane.
  **Record usage**

Settlement creates the immutable usage record for the work.
  **Batch payouts**

Pending payout rows are batched into a public-safe root with aggregate totals.
  **Submit proof**

The payout batch root is submitted to the settlement contract and emits a
    public proof log.
  **Finalize control-plane state**

The control plane verifies configured contract/event evidence before marking
    rows settled.

## Operator and cron boundary

Secured operator settlement can create, broadcast, submit, and finalize payout
batches from a local machine that holds the settlement key in ignored local env
or a secret manager. Worker cron can finalize already-submitted or submitting
batches when auto-finalize is enabled, but it does not hold the
private key, create batches, sign transactions, or broadcast payout roots.

Normal settlement should batch payout rows for efficiency. Singleton batches are
reserved for proof runs, incident recovery, or end-of-day cleanup.

## Roadmap

**Settlement roadmap**

**Payout proof pilot**

Payout proof deployment and real payout batch finalization exist.
  **Recurring operation**

Run the secured local settlement scheduler for batch creation, broadcast,
    submit, verify, finalize, and recovery paths while keeping Worker cron on
    no-key finalization only.
  **Additional roots**

Add receipt roots, availability roots, reputation snapshots, and epoch
    summaries after formats stabilize.