zkDeal engineering
One bounded room. Seven ways to put it to work.
A numbered seven-part series that turns zkDeal architecture into public-source tutorials you can run today.
The Island: a playable model of zkDeal
Villages, trade rooms and a distant Monolith make provisional work, proofs and checkpoints easier to see. A screenshot tour of the idea behind the game.
VII → I
Explore the articles
Start with what you can run, then work down through settlement, market policy, and the core room model.
- Part 1VII
Run the supplied Docker stack—or customize any role
Start with zkDeal’s published Docker operating planes, inspect a digest-pinned CUDA prover, and learn where customization keeps the proof and settlement boundaries intact.
- Part 2VI
Specialized validity systems and Stage-aligned room profiles
Run a local Ethereum L1, bounded zkDeal execution layer, CUDA prover, Blockscout, coordinator, and prebuilt app with the key application and client images pinned.
- Part 3V
zkDeal vs shared-L2 proof stacks
Compare a finite, policy-bound zkDeal room with shared L2 proof bases, then build a dependency-free minimal counter application and its capability policy.
- Part 4IV
Three ways capital returns to Ethereum L1
Compare the three canonical return paths, then emulate one conserved deposit-to-checkpoint-to-claim journey with the public room contracts.
- Part 5III
Prove the market rule you choose
See how the same signed intents behave under priority ordering, arrival FIFO, and commit-reveal—and why zkDeal proves the selected room rule without claiming universal MEV elimination.
- Part 6II
From a one-checkpoint clear to an eight-hour market
Deploy a one-checkpoint auction and a continuing shop as separate room profiles, then compare close behavior with a room that reopens after L1 finality.
- Part 7I
More than a transaction, less than a chain
Trace an accepted zkDeal room checkpoint from the running system record to its Blockscout receipt and human-readable L1 transaction page.