More than a transaction, less than a chain

CORE MODEL

zkdeal: more than a transaction, less than a chain

A guide to zkdeal's room model, capital path and relationship to the proving stacks used by ZK-based Ethereum L2s

Thesis: Most L2s prove a continuing shared chain. zkdeal proves one bounded room. An application chooses an allowed room profile; zkdeal binds that profile at room opening and proves each accepted checkpoint against it. The difference is lifecycle and settlement design, not a new cryptographic primitive.

Explore the architecture

Room anatomy: the app chooses; zkDeal pins and proves

Pan · zoom · select a node

Chosen for the room

• authorization + data route
• one-shot, rolling or sparse rhythm
• participants, assets + clocks
• proof template + app policy

Room-local EVM

• signed room transactions
• consumed deposits credit beneficiary
• policy-bounded calls + storage
• controlled liabilities + exit queue

Checkpoint + proof

• roots + ordered-data cursors
• withdrawal root (<=32,768 leaves)
• deposit-specific refund deadline
• selected close + exit behavior

Signed intent

Room block

2–4-block batch

Accepted L1 checkpoint

Ethereum finality

Validity-room boundary

Once a validity room is selected, the proof must authorize every checkpoint and bind an exit route.

Deployment profile

A Stage-oriented deployment admits validity + Ethereum-data rooms; other profiles remain separate choices.

React Flow

Press enter or space to select a node. You can then use the arrow keys to move the node around. Press delete to remove it and escape to cancel.

Press enter or space to select an edge. You can then press delete to remove it or escape to cancel.

Drag the canvas to pan, use the wheel or pinch gesture to zoom, and use the controls to zoom or fit the whole model. Expand for a page-sized view; press Escape to close it.

View the static reference image

Read the figure transcript

Room anatomy. The application chooses an allowed authorization mode, data route, lifecycle, proof template, participants, assets, clocks and application policy. zkdeal binds those choices when the room opens and verifies each accepted checkpoint against them. On the L1-funded validity path, consumed deposits credit their named beneficiaries before application execution and every room binds an exit route. The timing hierarchy is signed intent, room block, batch, accepted L1 checkpoint and Ethereum finality.

The five-stage time ladder and core vocabulary

Room: A room is an isolated EVM workflow with its own policy, assets, membership state and proof program. It has a deliberate close instead of running as one shared, always-on chain.

Settlement sequence: A signed intent enters a room block, and room blocks form a batch. The proof and journal turn that batch into an accepted L1 checkpoint. Ethereum finality makes the checkpoint canonical; until then, the room result remains provisional.

Authorization, membership and checkpoint rhythm

Joint-consent rail: An application may choose unanimous approvers for a small jointly controlled room. Every active approver signs the same checkpoint journal, and participants keep the replay data. This is a deliberate consent-room option rather than the standard rollup Stage path.

Stage-oriented validity rail: An application may choose validity-only settlement with Ethereum calldata. Customers sign room transactions; the bound proof checks input and execution, while exact genesis data, deposits and forced inputs remain reconstructable from L1. The rollup-oriented deployment enforces this combination for every room it admits.

One-shot, rolling and sparse: A one-shot room closes at its first checkpoint; a rolling room checkpoints repeatedly; a sparse room waits longer. Sparse timing can amortize per-checkpoint submission overhead, but it also extends the rollback and operator-dependency window.

What the proof establishes—and what it does not

Where the architecture is useful

Best fit: Choose a room when a high-value workflow has a clear beginning and end—for example, a deal, auction, game, fund episode or controlled settlement—and needs its own provable market rule and room-scoped L1 accounting.

Complementary fit: A persistent L2 remains the natural home for always-on composability, shared liquidity and broad wallet, RPC and indexer support. zkdeal can handle a bounded episode that begins in, returns to or coordinates with that wider market.

Use a continuing chain when: the application needs unrestricted contracts, permissionless entry, live cross-application composability or sustained chain-wide throughput during the episode. The eight-room recursive limit applies to one aggregate receipt; it is not a concurrency limit.