Fills & deadlines

A fill is one unit of delivered work, and it lives on a clock made of block heights — derived from the book's SLA tier, never from anyone's wall clock. Before liability starts, a miss refunds. After it, a miss slashes.

The timeline

1 · authorized	the fill exists — every deadline below derives from this height or from liability start
2 · activation deadline	the payload must go live by here: provider ack (soft) or a validator data-availability certificate (hard). Missed → the fill never activates; refund or rematch, no slash — liability never started
3 · liability starts	the height the provider becomes accountable: their ack under soft activation, the DA certificate under hard
4 · ack deadline (hard only)	after DA activation the provider must ack, validly reject, or complete by here — silence past it is slashable
5 · completion deadline	the work must be done. This is the one deadline a deadline-miss challenge can cite — miss it and the slash path opens
6 · receipt deadline	valid settlement evidence must land by here — no evidence, no payment, and the fill is exposed to fault close
7 · challenge window	opens when evidence lands: anyone may challenge it until here. The provider's payment is held back until every challenge resolves
8 · acceptance window (user-accept only)	the user must sign acceptance by here — or the fill refunds, the provider goes unpaid, and nobody's reputation moves

The challenge and acceptance windows both open when evidence lands, and run in parallel. All of these heights are visible on every fill via the read API — the deadlines are data, not promises.

SLA tiers are the only clock

Each book names an SLA tier, and the tier is a list of block-count windows — activation, ack, completion, receipt, challenge, acceptance. Those numbers are the only input to every deadline above. A first-token-latency target exists in the tier as a reputation signal, but it is never slashable: no slash on this protocol can derive from a relay's, provider's, or client's clock.

How a payload activates

SOFT_PROVIDER_ACK	payload travels off-chain; the provider is liable only after signing an ack. No ack → refund and reputation damage, but no slash — liability never began
HARD_DA_ACTIVATED	the encrypted payload goes to validator data availability; a quorum certificate activates it on-chain. From that height the provider is liable — silence becomes slashable

A provider can reject an activated payload only with a signed reason from a fixed set (decryption failed, commitment mismatch, token limit, malformed, unsupported parameters, policy violation) — and a fraudulent rejection is itself challengeable.

How delivery settles

USER_ACCEPT_ONLY	output goes to the user off-chain; only the user's signature settles it. Refusing costs the provider the sale, not their bond
DELEGATED_ACCEPTANCE	a user-authorized delegate signs acceptance — scoped by model, provider, amount, and expiry. The recommended path for API traffic
PUBLIC_OUTPUT_DA	the provider posts plaintext output to validator data availability — objective proof, no acceptance step, and the only mode where missing delivery is directly challengeable
OPTIMISTIC_NO_ACCEPTANCE	settles with no acceptance at all — explicitly the weakest mode, bounded only by the challenge window and the provider's bond

The refusal path is honest by design: under user-accept, a fill with valid evidence and no acceptance ends refunded — escrow back to the buyer, provider unpaid, bond released, no reputation change on either side, no relay fee. Buyer refusal is a priced risk, not a punished fault.

Fill statuses

AUTHORIZED → ACTIVATED → SETTLED | REFUNDED_UNACCEPTED | SLASHED — the last three are terminal. The replay trace on The protocol shows one fill reaching SETTLED and its sibling reaching SLASHED, with the money consequences of each.