Proof-backed rooms for Ethereum

More than a transaction.
Less than a chain.

Run a bounded, multi-step workflow as one provable episode, then checkpoint the verified result to Ethereum—without moving the whole application to another chain.

Review a workflowWatch the room lifecycle

v5 active protocol surface17,902 / 17,902 applicable Osaka cases21.2–22.3 s application proofs on RTX 4090

Starting state

Ethereum inputs

Escrow + authenticated state

Bounded execution room

fixed policy · fixed deadline

  1. Commit

  2. Import

  3. Execute

  4. Prove

Several room-local blocks remain provisional until one proof binds the complete result.

One exit

Verified result

Ethereum checkpoint

Compare the exposure

One transaction is too small. A permanent chain is too much.

Drag the handle to compare an ordinary multi-transaction delivery-versus-payment flow with one bounded zkdeel room.

Ordinary transactions

  1. 1

    Party A acts

    Asset leg submitted

  2. 2

    Market keeps moving

    Price +0.8%

  3. 3

    Party B acts later

    Second transaction

  4. 4

    Partial completion

    Recovery required

zkdeel room

  1. 1

    Both parties commit

    Roster + policy fixed

  2. 2

    Assets lock

    Starting state fixed

  3. 3

    Steps execute together

    One bounded episode

  4. 4

    Verified allocation

    Claimable after proof

A room is bounded

Participants, permitted inputs, ordered work and a deadline are committed first.

Many steps, one episode

Intermediate blocks stay provisional until one proof binds the combined result.

No half-finished settlement

Without an accepted proof, Ethereum remains at the latest verified checkpoint.

For operators coordinating high-value onchain workflows

OTC and treasury operations

“Several counterparties, approvals, and asset movements must produce one acceptable outcome.”

Marketplaces and allocation platforms

“Several counterparties, approvals, and asset movements must produce one acceptable outcome.”

Custody and settlement providers

“Several counterparties, approvals, and asset movements must produce one acceptable outcome.”

These are proposed interview audiences, not customers.

The room lifecycle

A long-lived room with repeatable Ethereum checkpoints

Select any of the five stages, or press play. Room-local work stays provisional until a proof advances the Ethereum recovery point; the room can then continue.

Execution room

Boundary fixed

Room terms committed

01/05

Ethereum

Source

import
Bounded room
RM-2048
Participants

Treasury A + Custodian B

Deadline

30 minutes

USDC250k
WETH100
Ordered room blocks
Match
Price check
Allocate

Proof receipt

0x7bd2…e119 · batch 003

exit

Ethereum

Awaiting

2 participants · DvP policy · 30 min deadline

Room economics

Compute is the floor. Captured settlement flow is the upside.

The operating model is deliberately narrow: charge about $2 to allocate a room, about $4 for each active GPU-hour, and up to 1% only on capital or matched settlements that actually pass through zkdeel-controlled contracts.

Allocate

$2/ room start

Predeployed contracts plus the selected accounts and state variables. This assumes the provisioning path is automated.

Run

$4/ active GPU-hour

Metered while a room uses proving capacity. Idle rooms should not carry an always-on GPU bill.

Settle

up to 1%× captured flow

Feasible only for transfers or matched settlements routed through a zkdeel adapter, escrow, vault or settlement contract.

Fee boundary: a rollup does not make arbitrary token transfers taxable. A 1% entry or exit fee can live in the relevant bridge, vault or adapter; a 1% fee on gross trading notional requires every matched settlement to route through fee logic.

Change the assumptions

Selected case

Capital movement only

Fee revenue = gross room volume × fee-bearing capture × 1%

6.3% captured
Fee-bearing flow

$937.5K

Per room / year

Flow fee

$9.4K

Per room / year

Runtime revenue

$8.8K

Per room / year

Portfolio revenue

$18.1M

999 rooms / year

Revenue mix

Flow fee revenue$9.4M
Active GPU-hours$8.8M
Room allocations$2.0K
Total modeled revenue$18.1M

Contribution bridge

Modeled revenue$18.1M
GPU supply cost−$1.8M
Fixed cost−$3.0M
Before other COGS$13.4M

$100M contribution hurdle

$153.7Mgross volume / room

Uses the selected room count, capture ratio, active hours, GPU supply cost and fixed cost. It still excludes gas, support, security, failed work and reserves.

Runtime unit economics

80%gross margin

Customer price$4.00 / h
GPU supply cost$0.80 / h
ROI on supply cost400%

A 400% ROI on cost requires all-in GPU supply at or below $0.80/hour. At $1/hour, the runtime layer is 75% gross margin and 300% ROI on cost.

Proof-capacity boundary

63.26 smeasured

HardwareRTX 4090
Card-room default120 s
Allocation price$2.00

The six-move hidden-card checkpoint was slower than the 17.23-second startup canary. Cloud overflow remains a variable-cost fallback, not proof of a fixed margin.

Room-volume sensitivity

Capital-only is the baseline. Every-trade capture is a separate product gate.

Room classGross volumeCapital-like flow1% capital-only fee1% every-trade fee
Long-tail$1.0M$62.5K$625.0$10.0K
Portfolio baseline$15.0M$937.5K$9.4K$150.0K
Strong$50.0M$3.1M$31.3K$500.0K
Blockbuster / fast$200.0M$12.5M$125.0K$2.0M

6.25% is a proxy

The ratio comes from monthly trading volume divided by open interest. It is not measured deposit, withdrawal or unique-capital flow.

$15M is an equal-weight average

Kalshi’s weekly volume and market count imply roughly $14.9M annual gross volume per market. The median is likely materially lower.

1% of handle is meaningful

Against 2025 US sportsbook economics, a 1% handle fee would consume close to a tenth of gross gaming revenue.

Market inputs: Kalshi reported more than $1B weekly volume across more than 3,500 markets; Pew reported roughly $24B combined Kalshi and Polymarket monthly volume in April 2026; FalconX reported $12.8B January volume against about $800M combined open interest. The 16× ratio is used only as a rough capital-turnover proxy.

KalshiPew ResearchFalconXAGAERC-7540ERC-4626Vault fee exampleOP bridgeOn-chain settlement

Failure is part of the design

See exactly what stops—and what keeps moving

Choose a room type, then a concrete case. Provisional work never silently becomes Ethereum state, and closing a browser is not the same as closing a room.

1. Choose a room type

2. Choose a case

Illustrative escrowed payment room

Candidate batch from the last verified checkpoint

Recovery path

Deadline rule in this example

Ethereum block #23,456,789

Must the user stay online?

No. A user who already deposited and authorized the action does not need to keep the page open.

  1. Last verified checkpoint

    Durable on Ethereum

  2. 01

    Import

    Provisional

  3. 02

    Execute

    Provisional

  4. 03

    Prove

    Stopped here

  5. 04

    Candidate checkpoint

    Not accepted

Usable state remains at the last verified checkpoint

The late candidate never becomes Ethereum state

This example commits Ethereum block #23,456,789 as the proof deadline. A submission in a later block is rejected even if its computation is otherwise correct.

What happens next

The provisional batch is discarded. The room remains at its last verified checkpoint, then its policy either starts a fresh batch from that state or permits a recovery close and claims.

A deadline is a rule committed when the room opens. These examples use an Ethereum block number; another reviewed room adapter may commit a different explicit time rule.

Who progresses state after a user disconnects?

Closing the page does not close the room

The browser submits actions and displays status; it is not the execution engine. Progress continues through explicit services and ends only when Ethereum accepts a checkpoint or the room policy closes or recovers the room.

  1. 01

    User or delegated agent

    Deposits, signs, or submits the required authorized action.

  2. 02

    Room service

    Collects authorized actions and orders provisional room blocks.

  3. 03

    Prover and relayer

    Builds the proof and submits the candidate checkpoint to Ethereum.

  4. 04

    Ethereum contract

    Checks the proof, authorization, ordering, and deadline before accepting state.

A user must come back only when the selected policy needs another authorization, or to inspect, claim, withdraw, or participate in a recovery close. Exact liveness and recovery duties remain part of the reviewed room policy and adapter.

A focused protocol boundary—not another chain to operate

Reviewed room policy

Participants, authorization, permitted inputs, calls, deadline and terminal rule.

Authenticated Ethereum inputs

Escrowed assets and narrowly mapped account or storage proofs enter the room.

Room-local EVM execution

Ordered work advances a long-lived room while intermediate progress stays provisional.

Proof, checkpoint, continue

An accepted proof advances Ethereum state; users can claim outputs while the room continues. Rejected work leaves the last checkpoint usable.

Precise guarantees, explicit boundaries

What an accepted proof binds

  • Starting state
  • Ordered batch
  • Resulting state
  • Authorization mode and signed actions
  • Inputs, outputs and liabilities
  • Deadline and terminal property

What zkdeel does not claim

  • It is not a general-purpose L2.
  • It does not write arbitrarily into unrelated contracts.
  • A provisional room block is not Ethereum-final.
  • Longer checkpoint intervals increase the amount of provisional progress at risk.
  • Adapter and application-policy correctness still require review.
  • A complete repeated real-proof lifecycle is not yet demonstrated.

Map your workflow

Sketch a room before discussing the protocol

Choose the boundary, authorization and terminal outcome. The diagram assembles as you go; it is an interview aid, not an automated technical qualification.

01Who is inside?2 known participants
2 parties8 parties
02What enters the room?Select authenticated starting inputs
03How is work authorized?Every active approver signs the exact batch.

Exploratory room map

Draft RM-WORKFLOW

2 participants
Known room roster
1 hour

Authenticated inputs

ERC-20 escrow

Ordered episode

Step 1
Step 2
Step 3
Authorization

Unanimous approvers

Terminal property

Both asset legs allocate exactly

Proof + accepted checkpoint

Ethereum checkpoint

Verified terminal result

This workflow appears bounded because it has 2 known participants, 1 named input type, 3 finite ordered steps, a 1 hour deadline and a precise terminal property.

This is a prompt for review, not a claim that the workflow is technically suitable or production-ready.

Built, measured, and moving toward production

Implemented

Measured

Not yet demonstrated

Evidence is linked directly to the public repository. Measurements describe the stated local environments; they are not public-Ethereum latency or production-readiness claims.

Oleg Jakushkin, creator of zkdeel

Creator

Oleg Jakushkin

Building zkdeel’s room contracts, proof path, Osaka EVM test surface, observer and application-room demos.

The public repository includes the protocol’s implemented boundary, direct evidence and explicit production blockers.

RepositoryEmail

Workflow review

Does your workflow need more than one transaction—but not its own chain?

Bring one real workflow. We will map its participants, state boundary, terminal property and failure modes against the protocol’s current evidence.

This is a workflow-research conversation, not a claim of production suitability. Submissions are emailed to the founder and stored for follow-up. Rate-limited to one request every 30 seconds.