zkDeal engineering · Technology Brief
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.
CAPITAL MOVEMENT • CANONICAL EXIT PATH
Three ways capital returns to Ethereum L1
Comparison lens: A fast L2 confirmation and a fast canonical L1 release are different things. The lanes below compare the point at which Ethereum can release the asset without relying on a third-party liquidity provider.
Explore the architecture
Canonical return to Ethereum L1 — compare the release path, not L2 transaction confirmation
Drag the canvas to pan, use the wheel or pinch gesture to zoom, and use the controls to zoom or fit the whole model. Expand for a page-sized view; press Escape to close it.
View the static reference image
Read the figure transcript
Three canonical capital-return lanes. On zkdeal's L1-funded validity path, a deposit names its beneficiary and waits for the deposit block to finalize. Before proof consumption it becomes refundable after its deposit-specific onchain deadline. When consumed, the proof credits the beneficiary before application execution and records controlled liability. An exit record or terminal sweep creates a withdrawal root; the recipient then claims on L1 and waits for Ethereum finality. A validity rollup uses a canonical bridge and a proved rollup output. Vanilla OP uses a withdrawal proof followed by the mainnet seven-day challenge period.
Read the accounting states correctly
| Term | Meaning |
|---|---|
| PENDING | Queued L1 escrow. If no proof consumes it, the depositor may reclaim it after that deposit's onchain deadline. |
| CONTROLLED | A proof consumed the deposit; the room's proved accounting now controls its allocation. |
| CLAIMABLE | An accepted validity-only proof moved value into a withdrawal root reserved for an L1 recipient. |
| PAID | The recipient claimed on L1. Ethereum finality then makes that release canonical. |
What each path means for liquidity
zkdeal L1-funded validity room: On the L1-funded validity path, assets stay in the RoomVault and remain segregated by room and asset. A deposit names its beneficiary and, until consumed, carries its own onchain refund deadline derived from the room's admission window. Consumption credits the beneficiary before application execution. The application's bound exit policy maps proved balances and exit records into L1 claims; code-free residual accounts can be swept at close.
Validity rollup—including Starknet: Starknet uses STARK-based proofs, with S-two in its prover stack; validity rollup describes its settlement and exit architecture. The canonical bridge moves value into a continuing shared L2, and a validity proof supports the output used by the bridge. There is no optimistic dispute window after proof acceptance; actual release still follows that rollup's proof cadence, bridge design and Ethereum finality policy.
Vanilla OP / OP fault proofs: Optimism documents typical Standard Bridge deposits from Ethereum in 1–3 minutes. The canonical return to Ethereum waits seven days on mainnet so an invalid withdrawal can be challenged. A fast bridge can advance liquidity sooner, but that is a separate liquidity-provider service with its own price and trust assumptions.
| Exit path | Components of release time |
|---|---|
| zkdeal unconsumed refund | deposit-block finality + deposit-specific onchain deadline + refund inclusion/finality |
| zkdeal validity-only claim | deposit finality + proof credit + exit record or terminal sweep + accepted root + claim + finality |
| vanilla OP Standard Bridge | output / withdrawal proof + 7-day challenge + L1 finalization |
Speed claim and measurement boundary
Architectural advantage: The validity path uses proof acceptance rather than an optimistic challenge waiting period, while custody and accounting remain on L1.
Measurement boundary: Removing an optimistic challenge wait does not by itself guarantee a faster deposit or a seconds-level withdrawal. Teams should measure deposit finality, proof generation, checkpoint inclusion/finality and claim inclusion/finality separately.
Application-facing liquidity claims
PROGRESSIVE RELEASE: A validity-only rolling room can publish withdrawal roots before close; closure is not the first opportunity to claim.
PENDING REFUND: A deposit never consumed by a proof can return after its deposit-specific onchain deadline, even while the room continues.
PROOF-GATED EXIT: That canonical claim path waits for proof acceptance and Ethereum finality rather than an optimistic challenge period.
PROVED CLOSE: A validity room may close through a proof-bearing batch. Its close sweep covers code-free accounts and up to 32,768 leaves; contract balances still use the room's exit records.
Motivational example
Follow one user’s money all the way home
A user starts with an L1 asset, uses it inside an application, and expects an L1 result at the end. That sentence is simple. The implementation is not: deposit ownership, beneficiary binding, application debits, checkpoint acceptance, withdrawal allocation, and the final claim must all agree.
The best demo therefore follows one conserved quantity through the entire trip. Do not stop at a fast UI confirmation. Show the room actions, the accepted checkpoint, the Ethereum transaction, and the balance that becomes claimable. Then the liquidity story is a sequence someone can inspect rather than a promise hidden behind the word “finality.”
- Fund the application from L1 and bind the intended beneficiary.
- Turn the application result into a withdrawal liability in an accepted batch.
- Use the focused test as a conservation gate, then test refund and terminal-exit policies separately for your application.
Demo / use it today
Emulate an L1 → room → L1 liquidity pipeline
Use one coherent Foundry scenario to follow one actor, one token, and one amount from L1 deposit through room consumption and a DvP transition, then through checkpoint finalization to the beneficiary’s L1 claim.
Before you start
- A Bash-compatible shell: Linux, macOS, or WSL on Windows. The copyable commands use POSIX shell syntax.
- Docker Compose.
- The protocol repository at the listed commit; the pinned Foundry image supplies the EVM and compiler.
- Only local test balances are used; no public-network funds or wallet keys are needed.
Begin with the application escrow
The test mints one amount to one actor, deposits it for the same beneficiary, and consumes the matching inbox entry into room state. Every later assertion refers to that same identity, asset, and amount.
Turn the room result into an L1 liability
The application transition moves the conserved value through its DvP leg. The next accepted checkpoint publishes the corresponding withdrawal liability and advances the same room sequence.
Claim the same value back on L1
The beneficiary claims on L1, and the final assertions reconcile the actor, vault, withdrawal record, and total amount. The test also makes its always-accepting verifier fixture explicit so an accounting gate is never mistaken for a zk-proof gate.
Fetch and pin the public protocol
git clone https://github.com/zkdeal/zkdeal-protocol.git web3-protocol && \
git -C web3-protocol checkout 7a8420b078d3bc04f1b5ace9de1bd223e4626608Expected output shape
Cloning into 'web3-protocol'...
HEAD is now at 7a8420bRun the coherent conservation gate
cd web3-protocol && docker compose run --rm --entrypoint /bin/sh \
contracts-build -c 'forge test --deny warnings --match-contract LiquidityPipelineTest -vv'Expected output shape
Ran 1 test for test/LiquidityPipeline.t.sol:LiquidityPipelineTest
[PASS] test_l1RoomL1LiquidityPipelineConservesOneActorAssetAndAmount()
Suite result: ok. 1 passed; 0 failed; 0 skippedWhat this gives you: You get a fast, reproducible conservation gate for one user’s ordinary L1 → room → L1 path before attaching the application to a live prover.
Interactive validated I/O
Test one L1 to room to L1 liquidity pipeline
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-protocol.git web3-protocol && \
> git -C web3-protocol checkout 7a8420b078d3bc04f1b5ace9de1bd223e4626608
Cloning into 'web3-protocol'...
HEAD is now at 7a8420b
$ cd web3-protocol && docker compose run --rm --entrypoint /bin/sh \
> contracts-build -c 'forge test --deny warnings --match-contract LiquidityPipelineTest -vv'
Ran 1 test for test/LiquidityPipeline.t.sol:LiquidityPipelineTest
[PASS] test_l1RoomL1LiquidityPipelineConservesOneActorAssetAndAmount()
Suite result: ok. 1 passed; 0 failed; 0 skippedVideo 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.