Optimistic assurance and challenges

One settlement ledger, two assurance modes

Joint proof obtains the original execution proof or attestation before settlement. Optimistic first registers a bonded, context-bound claim; the original execution evidence is requested only if challenged. Both still require the financial proofs and canonical settlement checks of their chosen rail.

The shared state machine is in zkpi-optimistic, the canonical driver in zkpi-defmi-sdk, and policy, escrow and finality in the DeFMI VM. QOMM and OCLOB supply application-specific verifiers. A local timer or a screen label cannot authorize a transfer.

What a proposal must bind

A governance-approved policy fixes network, application, verifier identity, proposer, collateral asset, both bond amounts and time windows. A registered execution fixes job, input root, before-state and validity. The node accepts a signed admission for that execution, produces a signed result claim and records that proposal durably before reuse can occur.

The settlement reference binds the finalized claim to the exact authorized execution. Replacing policy, verifier, input snapshot or output digest must not preserve validity. The formula is a map of fields, not a wire encoding specification.

Canonical state transitions and exact deadlines

Invalid proof bytes are rejected; merely submitting invalid bytes does not immediately slash the proposer. A response can still arrive before its deadline. If that deadline expires, an advance transaction records rejection. Browser countdowns are estimates; canonical block time is authoritative.

Collateral is part of canonical state

The native VM moves the specified collateral asset into escrow and accounts separately for available, locked and penalized balances. Registering a numeric bond in a policy without funding escrow is insufficient. An unchallenged finalization releases the proposer bond; a valid answer applies the challenge policy’s penalty; an unanswered challenge applies the proposer penalty.

Browser demos explicitly use synthetic public-development collateral and public fixture keys. The observed waits are QOMM 20 seconds with a 30-second response window and OCLOB 30 seconds with a 45-second response window. They are policy parameters, not protocol-wide constants or economically calibrated security guarantees.

The original verifier determines the assurance

QOMM

The quote challenge adapter checks the original mathematical quote evidence bound to the committed quote execution. This is separate from the financial proofs retained for settlement.

OCLOB

The transition challenge adapter verifies the existing committee transition attestation. It is not a new zero-knowledge proof of every price/time-priority rule. Collaborative amount, price, product and residual proofs remain separate.

No challenge

Finality relies on the registered policy, bonded proposer and an active challenge opportunity. It does not retroactively become mathematical verification of the skipped evidence.

Follow the real browser path

1. Choose joint proof or optimistic while the service is idle. The server persists the selected mode.
2. Join the taker in QOMM, or choose a company in OCLOB, and submit an order.
3. In optimistic mode, read the provisional price or fills in the participant view. Funds and the private book remain uncommitted during the challenge window.
4. Optionally submit the challenge from the same screen. The button sends a canonical challenge transaction; it is not a simulated UI state.
5. Wait for claim finality and the subsequent native settlement receipt. Read the resulting portfolio and public book.

The OCLOB HTTP server no longer falls back to in-process settlement. Both modes use five native Avalanche validators. This change does not replace its coordinator input handling with the separate participant-side native-note API.

Demo roles are freely selectable projections, not authenticated access control. The OCLOB coordinator receives plaintext before encryption and splitting; seven processes share one host. Do not put real orders, assets or private identity material into this development UI.

Observed scope and recovery limits

These observations used integration working trees; publication of this guide does not establish deployment of a later source commit. On 2026-09-12, the QOMM browser submitted one unit at a limit of 159.07 and received 157.18, including a challenged optimistic run. In OCLOB, a sell order of 100 at 100 was followed by joint-proof buy 20, unchallenged optimistic buy 40 and challenged optimistic buy 20, each limited at 101 and filled at 100. The resulting buyer portfolio was 99,992,000 cash and 10,080 units. These are synthetic functional observations on the scoped native environment, not throughput, independent-operator or production-security acceptance.

OCLOB retains an encrypted outbox and canonical receipts, but this HTTP coordinator’s private book is process-local. Reusing its state directory is rejected; ambiguous native outcomes require reconciliation and cannot be blindly retried. Start a new isolated development network for a new browser session. This limit differs from the separate native node recovery implementation.

Implementation and evidence pointers

Inspect the exact policy and verifier deployed in your environment. The shared files below are the implementation authority; the browser guide records run commands and functional evidence.

• Canonical policy, claims and escrow state machine
• Node admission and quote challenge adapter
• Shared canonical client
• Native VM optimistic execution
• OCLOB integration working tree: rust/oclob-proofs/src/optimistic.rs
• OCLOB browser guide and evidence
• QOMM browser guide and evidence