zkDeal engineering · Technology Brief
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.
GENERAL-PURPOSE L2 PROOF BASES
How zkdeal compares with shared-L2 proof stacks
Comparison scope
Comparison unit: This table compares proving and validation technology, not individual chains. Vanilla OP appears once as the optimistic benchmark. A proof family does not by itself determine data availability, sequencing, governance or exit rules.
| Underlying technology | Used by L2BEAT-listed systems (examples) | Validation, data availability and canonical exit | Best fit and relation to zkdeal |
|---|---|---|---|
| zkdeal RISC Zero room STF + Groth16 | Independent protocol • not yet L2BEAT-listed | Selectable room profiles. On the Stage-oriented rail: a validity proof gates every checkpoint, Ethereum calldata binds genesis and transitions, and the selected exit policy turns proved balances into L1 claims. | A bounded EVM workflow whose application policy, proof identity, clocks, assets and close are bound at room opening. It can begin in, return to or coordinate with a larger L2 ecosystem. |
| OP Stack + OPFP vanilla optimistic | OP Mainnet • Ink • Unichain | Interactive fault proofs; Ethereum data availability; Standard Bridge withdrawal waits seven days on mainnet. | Best for continuous public execution and shared-chain composability; liquidity depth is deployment-specific. zkdeal complements it when one finite episode selects proof-gated room settlement and room-scoped L1 accounting. |
| SP1 Hypercube / Turbo OP Succinct validity | Mantle • Katana; SP1 also participates in Taiko | In full-validity mode, SP1 proves each accepted OP/EVM state update; Ethereum data availability; proof-backed bridge exit. OP Succinct can also expose an owner-controlled optimistic fallback. | A strong fit for a full OP-compatible validity chain. zkdeal applies a smaller room lifecycle around one workflow. |
| SP1 ZK fault proofs OP Succinct Lite / 1R | Base • Morph • Facet • Ethscriptions • Celo | ZK resolves disputes; the happy path remains optimistic, so canonical exits retain challenge mechanics. Celo also uses external data availability. | A strong fit when OP compatibility is primary and ZK accelerates disputes. zkdeal requires validity at every accepted room checkpoint. |
| RISC Zero zkVM Kailua / multiproof | Taiko • BOB • Ronin; zkdeal uses RISC Zero too | General RISC-V execution proofs; a deployment may use full validity or ZK fault proofs; data availability and exit follow the host rollup. | The same prover family supports different products: zkdeal proves a certified room journal; these integrations prove a continuing chain. |
| Linea prover | Linea | EVM-specific validity proof; Ethereum data availability; persistent rollup bridge. | Linea serves public EVM composability. zkdeal adds task-scoped state, constrained calls/storage, L1 escrow and terminal close. |
| S-two | Starknet • Paradex | Cairo-focused STARK validity proofs; persistent rollup state and bridge; Ethereum settlement. | S-two now appears in Starknet and Paradex. It is a strong fit for Cairo-based ecosystems; zkdeal is EVM-room oriented. |
| Boojum / ZK Stack; legacy ZKsync Lite stack | ZKsync Era • Abstract • Sophon • Lens • Cronos zkEVM • zkCandy | Separate Matter Labs validity stacks: Boojum for ZK Stack and Era-era chains; legacy custom circuits for ZKsync Lite. Ethereum data for rollups or external data for validiums; exit follows the deployment. | A strong fit for launching a ZK Stack chain with shared tooling. zkdeal offers a bounded room with per-workflow policy and close. |
| OpenVM | Scroll | RISC-V zkVM-based EVM validity proof; Ethereum data availability; persistent rollup bridge. | Scroll serves shared EVM execution. zkdeal focuses on a room-chosen, proof-pinned workflow policy, room-scoped liabilities and a deliberate end state. |
| Airbender | ADI Chain | RISC-V validity proof; Ethereum data availability; continuing L2 state and bridge. | A strong fit for a policy-aligned general chain. zkdeal makes policy and decommissioning specific to each room. |
| zkProver | Silicon • Wirex Pay Chain | Validity proof with external committee data availability in these deployments. | A strong fit for continuing application chains using committee availability. zkdeal's current Stage-oriented deployment uses Ethereum calldata; blob modes remain options on the broader deployment rail. |
Motivational example
A useful first app is deliberately small
Start with a counter that has one useful operation: increment. It is small enough to read in one sitting, yet it still forces the decisions every room application needs—who may call, which target and selector are admitted, which call kind is allowed, and what state transition follows.
The interesting step is making those decisions executable. A shared L2 remains a good home for broad composability; a room is useful when an application wants a deliberately bounded action surface and a checkpoint that commits to what happened inside it.
- Begin with one state transition and one four-byte selector.
- Generate a deterministic app artifact and keep it in sync with the capability manifest.
- Test the allowed call, rejected selector, malformed input, overflow, and exact caller/target policy.
Demo / use it today
Build a minimal room application
Use the dependency-free minimal app in zkdeal-examples. Its executable definition, capability manifest, deterministic build artifact, and five focused tests fit in one small package; no wallet, Solidity toolchain, sibling checkout, or live chain is required.
Before you start
- A Bash-compatible shell: Linux, macOS, or WSL on Windows. The copyable commands use POSIX shell syntax.
- Docker.
- The examples repository at the listed commit; the command uses a digest-pinned Node image.
Read the application boundary
Read the executable definition beside app.capabilities.json. The app admits one increment(uint256) selector for one declared caller and target.
Build with the pinned toolchain
Run the deterministic builder through the pinned Node container. It emits minimal-counter.app.json from the same definition the tests exercise.
Prove the useful and rejected paths
The five-test gate checks a successful immutable state transition and four fail-closed boundaries: selector, ABI shape, uint256 range, and exact call policy.
Fetch the minimal application
git clone https://github.com/zkdeal/zkdeal-examples.git apps-examplesExpected output shape
Cloning into 'apps-examples'...Pin the reviewed application commit
git -C apps-examples checkout 54f329a04569f452ad0d32be1239ad86407a9c22Expected output shape
HEAD is now at 54f329aInspect the one admitted selector
jq -c '{appId,selector:.callRules[0].selector,callRules:(.callRules|length)}' \
apps-examples/packages/minimal-app/app.capabilities.jsonExpected output shape
{"appId":"minimal-counter","selector":"0x7cf5dab0","callRules":1}Build and test in a pinned Node container
cd apps-examples && docker run --rm \
--mount "type=bind,src=$PWD,dst=/src,readonly" -w /tmp \
node:22-bookworm@sha256:0557ac14e0d45d02ed563067b82856ca5e7aa3437fa28d98d4350ea9c3d9494a \
bash -lc 'cp -a /src/packages/minimal-app . && cd minimal-app && npm run build && npm test'Expected output shape
Built /tmp/minimal-app/dist/minimal-counter.app.json
ok 1 - the capability manifest and executable definition stay in sync
ok 2 - the one allowed action increments state without mutating the prior state
ok 3 - a selector outside the allowlist is rejected and state remains unchanged
ok 4 - malformed arguments and uint256 overflow are rejected
ok 5 - the room rule binds exactly the declared caller, target, selector and call kind
# tests 5
# pass 5
# fail 0What this gives you: You have a small application shape that can be understood, changed, and tested before it is attached to a coordinator or funded room.
Interactive validated I/O
Build and test a minimal room application
Select text directly in the player, pause at any point, or copy the complete transcript below.
Copy or read the complete transcript
$ git clone https://github.com/zkdeal/zkdeal-examples.git apps-examples
Cloning into 'apps-examples'...
$ git -C apps-examples checkout 54f329a04569f452ad0d32be1239ad86407a9c22
HEAD is now at 54f329a
$ jq -c '{appId,selector:.callRules[0].selector,callRules:(.callRules|length)}' \
> apps-examples/packages/minimal-app/app.capabilities.json
{"appId":"minimal-counter","selector":"0x7cf5dab0","callRules":1}
$ cd apps-examples && docker run --rm \
> --mount "type=bind,src=$PWD,dst=/src,readonly" -w /tmp \
> node:22-bookworm@sha256:0557ac14e0d45d02ed563067b82856ca5e7aa3437fa28d98d4350ea9c3d9494a \
> bash -lc 'cp -a /src/packages/minimal-app . && cd minimal-app && npm run build && npm test'
Built /tmp/minimal-app/dist/minimal-counter.app.json
ok 1 - the capability manifest and executable definition stay in sync
ok 2 - the one allowed action increments state without mutating the prior state
ok 3 - a selector outside the allowlist is rejected and state remains unchanged
ok 4 - malformed arguments and uint256 overflow are rejected
ok 5 - the room rule binds exactly the declared caller, target, selector and call kind
# tests 5
# pass 5
# fail 0Video fallback generated with VHS 0.11.0
Pinned public inputs
Repositories and images used here
Current first-party zkdeal repositories and packages are MIT licensed. These pinned historical inputs retain the license recorded at each referenced commit or image digest.