Receipts And Settlement
Signed receipts, payout batches, settlement roots, payout proofs, and public-safe commitment boundaries.
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 |
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
Payout proof deployment and real payout batch finalization exist.
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.
Add receipt roots, availability roots, reputation snapshots, and epoch summaries after formats stabilize.