zkDeal engineering · Platform Engineering
Specialized validity systems and Stage-aligned room profiles
Separate proof systems from settlement models, choose a zkDeal room inside a deployment envelope, and exercise today’s trust-root and fallback boundaries.
APPLICATION-SPECIFIC AND PRIVACY PROOF BASES
How zkdeal differs from specialized validity systems
Specialized systems in the L2BEAT landscape
Scope: These application-specific exchange, payment and privacy systems are closer to zkdeal in product scope than generic chains, but differ in state lifetime, data availability, custody and privacy.
| 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, proof-backed checkpoints bind Ethereum data, beneficiary credit, room liabilities and the application's exit policy. | Best for bespoke, bounded EVM episodes that choose their market policy, clocks, assets and close without creating a permanent venue. |
| Stone / StarkEx family | Legacy StarkEx-family deployments | Application-specific STARK validity proofs; data availability and exit depend on the deployment, including validium committee models. | A strong fit for specialized exchange lineage. zkdeal generalizes the bounded-application idea to policy-pinned EVM rooms with explicit room liabilities and close. |
| Lighter custom prover | Lighter Exchange | Application-specific validity rollup; Ethereum blobs/state deltas; exchange-oriented exit model. | Lighter is purpose-built for exchange execution. zkdeal targets bespoke multi-step EVM workflows beyond a single exchange design. |
| INTMAX | INTMAX Payments | Application proof stack with self-custodied data; payments and private-transfer focus. | INTMAX is purpose-built for network-wide private payments. zkdeal focuses on L1-custodied assets, EVM workflow policy and application-selected privacy. |
| Barretenberg / Aztec | Aztec | Privacy-first validity rollup with private/public state and the Aztec Virtual Machine; Ethereum settlement. | Aztec is the natural fit for general private smart contracts. zkdeal focuses on bounded EVM rooms and uses privacy only where the application adds it. |
Starknet, S-two, STARKs and validity rollups
How to read this comparison
Technology family: A proof system explains how computation is verified. It does not by itself determine data availability, sequencing, custody, governance or exits.
zkdeal comparison unit: The comparison uses the selectable validity-only + Ethereum-data + L1-vault profile. It is not a description of every zkdeal room; unanimous and blob-oriented profiles have different assurance boundaries.
VI STAGE LENS • ROOM-PROFILE CHOICES
Choose a room profile; stage the deployment
Room choice inside a deployment envelope
Options, enforcement and Stage effect
| Choice | What zkdeal enforces after selection | Stage effect |
|---|---|---|
| Deployment rail validity + Ethereum data, or open/mixed | The Stage-oriented manager admits only validity-proof rooms whose canonical data is in Ethereum calldata. The open manager retains consent, blob and aggregate options. | Only the concrete deployed manager is assessed. Weaker options on the open rail do not inherit another deployment's Stage. |
| Room-specific ZK template, policy and proof identity | The application selects a registered template and policy. Program identity, verifier, calls, storage, assets, capacity and close behavior are bound to that room. | Supports a narrow, reviewable trust surface. A new template must join the deployment's governed and reproducible proof inventory. |
| Data + reconstruction calldata or blob; Ethereum or sparse state | The Stage-oriented rail requires calldata. Independent reconstruction now rebuilds Ethereum-state rooms from L1 genesis, deposits, imports and accepted batches. | Calldata + Ethereum state supplies the current Stage 0 path. A separately assessed blob rail and sparse-state reconstruction are not yet provided. |
| Funding + exits beneficiaries, assets and exit mapping | Validity rooms require an exit-bearing template. A consumed deposit credits its beneficiary before app execution; an unconsumed deposit becomes refundable after its onchain deadline; proved exits become L1 claims. | Provides room-level accounting and exit controls needed for Stages 0 and 1. Unusual asset accounting needs a reviewed template. |
| Admission + forcing window, bond, penalty and user deadline | The application chooses the room window and accountability terms within protocol bounds. Any user can queue an L1 request; an overdue request must execute, revert, receive a proved rejection or stop room progress. | Supplies the Stage 1 censorship path for validity rooms. It is not available to unanimous consent rooms. |
| Recovery + governance clocks room timing and deployment delay | The room chooses inactivity, admission and confirmation clocks; the deployment chooses the timelock and council model. Protocol floors and ceilings prevent unbounded room settings. | The complete exit must fit before a non-council upgrade. Maximal room clocks can approach 21 days, so a seven-day governance delay does not fit every room. The application chooses shorter clocks or the deployment chooses a longer delay; the deployer demonstrates the selected timing envelope. |
Current readiness
Platform advocate view
Choose the assurance envelope—and make it observable
“ZK” is not a complete product description. zkDeal makes the missing choices explicit: where data lives, which proof template is accepted, how assets enter and leave, what happens when service operators disappear, and which governance clocks apply. That clarity lets an application choose a deliberately small room without pretending every room is a rollup.
The commercial advantage is focus. A product team can buy or operate only the assurances its episode needs, while a deployment owner can constrain the catalog to a Stage-aligned validity path. The proof binds the chosen profile; the deployment and its exercised recovery evidence establish the wider operating claim.
- Treat proof family, data availability, custody, and exit policy as separate decisions.
- Verify committed artifact locks before relying on a profile.
- Exercise the failure path, while stating honestly which verifier boundary the current public drill uses.
Demo / use it today
Run the public path
Use the public protocol, node, and prover repositories to inspect the committed trust roots and run the all-services-off exit exercise that exists today.
Before you start
- A Bash-compatible shell: Linux, macOS, or WSL on Windows. The copyable commands use POSIX shell syntax.
- The public repositories still expect their legacy sibling folder names. Clone into the names shown in the terminal, and keep the pinned commits together in one parent directory.
- Docker Compose with enough disk for the drill’s first build.
- A fresh drill chain for every rerun.
Check the locks
The protocol lock checker verifies the artifacts that are present and reports anything that cannot be verified in this checkout. Treat a non-zero exit as a stop condition.
Run the exit exercise
The drill stops the hosted path, rebuilds from Ethereum-side data, submits, and claims. Capture the full exit code; do not pipe the real acceptance run into tail.
Classify the result correctly
DRILL PASS is useful fallback integration evidence, but the public drill currently wires a mock seal/verifier boundary. The real-GPU, real-verifier variant is still deferred.
Create the expected checkout
mkdir zkdeal-lab && cd zkdeal-labFetch the protocol
git clone https://github.com/zkdeal/zkdeal-protocol.git web3-protocolExpected output shape
Cloning into 'web3-protocol'...Fetch the room node
git clone https://github.com/zkdeal/zkdeal-node.git app-nodeExpected output shape
Cloning into 'app-node'...Fetch the public prover inputs
git clone https://github.com/zkdeal/zkdeal-prover.git prover-nodeExpected output shape
Cloning into 'prover-node'...Pin reviewed commits
git -C web3-protocol checkout 8a188a5 && git -C app-node checkout c8b4669 && \
git -C prover-node checkout 1b894e7Expected output shape
HEAD is now at 8a188a5
HEAD is now at c8b4669
HEAD is now at 1b894e7Exercise profile gates
docker compose -f web3-protocol/docker-compose.yml run --rm contracts-test \
"forge test -vv --match-contract '^(RoomManagerDeploymentProfileTest|RoomManagerProfileRouteClosureTest)$'"Expected output shape
RoomManagerDeploymentProfileTest: 13 passed
RoomManagerProfileRouteClosureTest: 8 passedVerify committed proof and contract locks
docker compose -f web3-protocol/docker-compose.yml run --rm locks-testExpected output shape
artifact lock verification passed (15 verified, 6 not verifiable here)Inspect the proof dependency graph
docker run --rm -v "$PWD:/umbrella:ro" -w /umbrella/web3-protocol \
node:22-bookworm@sha256:0557ac14e0d45d02ed563067b82856ca5e7aa3437fa28d98d4350ea9c3d9494a \
node scripts/check-proof-graph.mjsExpected output shape
trust root pending v6 mint - lock is zkdeal/zkvm-artifacts-lock/v5
proof dependency graph check passed (5 checks, 1 pending note(s))Exercise the public fallback drill
DRILL_VERIFIER=mock DRILL_PROVE=mock \
docker compose -f app-node/docker-compose.drill.yml run --rm drill-driverExpected output shape
variant: DRILL_VERIFIER=mock DRILL_PROVE=mock
credentials: none - no operator key, no council key, no hosted endpoint
DRILL PASSWhat this gives you: You finish with a reproducible trust-root check and the strongest public all-services-off exercise currently available—without promoting mock-verifier evidence into a production proof claim.
Interactive expected I/O
Check trust roots, then rehearse the fallback boundary
Select text directly in the player, pause at any point, or copy the complete transcript below.
Copy or read the complete transcript
$ mkdir zkdeal-lab && cd zkdeal-lab
$ git clone https://github.com/zkdeal/zkdeal-protocol.git web3-protocol
Cloning into 'web3-protocol'...
$ git clone https://github.com/zkdeal/zkdeal-node.git app-node
Cloning into 'app-node'...
$ git clone https://github.com/zkdeal/zkdeal-prover.git prover-node
Cloning into 'prover-node'...
$ git -C web3-protocol checkout 8a188a5 && git -C app-node checkout c8b4669 && \
> git -C prover-node checkout 1b894e7
HEAD is now at 8a188a5
HEAD is now at c8b4669
HEAD is now at 1b894e7
$ docker compose -f web3-protocol/docker-compose.yml run --rm contracts-test \
> "forge test -vv --match-contract '^(RoomManagerDeploymentProfileTest|RoomManagerProfileRouteClosureTest)$'"
RoomManagerDeploymentProfileTest: 13 passed
RoomManagerProfileRouteClosureTest: 8 passed
$ docker compose -f web3-protocol/docker-compose.yml run --rm locks-test
artifact lock verification passed (15 verified, 6 not verifiable here)
$ docker run --rm -v "$PWD:/umbrella:ro" -w /umbrella/web3-protocol \
> node:22-bookworm@sha256:0557ac14e0d45d02ed563067b82856ca5e7aa3437fa28d98d4350ea9c3d9494a \
> node scripts/check-proof-graph.mjs
trust root pending v6 mint - lock is zkdeal/zkvm-artifacts-lock/v5
proof dependency graph check passed (5 checks, 1 pending note(s))
$ DRILL_VERIFIER=mock DRILL_PROVE=mock \
> docker compose -f app-node/docker-compose.drill.yml run --rm drill-driver
variant: DRILL_VERIFIER=mock DRILL_PROVE=mock
credentials: none - no operator key, no council key, no hosted endpoint
DRILL PASSVideo fallback generated with VHS 0.11.0
Pinned public inputs
Repositories and images used here
- zkdeal-protocolMIT8a188a5
- zkdeal-nodeBUSL-1.1c8b4669
- zkdeal-proverBUSL-1.11b894e7
Public availability is not one license claim: protocol, examples, and testing are MIT; node, prover, and coordinator are public source under BUSL-1.1.