Yellow paper · August 2026
zkdeal: A Bounded Execution Mode for Ethereum
Temporary and rolling execution rooms with validity checkpoints
Search every page, select and copy text, use the jump control, or press the arrow and page keys. Every page has a shareable link.
Page 01
Problem and thesis
zkdeal yellow paperbounded proof-backed executionzkdeal: A Bounded Execution Mode for EthereumTemporary and rolling execution rooms with validity checkpointsOleg IakushkinFounder zkDealcontact@zkdeal.orgAugust 2026Abstract.Ethereum supports atomic transactions and persistent rollups, but some workflows need several ordered steps without apermanent chain. A zkdeal room is a temporary EVM instance governed by fixed execution and closure rules. Its state becomescanonical only when Ethereum accepts a validity checkpoint. Users sign intents, an operator orders them, and a proof re-executesthe resulting blocks. A public journal binds continuity, data, authorization, accounting, withdrawals, and closure. The proofestablishes correct execution, while admission, fair ordering, data availability, and Ethereum finality remain separate concerns.Prototype runs execute 3–10 local blocks in 1.5–5 seconds at a 0.5-second cadence. Recorded B200 tests returned Ethereum-verifiable Groth16 proofs, but the small sample lacks stage, cycle, inclusion, finality, and L1-gas measurements. The contributionis a protocol composition and prototype, not a new cryptographic primitive or a cost claim.Ethereum L1BqregisterBtaccept one-shotBsacceptJkBvaccept sparseJkBunext or closeone-shotopen3–10 L2 blocksprovesubmitdiscardrollingopenrunJkrunJk+1sparseopenprovisional execution windowperiodicJkfinal closeFigure 1:Room execution against Ethereum block time. Horizontal edges represent local processing. Upward edges submit journals. Later roomstate becomes canonical only when the connected L1 block accepts the submitted journal. Spacing is schematic.1Problem and thesisAn Ethereum transaction gives one atomic state transition. Apersistent rollup supplies continuing execution, but also requiresa sequencer, prover, bridge, data service, and long-lived opera-tions [1]. State channels support temporary interaction, usuallythrough participant-signed updates and an on-chain dispute path[2].Some workflows sit between these choices. Examples includedelivery-versus-payment, an asynchronous vault round, sealedmarket clearing, and payment authorization followed by fulfil-ment. They need several ordered steps, but they do not alwaysneed a permanent chain.A room provides a temporary EVM environment for one suchworkflow. Local execution is provisional. Its result becomescanonical only after Ethereum accepts a checkpoint journal andvalidity proof.34567891024Texec=nδL2local blockssecondsFigure 2:IMPLEMENTATIONLocal execution window. At theconfigured 0.5-second cadence, 3–10 blocks take 1.5–5 seconds.Proof and settlement are separate.1.1PremisePersistent L2 infrastructure can outlive a bounded task. A one-shot room opens, runs the workflow, proves a closing checkpoint,settles on Ethereum, and decommissions its runtime. Rollingand sparse rooms reuse the same acceptance rule with differentcheckpoint schedules.This design rolls up a workflow, not an application estate.No cost or latency advantage follows without measurements forproving, data publication, and L1 acceptance.1.2Design requirementsThe protocol has five requirements:1.Authenticated opening.Ethereum binds the template, ini-tial root, participants, and accounting frame before roomexecution.2.Certified execution.Every checkpoint follows one deter-ministic EVM transition policy.3.Continuity.Every accepted checkpoint extends the latestL1-accepted root.4.Conservation.Custodied assets reconcile with liabilitiesand withdrawal claims.5.Recovery.Canonical data supports reconstruction, claims,and safe runtime disposal.Claim labels.MEASUREDis recorded;IMPLEMENTATIONis ob-served in code or tests;MODELEDuses stated assumptions;DESIGN TARGETrequires future qualification.1
Page 02
Protocol contribution and system model
zkdeal yellow paperbounded proof-backed executionlonger lifetime and broader scopeatomic L1 callone transitionstate channelinteractive updateszkdeal roombounded EVM workflowone or many checkpointsrollup or appchainpersistent serviceexecution-shape map; not a security rankingFigure 3:zkdeal occupies the lifecycle gap between one-call atomicity and persistent L2 infrastructure.2Protocol contributionTemporary runtimes, off-chain ordering, EVM execution, va-lidity proofs, storage proofs, and L1 custody are establishedtechniques. zkdeal combines them around one Ethereum check-point for a bounded workflow.The claimed combination has four parts:(i)Authenticated room.Ethereum binds the opening state andthe rules that govern execution and closure.(ii)Intent-authorized order.Users sign actions, the opera-tor orders them, and the proof certifies the resulting EVMtransition.(iii)Ethereum validity journal.The checkpoint binds execu-tion, public data, authorization, and accounting to one proof;fig.7and table5give the field classes.(iv)Explicit terminal state.One-shot, rolling, and sparse roomsuse one acceptance rule, while an accepted close preservescustody and claims after the runtime ends.This is a systems-composition claim, not a new cryptographicprimitive.Section10narrows the claim against channels,Ephemeral Rollups, Plasma, validium, coprocessors, and rollupvariants.3System model and notation3.1Actors and trustUsers authorize intents. The operator chooses their order, andthe executor computes EVM blocks.A prover certifies thetransition. Theroom manager contractverifies checkpoints,updates accounting, and records the canonical room state onEthereum.userssign intentsoperatorordersexecutorruns EVMprovercertifiesroom manager: verify, account, checkpointsignedwitnessdatanot trusted for safetyFigure 4:The proof and room manager protect state safety.Ordering, liveness, and provisional data still depend on theoperating mode.The operator need not be trusted for execution safety, butit controls admission and order unless the execution policyconstrains them. Proof soundness removes the need to trust theprover’s result; the prover may still learn its witness. Recoveryalso requires the canonical data named by the accepted journal.Guarantee boundary.Proof and L1 contract establishThey do not establishintent authorization; deterministic execu-tion; checkpoint continuity; public account-ing; closure rulesadmission; fair ordering; censorship resis-tance; witness secrecy; availability of provi-sional sparse state; L1 inclusion or finality3.2NotationTable 1:Core notation.SymbolMeaningD, r, eL1 chain and room-manager domain, room identifier, immutable instanceepochTreusable cold templatetregistered cold-template commitmentP, A,Γexecution, authorization, and checkpoint policiesχP, χproofcommitments toPand the proof programSjcomplete room state after stepjιisigned intentaisigner recovered fromιiπoperator-selected intent orderBbordered room block at heightbJk, ckjournal for checkpointkand its hashρkstate root accepted after checkpointkΠk, vkvalidity proof and verification keyδL2configured local block cadence∆cinterval between checkpointsThe deployment domainDcontains the L1 chain identifier androom-manager address. Bytes are length-delimited before hash-ing. Addresses and integers use Ethereum ABI encoding unlessa field states otherwise. Every signature and room-specific com-mitment binds its message type and(D, r, e). The reusabletemplate binds its type but not a room instance.3.3RoomDefinition 1 (room).A room isR= (D, r, e, T, P, A,Γ, S0),(1)whereS0is its authenticated opening state.The template commits to the opening root, execution policy,and proof program:t=Keccak256(ABI(RoomTemplate, ρ0, χP, χproof)).(2)The room manager registerstbefore it admits participant assets.3.4Signed intent and orderAn intent contains a signer, nonce, deadline, call payload, value,and fee bounds. LetHbe the domain-separated signing hash.The signature rule isιi= (mi, σi),Recover(H(D, r, e,SignedIntent, mi), σi) =ai.(3)The operator chooses a permutationπover admitted intents.The proof checks each intent at its selected position under policyP.2
Page 03
Protocol lifecycle and certified execution
zkdeal yellow paperbounded proof-backed executionι1ι2ι3operator orderπB1= [ι2, ι1]B2= [ι3]proof binds order and rootsFigure 5:Signed intents become an ordered batch whose execu-tion can be proved.4Protocol lifecycle and modesAll rooms use the lifecycle in fig.1. They share one transitionrule and one Ethereum acceptance predicate. Their checkpointschedules differ.4.1Cold-template proof and openingAcold-template proofcertifies construction of an allowedopening state. It binds code, initialized storage, execution limits,participant roots, the verifier, and the initial accounting frame.The proof prepares a reusable template; it does not execute lateruser actions.Opening registers one room instance against that template.The registration binds(D, r, e), the opening root, all three poli-cies, the verifier, participant limits, custody, and closing con-ditions. The room manager requires the service bond beforeparticipant assets enter the room.4.2ExecuteUsers submit signed intents at the admission boundary. Theoperator checks the signature, nonce, domain, resource bounds,and available value before admitting an intent. Admitted intentsremain provisional until an L1-accepted checkpoint includesthem.The production rule isdrop and continue. The operatorscans a bounded queue, records why an envelope is structurallyinvalid, drops it, and continues. A bad signature or domain isstructural invalidity; an ordinary EVM revert is not. A revertingintent remains in its selected block and consumes its nonce andgas.Each block is atomic. If block construction fails, the executorrestores state, headers, address discovery, and queue effects totheir pre-block values.4.3Checkpoint chain and modesCheckpointkbegins at the latest L1-accepted root:Jk.preRoot=ρk−1,Jk.index=k.(4)Its first L2 block follows the accepted height, and its blockrange is contiguous. Ethereum orders and finalizes checkpointtransactions; it does not choose the room’s intent order.Every checkpoint must extend the latest L1-accepted root.An operator may prove several local blocks at once, but it maynot checkpoint a branch that bypasses that root. The post-statebecomesρkonly after L1 acceptance.The three modes are:1.One-shot.One checkpoint proves the workflow and closesthe room.2.Rolling.Successive checkpoints extend the room without afixed short lifetime.3.Sparse.A longer provisional window precedes a periodicor closing checkpoint.Sparse operation changes the rollback and availability boundary;section7.5states that boundary once.4.4Close and decommissionA closing journal proves the terminal allocation and sets theclose flag. The room manager rejects later checkpoints, whileclaims and withdrawals remain usable.After L1 acceptance, the operator may decommission execu-tor instances and delete caches and prover workspaces. Canon-ical batch data, custody, liabilities, withdrawal roots, and ac-cepted commitments remain available under the recovery rulesin section7.4.5Certified execution and proof5.1Transition ruleLetEjcontain the constrained block number, timestamp, gaslimit, chain identifier, and environment fields. For executionpolicyP, one selected intent advances the state bySj+1= ΥP(Sj, ιπ(j), Ej).(5)PolicyPbounds block and transaction counts, gas, memory,code, contract creation, call edges, storage namespaces, andauthenticated imports. The proof rejects any transition outsidethose bounds.Production authorization uses the non-broadcastSignedIn-tentformat from eq. (3). It binds the user instruction to the L1chain, room manager, deployment, room, epoch, nonce, dead-line, and payload.The inner EVM transaction is witness data rather than areusable authorization for another chain.The registry mustnever reuse the tuple(D, r, e).S0authenticated rootρ0B1: ordered signed intentsS1, intermediate rootρ1B2: ordered signed intentsS2, terminal rootρ2ΥPΥPone proofFigure 6:One proof folds a contiguous block sequence andbinds every intermediate state root.The proved block list is nonempty and no larger than thepolicy maximum. A policy may permit a one-block rolling orclosing checkpoint.LetτQbe the latest L2 timestamp accepted in room stateQ. LetτL1be the checkpoint’s L1 acceptance time. For batchtimestampsτ1, . . . , τzand earliest deadlinedmin, requireτQ≤τ1≤ · · · ≤τz≤τL1≤dmin.(6)The proof checks the L2 sequence. The room manager checksthe L1 bounds, so a batch cannot assign an earlier timestamp toan expired intent.5.2Authorization modesBoth authorization modes use the same transition proof:•Journal-unanimous mode.Every active approver signs theexact checkpoint journal.•Per-intent mode.Each caller signs its own intent, and theproof verifies those signatures inside the selected batch.3
Page 04
Ethereum acceptance and accounting
zkdeal yellow paperbounded proof-backed executionidentitydomain, room, policyexecutionrange, roots, dataauthorizationparticipants, approverslivenessinbox, admissionsexternal stateL1 import anchorassetsliabilities, withdrawalsJk: public checkpoint journalck=Keccak256(ABI(Jk))Figure 7:The journal binds identity, execution, authorization, liveness, imports, and asset accounting into one commitment.5.3Checkpoint journalThe journalJkis the public statement for checkpointk.Itgroups settlement fields into the six classes shown in fig.7;table5is normative.Ethereum computesck=Keccak256(ABI(Jk)).(7)The proof usesckas its public input. Canonical, length-prefixedbatch bytes are also public when the mode requires calldatapublication, and their hash must match the journal.The journal binds an L1 inclusion range[bmin, bmax]. Theroom manager accepts only when the current block lies in thatrange. Changing the submission block inside the range thereforeneeds no new proof.5.4Witness and validity proofThe private witness contains the pre-state and the data neededto derive each journal class: execution blocks, authorizationrecords, liveness records, authenticated imports, and asset tran-sitions. The public inputs are the journal commitment and anycanonical bytes required by the data policy.private witnessstate, blocks, signatures, proofsproof guestre-execute and enforcePΠkwith public inputckEthereum verifierVerify(vk, ck,Πk) = 1Figure 8:The guest re-executes the ordered batch and producesan Ethereum-verifiable proof for the journal commitment.Validity isVerify(vk, ck,Πk) = 1.(8)This equation certifies the selected transition and its publicjournal commitment. The broader guarantee boundary remainsthe one in section3.1.6Ethereum acceptance and accounting6.1Acceptance predicateThe room manager accepts a checkpoint only when it matchesthe current room state and its proved inclusion range. DefineAcceptL1(Jk,Πk) =ProofValid∧ChainContinuous∧Authorized∧Accounted∧BeforeDeadline∧DataAvailable.(9)Each condition fails closed. A valid proof for a stale root,wrong room, expired range, incomplete accounting frame, ormismatched batch data is rejected. After acceptance, the roommanager advances all roots and cursors atomically. Closingprevents later checkpoints but preserves claims and withdrawals.6.2Asset entry, liabilities, and withdrawalFunds enter through L1 custody, a deposit inbox, or balances au-thenticated in the opening state. The room may spend them onlyafter the proof binds their amount and owner to its accountingstate.For each base asseta, the accounting frame has four buck-ets: pending depositspa, room-controlled assetsca, claimablewithdrawalsqa, and amounts already paidda. WriteLa= (pa, ca, qa, da).(10)A transition must satisfycustodya=pa+ca+qa,d′a≥da.(11)Execution may move backed value among the first three buck-ets. An accepted withdrawal moves claimable value to paidvalue and releases the corresponding L1 asset. Room-nativeshares use a separate supply invariant; they are claims on under-lying custody and are not counted again as base assets.A closing transition must allocate all controlled assets. Itsexecution policy must define a recipient, refund, or permittedburn for rounding dust in every reachable terminal state. Thismakes closure feasibility an application-policy obligation.Physical delivery, bank settlement, and external exchangebalances remain application obligations unless an authenticatedadapter brings them into the proof.6.3Authenticated L1 importsA room may read selected Ethereum state through an authenti-cated import. The witness carries account and storage proofsrooted in a confirmed L1 header [3].The journal binds the source block, header and state roots,adapter, allowed keys, payload, and replay cursor. The execu-tion policy limits which contracts and storage namespaces theadapter may expose.6.4Admission and forced outcomesAnadmission acknowledgmentrecords when the operator ac-cepted responsibility for an intent. Two forms provide differentguarantees:Admission guarantees.FormPromiseRequired commitmentClassificationsucceeded, reverted, or rejectedby a stated boundaryintentandterminal-recordboundarySuccess or positionspecified success or ordered po-sitionsealed prefix, batch index, andpositionA classification acknowledgment reserves no position, so laterintents may precede it. A stronger promise freezes the namedprefix; otherwise later ordering could invalidate the promise.A forced queue lets a user bypass normal admission after apolicy delay. An omission proof may slash the service bond4
Page 05
Security, availability, and recovery
zkdeal yellow paperbounded proof-backed executionuser Auser BoperatorproverEthereumcommit Acommit BsealrevealprovecheckpointhAhBorder sealedopen Aopen Bfixed batchJk,Πkno order-sensitive insertion after sealoperator may censor before admissionEthereum inclusion may be delayedFigure 9:Commit–reveal blocks reveal-reactive insertion after the order is sealed. Pre-admission censorship and delayed Ethereuminclusion remain possible.when the operator misses its committed boundary. These areliveness controls; ordering rules remain part of the executionpolicy.6.5Data requirementTheDataAvailablecheck requires the canonical bytes namedby the room’s data policy. Rollup-like checkpoints publish themon Ethereum. Recovery and the weaker sparse boundary arespecified in sections7.4and7.5.7Security, availability, and recovery7.1Safety invariantsAssume sound proofs, collision-resistant commitments, un-forgeable signatures, correct Ethereum execution, and availablecanonical data. Every L1-accepted checkpoint then satisfiesthese invariants:1.room identity and policy remain fixed within the checkpointchain;2.the pre-state root equals the latest accepted post-state root;3.every caller authorized its exact proved intent;4.intermediate roots match the ordered canonical batch;5.liabilities and withdrawals reconcile with custody; and6.closure preserves every outstanding claim.7.2Ordering and MEVMaximal extractable value includes gains from inclusion andordering choices [4]. A room narrows this surface when itsexecution policy hides information or constrains the admissibleorder.The prototype uses first-in, first-out order after observation.Network arrival is not a fair-order rule. Applications that needfairness must encode a checkable rule, such as commit–reveal,a deterministic auction, or signed price and time bounds.Calling a plaintext intent “sealed” does not hide it from theoperator. Commit–reveal hides the preimage until reveal, whilestronger operator privacy requires user-held reveals, thresholdencryption, or another confidentiality system.7.3Market exposureA shorter workflow window reduces modeled spot movementonly slightly at second-scale horizons.MODELEDAt 80% an-nualized volatility, the model in eq. (17) gives 3.59 basis pointsover ten seconds and 3.94 over twelve seconds. The main benefitis therefore multi-step atomicity and less public interleaving,not a sub-slot spot-price claim.7.4Data availability and recoveryAn accepted checkpoint is recoverable when its canonical batchdata, cold template, journal, and imports remain available. Areplacement executor or prover can reconstruct the acceptedstate from those inputs.L1-accepted root and journalcanonical batches and cold templatereplacement executor or proverwithdrawals and liabilities continuedelete runtime state after acceptanceFigure 10:Runtime disposal preserves the accepted data, cus-tody, and claims needed for recovery.A rollup-grade deployment also needs a timeout exit forclaims in the accepted accounting state and a refund path forunused L1 deposits. No exit can promise an outcome that neverreached an accepted checkpoint. Private keys and unpublishedapplication secrets remain outside protocol recovery.7.5Sparse-mode boundariesSparse mode treats uncheckpointed execution as operator-servedprovisional state. The protocol provides no canonical data avail-ability, forced progress, or accepted proof for that interval. Ifthe operator disappears, users return to the latest L1-acceptedroot unless the exact local data was published elsewhere.Longer checkpoint intervals therefore lengthen the rollbackwindow and increase dependence on operator availability. Theymay also increase each proof’s work. Sparse mode amortizesfixed submission overhead, but it does not by itself reduce proofwork, calldata, or total cost.8Latency, UX status, and measurements8.1Four intervals and finalityRoom execution exposes four operational intervals before L1inclusion. Ethereum finality is a later event.The four user-visible statuses are:•Provisional.The room accepted the local result; rollbackremains possible.•Proof-ready.An Ethereum-verifiable proof exists, butEthereum has not accepted it.•Submitted.The checkpoint transaction is waiting for inclu-sion.•L1-included.The room manager accepted the checkpoint;consensus finality follows separately.5
Page 06
Latency, UX status, and measurements
zkdeal yellow paperbounded proof-backed executionlocal executionproof endpointsubmissionL1 inclusionfinalityt0provisionalproof-readysubmittedL1-includedfinalizedTexecTproofTsubmitTincludeseparate consensus eventFigure 11:Local completion, proof readiness, submission, L1 inclusion, and finality are distinct events. The recorded proofmeasurements stop at proof readiness.Table 2:MEASUREDRecorded B200 timing, room gas, and paired H100 comparison. Room gas excludes cold preparation and L1settlement.DemoCold-templateproofFinal Groth16endpointRoom-EVMgasB200 fasterthan H100NobsAuction5.130 s8.917 s113,80821.7–30.2%1Shop5.139 s8.924 s113,80323.5–25.5%1ERC-75405.968 s29.641 s781,99220.2–21.3%1DvP5.138 s8.917 s69,52422.5–23.2%1ERC-46265.158 s8.910 s312,41221.4–22.4%1AMM5.398 s8.917 s824,86518.7–21.5%1Cards7.309 s28.866, 25.596, 26.426, 25.608 s480,57518.1–23.4%4A tap-to-pay interface may show the provisional status im-mediately when the merchant accepts its rollback and operator-availability risk. Irreversible delivery can instead require theproof-ready, L1-included, or finalized status chosen by the ap-plication.The page-one plot definesTexec(n) =nδL2for the config-ured cadence. LetTproof(n)be the proof-endpoint latency. Itincludes composition, recursion, identity work, Groth16 wrap-ping, self-verification, serialization, and host overhead. Hereidentity work means RISC Zero’sidentity_p254recursion step,which prepares a BN254-friendly proof before Groth16 wrap-ping [5]. ThenTready(n) =Texec(n) +Tproof(n).(12)MEASUREDThe recorded timer starts before the proof requestand stops after the endpoint returns a final Groth16 proof suit-able for Ethereum verification. The timing includes wrapping,but the record does not retain a separate wrap time.Adding a nominal two-block cadence to one 8.917-secondendpoint observation gives 9.917 seconds. That value is arith-metic, not a jointly timed run, percentile, submission result,or inclusion result. We do not claim completion within oneEthereum slot.8.2Recorded B200 observationsMEASUREDEach cold-template value records reusable opening-state preparation. Each checkpoint value records the proof end-point through its final Ethereum-verifiable Groth16 proof. ThesymbolNobscounts recorded endpoint calls. The table reportsindividual demonstrations, not production percentiles.The record did not retain Groth16 wrap splits, zkVM cycles,accelerator utilization, or L1 gas. Five workloads cluster be-tween 8.910 and 8.924 seconds despite a twelvefold room-gasrange. This suggests a proof-system granularity or recursionfloor, not equal proof cost.105106102030DvPAuction/ShopERC-4626CardsERC-7540AMMroom-EVM gas (log scale)proof endpoint (s)Figure 12:MEASUREDEVM gas is not a proof-complexityproxy. Similar gas can produce very different endpoint times.The recorded B200 advantage over H100 is modest for ahardware-generation comparison.Without cycle, memory,queue, and utilization telemetry, the record cannot identify thebottleneck.8.3Checkpoint resource modelLet∆cbe the checkpoint interval,λthe arrival rate,wthe workper arrival, andW0fixed checkpoint work. For checkpointq,Wq=W0+λ∆cw,Tproof,q=F(Wq),(13)whereFis the unmeasured proof-latency function.LetTcoldbe reusable template-proof time,mthe checkpointcount, andTRthe room duration. Accelerator duty isUacc=Tcold+∑︁mq=1F(Wq)TR.(14)LetBdaybe canonical bytes published per day. LetGf ixeddenote fixed submission gas. The functionsGdata,Ghash, andGstorecover data, hashing, and storage:Gday=mGf ixed+Gdata(Bday)+Ghash(Bday)+Gstore(m).(15)Sparse checkpointing amortizesGf ixedbut leaves throughput-dependent terms. The missingF, L1-gas, and accelerator-pricerecords prevent a cost comparison with L1 or a persistent L2.9Prototype status and examplesThe prototype contains an EVM engine, a transition-policyguest, a GPU proof path, Ethereum settlement contracts, andseven examples [6].6
Page 07
Prototype status and related work
zkdeal yellow paperbounded proof-backed executionTable 3:Prototype examples and the property exercised by each example.ExampleBounded workflowCheckpoint shapeProperty exercisedRights or assets outAuctioncommit, seal, reveal, clearone closing checkpointno reveal-reactive insertion after sealingwinner allocation; seller proceedsShopauthorize purchase, disconnect, fulfilrollingfulfilment while customer is offlineitem right; merchant proceedsERC-7540request, fulfil, claim deposit or redemptiontwo blocks, one checkpointasynchronous vault lifecycle [7]accepted deposit or redemption claimDvPpropose, affirm, exchange both legsone closing checkpointall-or-nothing terminal allocationatomic asset allocationERC-4626deposit, donate, redeemrolling checkpointsshare accounting and rounding [8]shares, assets, or withdrawal claimAMMcommit two trades, reveal, swaptwo blocks, one checkpointreserve conservation under sealed orderreserve-backed swap outputCardsprivate hand proofs and public movesfour outer checkpointsinner proofs composed into room settlementstake or prize claimThe Cards template fixes the duel, token, verifier adapter,verifying keys, funded seats, and participant root. Each browserlater proves a hidden-deck action. The outer room proof verifiesthose public inner proofs and the ordered public moves.The AMM is a two-trader demonstration. For pool reservesRx, Ry, inputx, and fee factorf, it computesy=f xRyRx+f x.(16)The proof checks reserve conservation and minimum output;the admission policy still governs censorship.The ERC-7540 manager and exchange rate are demonstration-scoped. The ERC-4626 example implements caps, virtual assetsand shares, donations, and explicit rounding. Neither exampleis a production vault review.9.1Execution compatibilityIMPLEMENTATIONThe recorded Osaka corpus contains 17,902applicable cases [9]. Every case passed in both engines: revmthrough the transition core and EthereumJS VM. The qualifiedset excludes 1,615 blob and EIP-7702 delegated-code envelopecases.All 256 opcode byte values are classified and tested. The roomengine enforces gas limits, chain identifiers, block numbers, andintermediate roots. Zero base fee is an explicit room rule, soadmission fees, queue caps, sender limits, and bond coveragecarry the spam-control load.The EIP-7702 exclusion also removes a natural smart-accountroute for signed intents. The production intent adapter describedin eq. (3) remains required before delegated accounts are sup-ported.9.2Proof reliabilityMEASUREDThe repaired CUDA path completed 20 proof arti-facts across five workload shapes without retry. A run passedonly when its final Groth16 proof verified locally against theexpected public statement. The workload alternated witnessshapes to exercise the two repaired cross-stream dependencies.MEASUREDA separate RTX 4090 capacity sweep completed120 artifacts plus a 20-artifact mirror follow-up without retryunder reduced published limits. These completion runs testselected conditions; they do not estimate a production failurerate.10Related work and novelty boundaryNearby systems differ in state lifetime, order authorization, cor-rectness enforcement, data availability, and exit guarantees. Thesame short runtime can therefore sit inside very different secu-rity models.10.1Virtual and multi-party channelsPerun virtual payment channels avoid intermediary participa-tion in each payment [10]. Multi-party channels extend theconstruction to changing participant subsets [11]. Nitro sup-ports ledger and virtual channels with an on-chain force-movepath [12].Channel participants normally authorize successive statestogether. zkdeal users authorize individual intents, while an op-erator selects their order and a validity proof certifies execution.This supports asynchronous participation but leaves admissionand unconstrained ordering with the operator.10.2Ephemeral RollupsPicco and Fortugno describe Ephemeral Rollups for games onthe Solana Virtual Machine (SVM) [13]. Accounts are dele-gated to a temporary runtime, periodically committed, and laterundelegated. The documented system uses sequencer controland fraud-proof finalization [14].zkdeal instead re-executes ordered EVM blocks in a validityproof.Its Ethereum journal also records custody liabilities,authenticated deposits and imports, withdrawal claims, andterminal closure. This is an architectural comparison; it is not aclaim that one proof family is always superior.10.3Plasma and validiumPlasma uses child-chain commitments, fraud proofs, and exitgames so asset safety need not depend on operator cooperation[15]. Its central lesson is that data withholding must not makeaccepted assets unrecoverable.Validium combines validity proofs with off-chain data avail-ability. For example, StarkEx can require a data-availabilitycommittee before it accepts an update [16].By contrast,uncheckpointed sparse-room state has neither an accepted proofnor committee-backed availability.10.4Authenticated imports and coprocessorsStorage-proof coprocessors authenticate historical or cross-chain state and prove computations over it.Herodotus, forexample, verifies storage proofs in a zkVM before returning aresult on-chain [17].The import mechanism in section6.3uses this pattern in-side a room transition. Its contribution is the binding betweenthe source proof, adapter policy, replay cursor, execution, andcheckpoint journal.10.5Based and booster rollupsBased rollups let the next L1 proposer drive sequencing andinherit L1 ordering liveness [18].zkdeal is not based: theoperator orders room intents, while Ethereum orders checkpointtransactions.Booster rollups expose the L1 environment while retainingseparate L2 storage [19]. They focus on state access across acontinuing rollup. zkdeal imports selected state through certi-fied adapters and keeps the room lifecycle explicit [19].10.6Comparative inferencePrior work supplies every individual ingredient. The claimedcombination is an Ethereum-accepted journal that ties orderedEVM execution to public accounting, recovery data, and anexplicit close. An indefinitely rolling room approaches a validityrollup; the remaining distinction is its certified workflow policy,room-scoped liabilities, and terminal-state rule.7
Page 08
Execution design space and conclusion
zkdeal yellow paperbounded proof-backed executionTable 4:Execution design space. Cells describe representative defaults; deployments may vary.FamilyRuntime and stateOrder and correctnessSettlement and recoveryAsset exit and closureL1 transactioncanonical EVM; one atomic callEthereum ordering and nativeexecutionL1 block and native datadirect contract custody; no roomcloseManaged serviceprivate service workflowoperator trust; L1 checks submit-ted callsno protocol data recoveryapplication-specific custody andshutdownVirtual channel [10,12]escrowed application sessionjoint state signatures; dispute orforce movelatestsignedstateandparticipant-held dataterminal escrow allocationEphemeralRollup[13,14]delegated SVM accountssequencer;commitments andfraud proofperiodic/final commit;revertand undelegationbase-layer accounts return onclosezkdealauthenticated EVM roomsigned intents; operator order;validity proofjournal plus canonical check-point dataL1 liabilities and claims sur-vive closePlasma / validium[15,16]continuing off-chain stateoperator; fraud or validity proofexit data or off-chain availabilitycommitteeescrowexit;noinherentbounded closePersistent L2continuing chain and bridgesequencer, committee, or L1;proof or disputeperiodicrootsandsystem-specific data pathbridgewithdrawal;notask-scoped closeBased/boosterrollup [18,19]persistent rollup or L1-reflectingstateL1-driven or host-rollup orderand proofhost-rollup data and recoveryhost bridge; no inherent termi-nal closeStorage coprocessor[17]authenticated query or computa-tionrequest selects data and pro-gram; storage proofreturns a verified fact, not a statechainno custody lifecycle by itself11Conclusionzkdeal gives a bounded EVM workflow an authenticated open-ing state, user-authorized intents, an operator-selected order,and one Ethereum checkpoint path. The validity proof certifiesexecution; the room manager enforces continuity, accounting,and closure.The prototype demonstrates the composition, not productionlatency or cost. The intended niche is a multi-step task that ben-efits from fast provisional interaction and explicit termination,while Ethereum remains the source of canonical settlement.8
Page 09
Appendices
zkdeal yellow paperappendicesAppendicesNormative field definitions, the L1 acceptance algorithm, qualification records, and the illustrative exposure model are collected below.AJournal field classesTable 5:Normative checkpoint-journal field classes. Integerwidths and ABI order follow the settlement interface.ClassBound fieldsIdentitydeployment, room, epoch, authorization mode, template, proof pro-gram, proof system, execution-policy commitmentExecutionbatch and block ranges, timestamps, minimum deadline, pre/postroots, ordered-data and canonical-data commitmentsParticipantspre/post participant and approver roots, epochs, counts, capacity,change cursorsLivenessdeposit, admission, and forced-queue cursors; record and outcomecommitmentsImportssource L1 block, header and state roots, adapter commitment, importcursorAssets and closeliability commitments, withdrawal epoch and root, inclusion range,close flagProof-work telemetry is not part of the settlement statement.The generic timestamp and inclusion-range fields are requiredprotocol fields; the current prototype does not yet include them.BAcceptance algorithmLetQbe the accepted room state andJthe submitted journal.LetΠbe its validity proof,Ccanonical batch data,Xauxiliaryrecords, andvkthe registered verification key.The journal supplies block range[bmin, bmax], batch timesτ1, τz, and minimum intent deadlinedmin.The current L1block and timestamp arebL1andτL1.The room manager performs:1.Reject a closed room and requirebmin≤bL1≤bmax.2.Match the identity, policy, checkpoint index, pre-state, par-ticipant state, and cursors inJagainstQand table5.3.RequireQ.τ≤τ1≤τz≤τL1≤dmin.4.Computec=Keccak256(ABI(J))andrequireVerify(vk, c,Π) = 1.5.In journal-unanimous mode, verify every active approver’ssignature onJ. In per-intent mode, rely on the proved intentsignatures.6.Recompute the commitment toCand validate the liveness,participant-change, and import records inX.7.Apply the liability transition, require custody conservation,and bind the next withdrawal root.8.ReplaceQatomically with the accepted post-state and cur-sors. IfJcloses, mark the room closed.Any failure reverts the full submission.CRequired measurement recordTable 6:Fields required for future qualification records.CategoryRequired fieldsTimingrequest boundary, composite, recursion, identity, Groth16 wrap, ver-ification, serialization, end-to-end timeProof complexityuser and total cycles, segments, witness bytes, canonical bytesAcceleratordevice, utilization, memory, power, billed seconds, software andasset versionsQueue and retryqueue delay, workload identity, attempt count, retry reason, terminalstatusL1 acceptanceverifier, journal, data, hashing, and storage gas; inclusion delay;finality ruleHardware cost comparisons must state the billed accelerator-seconds and price source. For an accepted checkpoint, recordL1 costs separately from proof-endpoint measurements.DIllustrative market-exposure modelFor a driftless log price with annualized volatilityσa, the ex-pected absolute movement overtseconds isE|∆logPt|=σa√︃2tπY,(17)whereYis seconds per year.01020304050600246810σa= 80%10 s: 3.59 bp12 s: 3.94 bpexposure windowt(seconds)expected movement (bp)Figure 13:MODELEDExpected absolute movement under theillustrative volatility model. The 10-to-12-second difference is0.35 basis points.This model omits spreads, jumps, and market impact; it sup-ports only the narrow comparison in section7.3.9
Page 10
References
zkdeal yellow paperreferencesReferences[1]Ethereum Foundation.Zero-Knowledge Rollups. 2026.(Visited on August 5, 2026).[2]Ethereum Foundation.State Channels. 2026. (Visited onAugust 5, 2026).[3]Felix Lange.EIP-1186: RPC Method to Get Merkle Proofs.2018. (Visited on August 5, 2026).[4]Philip Daian et al. “Flash Boys 2.0: Frontrunning inDecentralized Exchanges, Miner Extractable Value, andConsensus Instability”. In:2020 IEEE Symposium on Securityand Privacy. 2020, pp. 910–927. doi:10.1109/SP40000.2020.00040.[5]RISC Zero.RISC Zero zkVM Documentation. 2026. (Visitedon August 5, 2026).[6]zkdeal contributors.zkdeal Reference Implementation. 2026.(Visited on August 5, 2026).[7]Martin Baer et al.ERC-7540: Asynchronous ERC-4626Tokenized Vaults. 2023. (Visited on August 5, 2026).[8]Joey Santoro, transmitted-light, and jet-lab.ERC-4626:Tokenized Vaults. 2021. (Visited on August 5, 2026).[9]Ethereum Foundation.Ethereum Execution Specification Tests.2026. (Visited on August 5, 2026).[10]Stefan Dziembowski, Lisa Eckey, Sebastian Faust, andDaniel Malinowski. “Perun: Virtual Payment Hubs overCryptocurrencies”. In:2019 IEEE Symposium on Security andPrivacy. 2019, pp. 106–123. doi:10.1109/SP.2019.00020.[11]Stefan Dziembowski, Lisa Eckey, Sebastian Faust, Julia Hesse,and Kristina Hostáková. “Multi-Party Virtual State Channels”.In:Advances in Cryptology – EUROCRYPT 2019. 2019,pp. 625–656. doi:10.1007/978-3-030-17653-2_21.[12]Tom Close.Nitro Protocol. Cryptology ePrint Archive, Paper2019/219. 2019. (Visited on August 5, 2026).[13]Gabriele Picco and Andrea Fortugno.Ephemeral Rollups AreAll You Need. arXiv:2311.02650. 2023. doi:10.48550/arXiv.2311.02650. (Visited on August 5, 2026).[14]MagicBlock.Ephemeral Rollup. 2026. (Visited on August 5,2026).[15]Joseph Poon and Vitalik Buterin.Plasma: ScalableAutonomous Smart Contracts. Working draft. 2017. (Visitedon August 5, 2026).[16]StarkWare.StarkEx Data Availability. 2026. (Visited onAugust 5, 2026).[17]Herodotus.Data Processor: Verifiable Compute overAuthenticated On-Chain Data. 2026. (Visited on August 5,2026).[18]Justin Drake.Based Rollups—Superpowers from L1Sequencing. 2023. (Visited on August 5, 2026).[19]Brecht Devos.Booster Rollups—Scaling L1 Directly. 2023.(Visited on August 5, 2026).10