​
Verified model settlement

How signed settlement receipts decide whether a buyer is charged and a provider is credited.
A billed request settles only when the network can verify a signed settlement receipt from the provider. The receipt ties the request and response to the provider’s key and to the exact catalog model artifact the provider served. If the receipt is missing or invalid, the buyer is not charged and the provider earns nothing for that request.

​
The money path

The buyer charge is reservation-first. It becomes a final debit only once the request reaches verified.

​
Receipt deadline

A settlement receipt has to arrive before the pending deadline closes. The deadline is measured from when the request reached its terminal state, and the network default is 300 seconds. A request still pending at the deadline becomes quarantined: the buyer reservation is released and the provider gets zero credit. Late receipts do not settle and cannot be recovered. They cannot create provider credit, payout eligibility, or a new buyer charge. A healthy provider emits its receipt as part of completing the response, so the deadline is a backstop rather than something you plan around.

​
Receipt versions

Only v0.4 settlement receipts can create provider credit. v0.3 and older receipts are not settlement-capable, and traffic that carries only a legacy receipt settles as quarantined. Which kind a provider signs depends on whether the request was dispatched with a settlement snapshot. Fresh invite installs enable receipts. A buyer’s verifier version affects only the buyer’s own audit, never settlement. 1.0.x verifiers report v0.3 buyer receipts as invalid, and 1.1.0 cannot parse current v0.3 buyer receipts, so offline verification of current receipts is pending a verifier update.

​
Checking a request’s settlement

Buyers can look up metadata-only receipt status for their own requests:
The response contains hashes and the settlement outcome, never prompt or completion text. It returns 401 without a key and 403 for another buyer’s request or for a demo key.

​
Why this matters

  • Buyer safety. A buyer’s charge only becomes final once a signed receipt ties the response to a catalog model on an identified provider.
  • Provider incentives. A provider that skips signing, tampers with the tuple, or serves weights that don’t match the catalog earns nothing for that request.
  • Ledger integrity. Provider credits come from verified receipts, not raw request counts.

​
Recent reliability changes

  • If the settlement-evidence database write hits its deadline after the provider credit has already been recorded, the buyer now receives the completed response instead of an HTTP 500. The write is retried.
  • The gateway now reconciles settlement holds promptly, and holds that were already verified are recovered instead of left pending.