Withdrawals & claims

A withdrawal moves value from ZUL back to Solana. It is the direction that cannot be trusted blindly: L1 must be convinced the exit really happened on L2. ZUL convinces it with an SMT inclusion proof against a settled state root, after a challenge window.

Flow

1. user    submits an L2 withdraw: burns wSOL (or locks ZUL
            for exit) and records the withdrawal in L2 state
2. settle  the batcher posts a settlement record whose
            state_root covers that withdrawal record
3. wait    the challenge window runs (24 h on the testnet
            config) — time for anyone to dispute the root
4. claim   the user (via the SDK or bridge UI) submits the
            claim on L1: a Merkle path proving the withdrawal
            record exists under the settled root
5. payout  the settlement program verifies the blake3 path
            on-chain and releases:
            SOL  → from the vault PDA
            ZUL  → minted as SPL-ZUL (bridge PDA is mint authority)

Why the window exists

The root being claimed against is an optimistic assertion by the sequencer. The window is the period in which a wrong root can be called out before value leaves L1 — at stage 0 the calling-out is procedural (anyone can recompute from DA; rejection is operational), which is exactly why the window is conservative. Enforced fraud proofs shorten nothing by themselves, but they turn the window's guarantee from social to cryptographic. See Trust model.

Properties

• Self-service claims— the proof is fetched from the node and verified by the L1 program; claiming does not require the sequencer's cooperation once the root is settled.
• One claim per withdrawal — claims are keyed to the withdrawal record; replays fail.
• Cross-pinned hashing— the L1 verifier's blake3 SMT is byte-pinned to the node's implementation by shared constants and a cross-test, because two implementations of one tree is where bridges quietly break.