VAULT AND TREASURY

The four balances answer four different questions and move under four different sets of permissions. The table is the contract layout, not a marketing abstraction — each row is a deployed address on Base with its own signer policy and its own accounting trail.

#Custody, settlement, and protocol balances

User collateral is held in the dedicated vault contract on Base. Deposits, withdrawal requests, the per-account nonce trail, and the finalize step that releases USDC back to the wallet all pass through contract logic — never through the runtime alone. The runtime is fast enough to coordinate matching and risk in real time, but it cannot rewrite custody outcomes, because every release is gated by a Merkle proof against a state root the vault contract has already accepted. The full request-to-release flow is documented on Settlement and withdrawals; what matters here is that the runtime and the vault are deliberately decoupled.

The vault stores more than token balances. It also stores the settlement references that describe what the runtime believed when each state update was sealed: the active state root, the root id, the publication timestamp, the schema version, the sequence commitment, the oracle-source hash from the price layer, and the order-batch commitment. Root history is retained on-chain so any settlement transaction can be tied back to a specific published exchange state — not to a vague claim that the operator says the ledger changed.

The other three vault addresses live in parallel, with their own permission policies and their own accounting buckets. Operating treasury holds fee revenue from trading activity. Insurance reserve holds the 50% liquidation-residual share plus any seeded buffer used to absorb stressed outcomes — the other 50% of every liquidation residual goes to the keeper that triggered the routine. Reward pool holds posted leaderboard cash for the active season, funded before the season opens so the bracket cannot be silently reduced mid-season. None of these are user margin, and none of them release under user-withdrawal rules.

#Why custody and protocol value stay separate

This architecture does not claim the vault is impossible to attack — no serious venue should promise that. It does make any single compromise less powerful than a compromise of the whole system. A runtime fault cannot move user collateral, because the vault only releases against a proof matching an already-accepted root. A signer compromise on the operating treasury cannot pay out the reward pool, because the reward pool is a different contract with a different signer set. A spike of liquidations on a single funded account cannot drain the operating treasury, because the loss draws from insurance under a separate accounting bucket.

Permission policy is explicit at each layer. Operating treasury outflows above $10K require 2-of-3 multi-sig from the operations group. Insurance reserve draws require 3-of-5 multi-sig that must include an external signer outside the operations group, so an insider-only quorum cannot deplete the reserve. Governance actions — parameter changes, contract upgrades, recipient changes — run on the same 3-of-5 external-signer requirement. Pause flags and root-guard logic give the contract layer a way to freeze releases while a dispute or incident is investigated, without those flags also enabling unilateral movement.

The result is a layout a reviewer can read in three questions: where is user money (the collateral vault, released by proof), what belongs to the protocol (operating treasury and insurance reserve, with their own signer policies), and what must be true before any balance moves (the on-chain rules listed above). No part of the answer requires trusting the operator's word.

#How this protects your payouts

• Your collateral cannot fund someone else's payout. The user collateral vault releases USDC only against a published state root and a matching Merkle proof. The operating treasury cannot reach into it to cover a leaderboard bracket, a referral cash batch, or an insurance shortfall. The cashier UI shows the root id and proof at finalize time; you can verify the on-chain release against the same root yourself on Basescan.
• Insurance is a separate contract with its own signer policy. Every liquidation residual is split 50% to the keeper that triggered it, 50% to insurance. Bad-debt spillover from a failed funded account draws on insurance, not on the operating treasury and not on user collateral — which is why a chain of liquidations does not slow down legitimate withdrawals. Insurance draws themselves require 3-of-5 multi-sig including an external signer.
• The reward pool is funded at season open, not at season close. Leaderboard cash for the active season is moved into the dedicated reward-pool contract before the season opens. The published brackets ($X for #1, $Y for #2–3, etc.) cannot be quietly reduced mid-season because the cash is no longer in the operating wallet. Podium finishes (top 3) are reviewed before the season-close batch transaction leaves treasury; single withdrawals above $5K trigger the same high-value review.
• Multi-sig gates every protocol-side movement. Operating treasury outflows above $10K require 2-of-3; insurance reserve draws and governance actions require 3-of-5 with an external signer. Every transaction is posted on Base, so a sudden movement out of any of the four vaults is visible to anyone watching the address.

Each vault address is published on the security controls page and can be pinned to a Basescan watchlist. If the dexter.market "Verified Rewards" leaderboard total ever disagrees with the sum of transactions out of the reward pool address, the on-chain record wins — and you will see the discrepancy before we tell you about it. The settlement mechanics that release user collateral are documented on Settlement and withdrawals; the accounting flows for fees and insurance are documented on Treasury and accounting.