From a one-checkpoint clear to an eight-hour market

MARKET ROOMS IN PRACTICE

From a one-checkpoint clear to an eight-hour market

Why use a room? A room lets a market episode end: the application pins its inputs, rule and close. Reading the figure: The 1–8-hour window is an application target, not a proof deadline. The figure separates room choices from proof-enforced accounting and Ethereum finality. Depositors name the beneficiary; the application chooses clocks, cadence and exit allocation; and the validity proof makes consumed funding canonical for that beneficiary.

A one-to-eight-hour room diagram with three lanes. The application chooses assets, beneficiaries, admission window, checkpoint rhythm, market rule and exit allocation. New capital is queued in the L1 RoomVault, waits for its L1 block to finalize and, if consumed, is credited by the proof before application execution. An unconsumed deposit becomes refundable after its deposit-specific onchain deadline. A validity room can create an L1 withdrawal root through an exit record or terminal sweep. Independent tooling can rebuild the calldata room from Ethereum data, prove, submit and claim if the hosted service stops. — Interactive architecture diagram.

Worked target: a four-hour power auction

Capacity envelope: The application selects a power-of-two participant capacity from 128 to 32,768, constrained by the number of supported assets and the withdrawal-tree limit. Unanimous mode caps approvers at 256. On the open deployment rail, one recursive receipt may aggregate 1–8 rooms; the Stage-oriented calldata rail disables aggregation so each accepted root uses its room-pinned proof.

Three useful room patterns

Room pattern	What the application pins	Why it helps
Sealed RFQ / call auction one terminal block or 2–4-block burst	The application prefunds cash or inventory and pins the cutoff, signed price and size fields, nonce, expiry, clearing rule and exit-record behavior.	Once the room has a client's signed intent and the proof has credited finalized funds to that beneficiary, the client may disconnect. The pinned fallback states whether low volume causes a partial clear, deferral or no trade.
Protected market round repeated 2–4-block batches	The application pins commit and reveal deadlines, the eligible set, an exposure cap and the execution rule. A commit-reveal AMM shows how sealing the set can block reactive insertion.	Once the eligible set is sealed, a batch or uniform-price rule can remove arrival order from price formation. The application must separately encode any liquidity-provider lock, notice period or reserve floor.
Commercial session 1–8 hours	The application pins eligible commodity, freight, power or warehouse lots; escrow rules; L1-block deadlines; checkpoint cadence; exit allocation and terminal DvP close.	A validity-only checkpoint may publish claims before close; a terminal proof can sweep code-free residual accounts. Legal title and delivery still wait for finalized L1 facts and accepted attestations.

Sparse-mode mapping: Choose sparse checkpoint timing only when participants accept a longer provisional window. Between checkpoints, results can roll back. Recovery starts from the latest L1-finalized checkpoint. On the Stage-oriented validity rail, a replacement prover advances or closes the room through the ordinary proof-bearing path; a live all-services-off exercise remains qualification evidence.

How the room fails closed

Failure mode	Fail-closed room response
An L1 branch changes	The operator should treat the room opening, each deposit or import, and every checkpoint as provisional until Ethereum's finalized tag covers the exact L1 block hash; confirmation depth is not finality. A production host should verify the tag and hash through two providers and fail closed on disagreement. The operator should retain proof and calldata; a changed branch or deadline requires re-proving.
Liquidity vanishes before seal	A quote is not capital. The application requires finalized funding, and each deposit names its beneficiary. If the proof never consumes it, the depositor can reclaim the gross amount after that deposit's onchain deadline. Once consumed, the proof credits the beneficiary and can move controlled value to an L1 claim.
The client disconnects after seal	After the operator durably records the signed transaction, its receipt survives a disconnect. A receipt promises a SUCCEEDED, REVERTED or REJECTED outcome by an L1-block deadline and gives finite omission recourse; it does not by itself guarantee proof, finality, payment or notional coverage. Proof-enforced beneficiary credit supplies the payment link.
The operator or prover stalls	Admissible forced transactions are injected before seal. Each must execute, revert or receive a proof-derived rejection; once an unresolved request is overdue, room progress stops. For calldata rooms using the Ethereum state commitment, independent tooling rebuilds genesis, deposits, imports and batches from L1, then composes, proves, submits and claims. A recorded all-services-off exercise remains a deployment qualification gate.

Physical release is a separate finality gate

Finality state	Permitted external effect
Room result	Fast and provisional. The app may quote or simulate, but should keep positions capped and rollbackable.
L1 accepted	Proof-backed, but the accepting Ethereum block can still reorg. Payment, title and physical delivery remain pending.
Ethereum finalized	The provider may act when the finalized checkpoint proves both the application transaction and the proof-enforced beneficiary credit.

Motivational example

Choose a room clock that matches the episode

An auction that collects orders and clears once should not be operated like a shop that stays open all day. The first wants one admission window, one clear, one checkpoint, and a close. The second wants progressive checkpoints, restart safety, and an explicit terminal condition later.

Both can use the same proving and settlement machinery. What changes is the room policy and the way you operate it. Making that choice up front keeps a one-shot market from accumulating needless infrastructure, and keeps a long-running room from pretending that one final checkpoint is enough for every user.

Deploy a one-checkpoint room for a single clear and close it deliberately.
Finalize a checkpoint in a continuing room and show that it reopens for the next action set.
Compare their lifecycle evidence, not only the time printed on a configuration file.

Demo / use it today

Deploy one-checkpoint and long-running rooms

Use the running local deployment to open two independent rooms: a one-clear auction and a persistent shop. Drive the auction through one checkpoint and an explicit close; then finalize two successive shop checkpoints and show that the same room reopens cleanly again.

Before you start

A Bash-compatible shell: Linux, macOS, or WSL on Windows. The copyable commands use POSIX shell syntax.
The complete local enclave from the Kurtosis walkthrough, already reporting READY.
Node.js for the small API driver.
Enough GPU time for the rooms’ template and checkpoint proofs; run the proof work sequentially on one GPU.

Keep the infrastructure constant
Create both rooms through the same coordinator and prover. Select the auction and shop presets so the comparison changes application lifecycle, not hardware or proof backend.
Deploy and observe the one-shot room
Post the auction actions, accept one L1 checkpoint, and close the room. The important evidence is that a later application action is refused because this episode is deliberately over.
Deploy and observe the continuing room
Post the first shop action set, accept and finalize checkpoint one, then post and prove the continuation as checkpoint two. The driver requires accepted sequences [1,2], no pending actions, and a room that reopens again while the closed auction refuses later work.

Download the small public API driver

umask 077 && SCRIPT_DIR="$(mktemp -d)" && \
  SCRIPT="$SCRIPT_DIR/compare-room-lifecycles.mjs" && \
  trap 'rm -r -- "$SCRIPT_DIR"' EXIT && \
  curl -fsS https://zkdeal.org/blog/tutorials/compare-room-lifecycles.mjs -o "$SCRIPT"

Verify the exact driver before running it

printf '%s  %s\n' bcc7bb3d89a0d2af3fafa43c69f54b46277f84216fa386d0c7dd12f95debcc00 "$SCRIPT" | \
  sha256sum --check --status && printf '%s\n' 'lifecycle driver: OK'

Expected output shape

lifecycle driver: OK

Require the same ready deployment

API=http://127.0.0.1:3100 && \
  test "$(curl -fsS "$API/demo/v1/system" | jq -r .decision)" = READY

Close one room and prove two checkpoints for the other

node "$SCRIPT" "$API" | jq -e -c \
  'select(.decision == "ROOM_LIFECYCLES_COMPARED" and \
    .oneShot.checkpoints == 1 and .oneShot.phase == "CLOSED" and \
    .oneShot.laterActionRejected == true and \
    .longRunning.checkpoints == 2 and \
    .longRunning.checkpointSequences == [1,2] and \
    .longRunning.phase == "L1_FINALIZED" and \
    .longRunning.reopenedAfterSecondCheckpoint == true and \
    .longRunning.pendingActions == 0)'

Expected output shape

{"decision":"ROOM_LIFECYCLES_COMPARED","oneShot":{"preset":"auction","checkpoints":1,"phase":"CLOSED","laterActionRejected":true},"longRunning":{"preset":"shop","checkpoints":2,"checkpointSequences":[1,2],"phase":"L1_FINALIZED","reopenedAfterSecondCheckpoint":true,"pendingActions":0}}

Remove the downloaded driver

rm -r -- "$SCRIPT_DIR" && trap - EXIT && unset SCRIPT_DIR SCRIPT API

What this gives you: You get two concrete operating profiles on one stack: the auction is closed after its single clear, while the shop has two accepted checkpoints and is ready to collect a third action set.

Interactive validated I/O

Compare one-shot and continuing room lifecycles

Validated on the B200 host

Select text directly in the player, pause at any point, or copy the complete transcript below.

Copy or read the complete transcript

Plain text Asciicast v3 VHS tape

$ umask 077 && SCRIPT_DIR="$(mktemp -d)" && \
>   SCRIPT="$SCRIPT_DIR/compare-room-lifecycles.mjs" && \
>   trap 'rm -r -- "$SCRIPT_DIR"' EXIT && \
>   curl -fsS https://zkdeal.org/blog/tutorials/compare-room-lifecycles.mjs -o "$SCRIPT"
$ printf '%s  %s\n' bcc7bb3d89a0d2af3fafa43c69f54b46277f84216fa386d0c7dd12f95debcc00 "$SCRIPT" | \
>   sha256sum --check --status && printf '%s\n' 'lifecycle driver: OK'
lifecycle driver: OK
$ API=http://127.0.0.1:3100 && \
>   test "$(curl -fsS "$API/demo/v1/system" | jq -r .decision)" = READY
$ node "$SCRIPT" "$API" | jq -e -c \
>   'select(.decision == "ROOM_LIFECYCLES_COMPARED" and \
>     .oneShot.checkpoints == 1 and .oneShot.phase == "CLOSED" and \
>     .oneShot.laterActionRejected == true and \
>     .longRunning.checkpoints == 2 and \
>     .longRunning.checkpointSequences == [1,2] and \
>     .longRunning.phase == "L1_FINALIZED" and \
>     .longRunning.reopenedAfterSecondCheckpoint == true and \
>     .longRunning.pendingActions == 0)'
{"decision":"ROOM_LIFECYCLES_COMPARED","oneShot":{"preset":"auction","checkpoints":1,"phase":"CLOSED","laterActionRejected":true},"longRunning":{"preset":"shop","checkpoints":2,"checkpointSequences":[1,2],"phase":"L1_FINALIZED","reopenedAfterSecondCheckpoint":true,"pendingActions":0}}
$ rm -r -- "$SCRIPT_DIR" && trap - EXIT && unset SCRIPT_DIR SCRIPT API

Video fallback generated with VHS 0.11.0

Pinned public inputs

Repositories and images used here

Public availability is not one license claim: protocol, examples, and testing are MIT; node, prover, and coordinator are public source under BUSL-1.1.

Explore public repositories Browse Docker images