zkDeal engineering · Technology Brief

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.

Oleg Iakushkin5 August 2026 at 09:00 BST9 min read

Validity proofsL2BEATFallbackRoom profiles

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

Motivational example

Run the whole system before debating the label

Here is a better first question than “Is it ZK?”: can I start the L1, the bounded execution layer, the prover, the explorer, and an application surface, then follow one result through all of them? A local Kurtosis enclave gives that question a visible answer.

The answer matters because a proof system and a settlement system are not the same thing. Data availability, asset custody, exit behavior, governance, and the accepted proof template remain separate engineering choices. A zkDeal room keeps those choices scoped to one application episode, while the deployment profile says which combination you are actually operating.

Boot a private Ethereum L1, Blockscout, CUDA prover, coordinator, and prebuilt app surface as one named enclave.
Read the system manifest instead of inferring readiness from running containers.
Keep proof, custody, data, and exit claims separate when you describe the result.

Demo / use it today

Run L1, room execution, and a prebuilt app surface in Kurtosis

The public testing package composes a private Ethereum L1, Blockscout, a CUDA prover, the zkDeal coordinator and demo surface, and a prebuilt application. The terminal pins the key zkDeal and Ethereum client images by digest and uses a separate Kurtosis enclave.

Before you start

A Bash-compatible shell: Linux, macOS, or WSL on Windows. The copyable commands use POSIX shell syntax.
Kurtosis, Docker, curl, jq, and an NVIDIA B200 supported by the selected native sm100 prover image.
Enough disk and GPU memory for the complete local enclave.
No competing GPU workload; use a fresh enclave name for a clean run.

Generate an explicit public configuration
Copy the checked-in template, mark it ready, select the prebuilt application, and replace every publish placeholder with an architecture-appropriate immutable digest.
Start one named enclave
Kurtosis creates the L1, explorer, prover, and coordinator together, then exposes the coordinator-hosted application surface. A named enclave makes inspection and cleanup unambiguous.
Ask the system what became ready
Inspect the enclave and then query the deliberately filtered system endpoint. A list of running containers is not enough; the application, proof route, and explorer must agree on the same run.

Fetch and pin the public deployment package

git clone https://github.com/zkdeal/zkdeal-testing.git kurtosis-testing && \
  git -C kurtosis-testing checkout c791adf192a014d42087983cd644de3bfaac126e && cd kurtosis-testing

Expected output shape

Cloning into 'kurtosis-testing'...
HEAD is now at c791adf

Measure the supported GPU architecture

nvidia-smi --query-gpu=name,compute_cap --format=csv,noheader | head -n 1

Expected output shape

NVIDIA B200, 10.0

Verify the checked-in B200 image pins

GPU_NAME='NVIDIA B200' && \
  test "$(nvidia-smi --query-gpu=name --format=csv,noheader | head -n 1)" = "$GPU_NAME" && \
  grep -F 'prover: docker.io/zkdeal/prover-cuda:sm100-d60547b-20260827@sha256:e1a0b4b36637a415823fdcf1139657884dfa1f1016441a8d1e3701bed4483d67' package/params/public.yaml && \
  grep -F 'runner: docker.io/zkdeal/coordinator:20260827-shopfinal-faa4149@sha256:fd6a3f687b2b09e3df1336f0318804b339d12fa9d53e0a5ed9d6796bd047ec05' package/params/public.yaml

Expected output shape

prover: docker.io/zkdeal/prover-cuda:sm100-d60547b-20260827@sha256:e1a0b4b36637a415823fdcf1139657884dfa1f1016441a8d1e3701bed4483d67
runner: docker.io/zkdeal/coordinator:20260827-shopfinal-faa4149@sha256:fd6a3f687b2b09e3df1336f0318804b339d12fa9d53e0a5ed9d6796bd047ec05

Generate a ready shop configuration

cp package/params/public.yaml package/params/public.generated.yaml && \
  sed -i -e 's/status: TEMPLATE/status: READY/' -e 's/case: base/case: shop/' \
  -e 's/prove_queue: false/prove_queue: true/' \
  -e "s|^gpu_name:.*|gpu_name: \"$GPU_NAME\"|" package/params/public.generated.yaml

Require the filled runtime fields

test "$(grep -c '^status: READY$' package/params/public.generated.yaml)" = 1 && \
  test "$(grep -c '^gpu_name: "NVIDIA B200"$' package/params/public.generated.yaml)" = 1 && \
  ! grep -Eq '^(status: TEMPLATE|gpu_name: CURRENT_GPU_NOT_MEASURED)$' package/params/public.generated.yaml

Start the complete local enclave

kurtosis run ./package/kurtosis.yml --args-file package/params/public.generated.yaml \
  --enclave zkdeal-public --image-download always

Require system-level readiness

curl -fsS http://127.0.0.1:3100/demo/v1/system | jq -e -c \
  '{decision,allServicesReady:([.services[].status]|all(.=="READY")),gpu:.gpu.name,explorerPublished:(.canary.explorerUrl!=null),explorerUrl} | \
  select(.decision=="READY" and .allServicesReady and .gpu=="NVIDIA B200" and .explorerPublished)'

Expected output shape

{"decision":"READY","allServicesReady":true,"gpu":"NVIDIA B200","explorerPublished":true,"explorerUrl":"http://127.0.0.1:3200"}

Confirm the prebuilt app is published

curl -fsS http://127.0.0.1:3100/demo/v1/presets | jq -c \
  '[.presets[]|select(.id=="shop")|{id,name,actions:(.actions|length)}][0]'

Expected output shape

{"id":"shop","name":"Persistent tokenized shop","actions":2}

What this gives you: The B200 validation run produced one READY environment, completed the prebuilt shop workflow through GPU proving and L1 finality, and exposed the accepted checkpoint through its local explorer.

Interactive validated I/O

Run the public L1 + room + app enclave

Validated on the B200 host

Select text directly in the player, pause at any point, or copy the complete transcript below.

Copy or read the complete transcript

Plain text Asciicast v3 VHS tape

$ git clone https://github.com/zkdeal/zkdeal-testing.git kurtosis-testing && \
>   git -C kurtosis-testing checkout c791adf192a014d42087983cd644de3bfaac126e && cd kurtosis-testing
Cloning into 'kurtosis-testing'...
HEAD is now at c791adf
$ nvidia-smi --query-gpu=name,compute_cap --format=csv,noheader | head -n 1
NVIDIA B200, 10.0
$ GPU_NAME='NVIDIA B200' && \
>   test "$(nvidia-smi --query-gpu=name --format=csv,noheader | head -n 1)" = "$GPU_NAME" && \
>   grep -F 'prover: docker.io/zkdeal/prover-cuda:sm100-d60547b-20260827@sha256:e1a0b4b36637a415823fdcf1139657884dfa1f1016441a8d1e3701bed4483d67' package/params/public.yaml && \
>   grep -F 'runner: docker.io/zkdeal/coordinator:20260827-shopfinal-faa4149@sha256:fd6a3f687b2b09e3df1336f0318804b339d12fa9d53e0a5ed9d6796bd047ec05' package/params/public.yaml
prover: docker.io/zkdeal/prover-cuda:sm100-d60547b-20260827@sha256:e1a0b4b36637a415823fdcf1139657884dfa1f1016441a8d1e3701bed4483d67
runner: docker.io/zkdeal/coordinator:20260827-shopfinal-faa4149@sha256:fd6a3f687b2b09e3df1336f0318804b339d12fa9d53e0a5ed9d6796bd047ec05
$ cp package/params/public.yaml package/params/public.generated.yaml && \
>   sed -i -e 's/status: TEMPLATE/status: READY/' -e 's/case: base/case: shop/' \
>   -e 's/prove_queue: false/prove_queue: true/' \
>   -e "s|^gpu_name:.*|gpu_name: \"$GPU_NAME\"|" package/params/public.generated.yaml
$ test "$(grep -c '^status: READY$' package/params/public.generated.yaml)" = 1 && \
>   test "$(grep -c '^gpu_name: "NVIDIA B200"$' package/params/public.generated.yaml)" = 1 && \
>   ! grep -Eq '^(status: TEMPLATE|gpu_name: CURRENT_GPU_NOT_MEASURED)$' package/params/public.generated.yaml
$ kurtosis run ./package/kurtosis.yml --args-file package/params/public.generated.yaml \
>   --enclave zkdeal-public --image-download always
$ curl -fsS http://127.0.0.1:3100/demo/v1/system | jq -e -c \
>   '{decision,allServicesReady:([.services[].status]|all(.=="READY")),gpu:.gpu.name,explorerPublished:(.canary.explorerUrl!=null),explorerUrl} | \
>   select(.decision=="READY" and .allServicesReady and .gpu=="NVIDIA B200" and .explorerPublished)'
{"decision":"READY","allServicesReady":true,"gpu":"NVIDIA B200","explorerPublished":true,"explorerUrl":"http://127.0.0.1:3200"}
$ curl -fsS http://127.0.0.1:3100/demo/v1/presets | jq -c \
>   '[.presets[]|select(.id=="shop")|{id,name,actions:(.actions|length)}][0]'
{"id":"shop","name":"Persistent tokenized shop","actions":2}

Video 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.

Explore public repositories Browse Docker images

Specialized systems in the L2BEAT landscape

Starknet, S-two, STARKs and validity rollups

How to read this comparison

Room choice inside a deployment envelope

Options, enforcement and Stage effect

Current readiness

Run the whole system before debating the label

Run L1, room execution, and a prebuilt app surface in Kurtosis

Before you start

Generate an explicit public configuration

Start one named enclave

Ask the system what became ready

Fetch and pin the public deployment package

Measure the supported GPU architecture

Verify the checked-in B200 image pins

Generate a ready shop configuration

Require the filled runtime fields

Start the complete local enclave

Require system-level readiness

Confirm the prebuilt app is published

Run the public L1 + room + app enclave

Repositories and images used here