> ## 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 — Network Traffic And Settlement

How B3IQ proves live routed work, keeps public stats moving, and batches payout settlement.

**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.


B3IQ production evidence comes from real requests: routed inference, streaming,
private process work, usage rows, receipts, public telemetry, and payout-batch
proofs.

**Operator runbook is internal**

Running the traffic warmer and the settlement operator is a secured-operator
  task with its own private runbook. This page describes the public-safe shape
  of how live work and settlement flow, not the operational commands,
  endpoints, or environment used to drive them.

## Latest observed evidence

The scheduled traffic warmer generates fresh routed work, and the settlement
scheduler finalizes the threshold batch. Live counts (accepted receipts and
finalized payout rows) are published on the
[public explorer](https://b3iq.org).

## Traffic warmer

A scheduled warmer rotates eligible node and model targets and sends a bounded
mix of routed inference probes against protocol-ready supply. Its job is to keep
public telemetry and receipts moving and to prove the end-to-end path
continuously. Operators do not need to run it: it is a protocol-operations
task.

## Settlement operator

The settlement network is an efficient public commitment layer, not one
transaction per request. The settlement policy batches payout rows and anchors a
root that commits the payout count and aggregate amount. Broadcasting a root
always requires explicit secured-operator confirmation.

## Worker cron boundary

Worker cron can snapshot public network stats and finalize already-submitted or
submitting payout batches when auto-finalize is enabled. It does **not** create
payout batches, hold the settlement private key, sign transactions, or broadcast
payout roots. Those actions stay with the secured local operator.

## Batching policy

Use threshold batches for normal operation:

- 25 to 100 payout rows for routine settlement.
- Singleton batches only for smoke tests, incident recovery, or final cleanup.
- Aggregate settlement logs for payout proofs first, then later receipt roots,
  reputation roots, capability roots, and challenge/dispute evidence roots.

**Public payloads stay minimal**

Public payloads must never include prompts, outputs, customer IDs, exact
  private routes, raw response bodies, local URLs, API keys, payout account keys,
  or raw request logs. Settlement commits only counts, aggregate amounts, and
  roots.

## Related

**[Receipts & settlement](/protocol/receipts-settlement)**

The protocol view of receipts, payout roots, and settlement commitments.
  **[Current status](/operations/current-status)**

Live pilot evidence and the open production gates.