STATE ROOTS, WITHDRAWALS, AND SETTLEMENT FLOW

Every state root the vault accepts is more than a balance snapshot. Five references travel with it, so a single root commitment binds not only what each account was worth but the entire context the runtime was operating under when the snapshot was sealed. A reviewer reading the contract later can reconstruct the exact configuration that produced any given payout.

#How settlement actually works

The vault contract retains the active root, the root id, and the surrounding commitments so the contract side carries an explicit, queryable record of every published exchange state. Settlement is therefore never resolved against what the runtime believes in the last second — it is resolved against a committed state that can be referenced from chain, challenged on chain, and proven against on chain. The runtime is fast; the vault is final.

Withdrawals are request-based and nonce-tracked. The user signs a withdrawal request on-chain, which mints an account nonce the contract tracks. The runtime picks that request up in the next publication cycle, includes it inside the snapshot that produces the next state root, and posts the root with the five bound references listed above. The user (or any wallet acting on their behalf) then calls the finalize step with the Merkle leaf, the proof path, and the matching nonce; the vault contract verifies the proof against the committed root, confirms the nonce is current, checks the proof window has elapsed, and releases USDC.

This is materially different from a model where an operator decides when funds leave. The runtime cannot release funds it failed to seal into a root. The vault cannot release against a root that has not passed its proof window. An operator with full keys to the runtime still cannot push a payout through without producing a coherent committed state plus a matching proof. That layering — request, root commitment, proof window, contract release — is what makes the on-chain payout path defensible without trusting any single actor.

 requestWithdraw(amount)
   -> on-chain account nonce is created
   -> runtime includes the request in the next snapshot
   -> state root + 4 bound commitments published on Base
   -> proof window opens (challenge period)
   -> user receives leaf data and Merkle proof from runtime
   -> finalizeWithdraw(leaf, proof, nonce)
        -> vault verifies proof against committed root
        -> vault verifies nonce matches account state
        -> vault confirms proof window has elapsed
        -> USDC released to wallet on Base

#Proofs, challenges, and failure handling

Proofs matter because the vault is not designed to trust runtime claims blindly. Between root publication and finalize, a proof window opens during which any party can dispute a questionable root or a malformed settlement transition. Root history is retained on-chain so a challenge can reference a specific commitment by id, not just a vague accusation. Guardian controls and pause flags can freeze further releases against a root under dispute. Fraud-verifier hooks and root-guard logic exist to make a bad state update visible and contestable before value leaves — not just to log it after the fact.

This does not justify claiming the system is unhackable. No serious venue should make that promise. It does justify saying that Dexter is engineered so a successful withdrawal requires four assumptions to hold at once: the runtime must publish a coherent state, the vault contract must accept the corresponding root, the request nonce must match the user's on-chain account state, and the proof path must verify against the committed root. A compromise of any single layer in isolation does not produce an unauthorized payout. That is the layered settlement model — fewer single points of failure, more places a dispute can intercept a bad outcome.

#Payout timeline you should expect

• Profit-share withdrawal (funded account, 90 / 10 split). Request from the cashier in-app against your funded equity. If KYC is already cleared on the wallet, the target is under 24 hours from request to USDC arriving on Base — request enters the next publication cycle, root posts, proof window elapses, finalize step releases. The first profit-share withdrawal triggers KYC if it has not been completed yet; plan 1–2 extra days the first time.
• Leaderboard cash. Posted at season close from the dedicated reward-pool contract, paid in a single batch transaction per bracket. Wallets that have already cleared KYC for a profit-share withdrawal do not re-verify. Podium finishes (top 3) are reviewed before the batch leaves treasury — every season, no exceptions — so a leaderboard exploit cannot bypass operations review by ranking #1.
• Referral cash. Paid monthly in batch on the first business day of the month, anchored to the upstream wallet. Every transfer carries the referee payment id and the Basescan tx hash, so the link between an attribution event and the USDC that landed in your wallet is end-to-end auditable.
• High-value withdrawals ($5K+). Any single request above $5,000 is reviewed by operations before the proof window opens. This adds a few hours but does not change the on-chain settlement path — the proof, the root reference, and the contract release are identical.

The proof-gated design has one important consequence: even with full access to the cashier and the runtime, operations cannot push a payout through that does not have a valid root reference and a matching Merkle proof. The cashier UI surfaces the published root id and the proof at finalize time; you can paste either into a Basescan read call and verify the on-chain release against the same root yourself. If the published bracket total on dexter.market disagrees with the sum of transactions out of the reward-pool address, the on-chain record is the truth and the dashboard is wrong — not the other way around. Vault accounting (how fees, insurance draws, and reward-pool funding move) is documented on Treasury and accounting.