zkDeal engineering · Technology Brief
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.
MEV POSTURE FOR APPLICATION DEVELOPERS
Prove the market rule you actually choose
Base rule: Today, the engine orders transactions by when they reach the operator: FIFO by gossip arrival. That order is neither globally fair nor private. An application can instead pin its own ordering or clearing rule, and the accepted proof can check that the room followed it.
Where zkdeal differs: Applications on general-purpose ZK L2s can also build auctions, commit–reveal schemes and protected intents. zkdeal's distinction is packaging the selected rule, room-scoped accounting, recovery and explicit close into one isolated lifecycle.
Who can see an order before the seal
| Submission pattern | Visible before seal | Protection and remaining exposure |
|---|---|---|
| Plaintext signed intent | The operator receives the price, size and direction in plaintext. In the shipping P2P mode, room members or the relay may also see them. | The proof checks the signature, signed limits and pinned execution policy. It does not prevent censorship before admission, a reactive order that the policy permits, or an external hedge on L1 or a CEX. |
| Commit–reveal | Before reveal, observers see the commitment and metadata, not the committed price and size. The participant later opens the commitment. | If the application seals the eligible set and order before any reveal, the proof can reject insertion based on revealed content. The application must still define cutoff, metadata and missing-reveal rules. |
| App-level ZK or threshold encryption | An application-level proof reveals only selected facts. Threshold encryption exposes ciphertext until the decryption keys are released. | zkdeal supports application-specific proofs. Threshold-encrypted room order flow is not a current base feature and introduces separate key-release, availability and disclosure assumptions. |
How common MEV approaches differ
| Approach | Primary job | What it does not solve alone |
|---|---|---|
| CoW-style fair combinatorial auction | Match signed constraints through competing solver solutions and pair-specific uniform clearing prices. | Encrypted submission, guaranteed fills, reserved capital or Ethereum finality. |
| Shutter threshold encryption | Hide order content until inclusion/order is committed and a Keyper threshold releases decryption material. | Price discovery, fills, liquidity or timely key release without additional assumptions. |
| FCFS sequencing | Order by receipt at one sequencer; simple and low latency. | Global arrival fairness, privacy or immunity from network-location races. |
| Timeboost-style priority | Auction a time advantage and redirect some ordering value to the chain. | MEV elimination or fair price formation; priority remains the product. |
| Private order flow / OFA | Keep orders out of the public mempool and optionally auction backrun rights. | Cryptographic secrecy from recipients, guaranteed inclusion, liquidity or settlement. |
| zkdeal room | The application pins the ordering, clearing, collateral, timeout and close rules; the proof checks them for one bounded episode. | Encryption, fair ordering and censorship resistance are not automatic. The application must encode the rule and provide the required infrastructure. |
Cutoff, censorship economics and capital
Cutoff control: The application should tie the seal to L1 block N or another authenticated L1 signal. If the operator may choose any instant inside a wide window, that choice becomes a timing advantage.
Forced route: In validity-only mode, the application chooses a maximum admission window within protocol bounds, and each user chooses a deadline inside it. A signed room transaction can be queued on L1 without operator permission. The room cannot advance past an overdue request unless the proof shows it executed, reverted or was deterministically rejected. A live replacement-operator exercise remains qualification evidence.
Bond versus notional: An admission receipt makes omission challengeable against the service bond; it does not insure the trade value. The venue should size the penalty to its failure exposure and use the forced route as a separate path for progress.
Capital isolation: Each room keeps separate accounting, which limits the blast radius of a failure. The base contracts provide no cross-room netting. Market makers must preposition funds or add a reserve, credit, routing or rebalancing layer. Recursive aggregation shares proving and submission overhead, not balances.
Developer path and operating model
Self-operated path: Developers can run a room operator or node, prove room checkpoints and submit them to L1 permissionlessly. For calldata rooms using the Ethereum state commitment, the fallback rebuilds the opening state, policy, deposits, authenticated imports and accepted batches from L1, then composes, proves, submits and claims without hosted credentials. Imports require historical Ethereum state proofs; sparse-state reconstruction is not yet provided.
Hosted path: Hosted validity rooms inject admissible forced inputs and apply proof-bound deposit credits before the first application transaction. The host, execution engine and proof therefore start from the same credited state. The application still selects its admission clocks, service bond, omission penalty, checkpoint rhythm and market policy.
Signatures and policy: Customers sign EVM transaction envelopes with room-specific replay protection. Checkpoint approvals and admission promises use EIP-712 typed data. The application can pin permitted targets, selectors, call types, storage namespaces and resource limits.
Motivational example
Ordering is application logic
Give the same signed orders to two markets. One sorts by fee priority; the other preserves arrival order. Nothing about the orders changes, yet the searcher’s result can change from a gain to a loss. The ordering rule is part of the product, whether the product admits it or not.
A zkDeal room lets the application name that rule, test it, and bind it to the episode whose checkpoint is accepted. This is not a claim that one rule abolishes MEV. FIFO leaks timing assumptions. Commit-reveal adds another clock and another liveness edge. The useful promise is narrower: the market processes the eligible set according to the policy it published.
- Run identical signed intents against two ordering policies.
- Observe positive searcher profit under naive priority and a loss under arrival FIFO.
- Verify that the commit-reveal reference blocks the reactive and out-of-order attempts in its test scenario.
Demo / use it today
Build an app that chooses block order
Build the source-pinned SequencedAMM and CommitRevealAMM artifacts, then let the application select two different block orders for the same signed intent set in the in-memory zkDeal room harness.
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.
- The node, protocol, and examples repositories at the listed commits.
Build the contract first
The example intentionally refuses to run if the compiled SequencedAMM artifact is missing. Build through the protocol’s pinned Foundry service.
Hold the intents constant
The tests hash the same signed intent set, validate each selected order as an exact nonce-preserving permutation, and inspect the sealed block’s raw transactions. Naive priority produces +17,368 token-0 for the searcher; arrival FIFO produces -551.
Read commit-reveal narrowly
The reference blocks one reactive attempt and one out-of-order reveal in the scenario. That demonstrates the selected room rule; it is not a universal MEV-elimination claim.
Fetch the three required repositories
git clone https://github.com/zkdeal/zkdeal-node.git app-node && \
git clone https://github.com/zkdeal/zkdeal-protocol.git web3-protocol && \
git clone https://github.com/zkdeal/zkdeal-examples.git apps-examplesExpected output shape
Cloning into 'app-node'...
Cloning into 'web3-protocol'...
Cloning into 'apps-examples'...Pin reviewed commits
git -C app-node checkout c8b4669dfa47640c3f5ca9cddcab1f003a7d1eba && \
git -C web3-protocol checkout 7a8420b078d3bc04f1b5ace9de1bd223e4626608 && \
git -C apps-examples checkout 54f329a04569f452ad0d32be1239ad86407a9c22Expected output shape
HEAD is now at c8b4669
HEAD is now at 7a8420b
HEAD is now at 54f329aBuild the SequencedAMM contract
docker compose -f web3-protocol/docker-compose.yml run --rm contracts-buildExpected output shape
Compiler run successful!Run the market-ordering example and read its comparison
docker compose -f apps-examples/docker-compose.yml run --rm mev-testExpected output shape
✓ test/policies.test.ts (6 tests)
✓ test/ordering.test.ts (4 tests)
Test Files 2 passed (2)
Tests 10 passed (10)
Shared arrival order: victim buy -> attacker front-run buy -> attacker back-run sell
Identical signed intent set: yes
App selects: naive-priority
sealed block: attacker front-run buy -> victim buy -> attacker back-run sell
App selects: fair-fifo
sealed block: victim buy -> attacker front-run buy -> attacker back-run sell
| application choice | attacker PnL (token0) | victim out (token1) | blocked attempts |
| --- | ---: | ---: | ---: |
| naive-priority | 17368 | 75569 | 0 |
| fair-fifo | -551 | 90661 | 0 |
| commit-reveal-batch | n/a (contract gate) | n/a | 2 |What this gives you: You get a reproducible before/after market-design example whose economic result changes with the pinned rule and whose limitations are explicit.
Interactive validated I/O
Compare priority ordering, FIFO, and commit-reveal
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-node.git app-node && \
> git clone https://github.com/zkdeal/zkdeal-protocol.git web3-protocol && \
> git clone https://github.com/zkdeal/zkdeal-examples.git apps-examples
Cloning into 'app-node'...
Cloning into 'web3-protocol'...
Cloning into 'apps-examples'...
$ git -C app-node checkout c8b4669dfa47640c3f5ca9cddcab1f003a7d1eba && \
> git -C web3-protocol checkout 7a8420b078d3bc04f1b5ace9de1bd223e4626608 && \
> git -C apps-examples checkout 54f329a04569f452ad0d32be1239ad86407a9c22
HEAD is now at c8b4669
HEAD is now at 7a8420b
HEAD is now at 54f329a
$ docker compose -f web3-protocol/docker-compose.yml run --rm contracts-build
Compiler run successful!
$ docker compose -f apps-examples/docker-compose.yml run --rm mev-test
✓ test/policies.test.ts (6 tests)
✓ test/ordering.test.ts (4 tests)
Test Files 2 passed (2)
Tests 10 passed (10)
Shared arrival order: victim buy -> attacker front-run buy -> attacker back-run sell
Identical signed intent set: yes
App selects: naive-priority
sealed block: attacker front-run buy -> victim buy -> attacker back-run sell
App selects: fair-fifo
sealed block: victim buy -> attacker front-run buy -> attacker back-run sell
| application choice | attacker PnL (token0) | victim out (token1) | blocked attempts |
| --- | ---: | ---: | ---: |
| naive-priority | 17368 | 75569 | 0 |
| fair-fifo | -551 | 90661 | 0 |
| commit-reveal-batch | n/a (contract gate) | n/a | 2 |Video fallback generated with VHS 0.11.0
Pinned public inputs
Repositories and images used here
Public availability is not one license claim: protocol, examples, and testing are MIT; node, prover, and coordinator are public source under BUSL-1.1.