SECURITY
Dexter is the first on-chain prop firm. Traders pay $49, $99, $199, or $299 for a challenge pack, hit the +10% target without breaching the -4% daily or -8% trailing limits, and receive a 90 / 10 funded account whose every payout posts on Base. The security model behind that cashier is what determines whether the profit share lands. This page sets out the boundaries — a single-writer runtime, separated gateway permission surfaces, proof-gated withdrawals, multi-sig vault controls with a 2-of-3 operations threshold above $10K and 3-of-5 governance with at least one external signer, guardian pause flags, and dispute and challenge windows on every published settlement root. The deeper mechanics live on the three pages that follow.
Authority is split across five layers so no single component can move treasury value or finalize a withdrawal on its own assertion. Each layer has a different signer set, a different blast radius, and a different recovery path.
| Security boundary | What it protects |
|---|---|
| Runtime discipline | Single-writer ordering on fills, funding, liquidations, and mark updates; no competing writers can alter exchange state |
| Gateway boundaries | Public reads, authenticated account views, signed trading routes, and operator-only routes each carry distinct auth — a public token never reaches a treasury surface |
| Proof and challenge rails | Withdrawals finalize only against a published root, a matching Merkle proof, a bound nonce, and a satisfied dispute window |
| Vault and governance multi-sig | 2-of-3 operations multi-sig on movements above $10K; 3-of-5 governance and insurance with at least one external signer for parameter and reserve changes |
| Monitoring and recovery | Continuous feed-freshness, root-liveness, gateway-health, and treasury-reconciliation signals with guardian pause authority on any one of them |
#Security is not one control plane
Exchange state advances through a single-writer runtime that owns funding accruals, mark updates, liquidation triggers, skew control, and the publication of settlement state. Nothing else is allowed to mutate that state in parallel, which is the prerequisite for every downstream guarantee — a proof can only be trusted if there is exactly one canonical history it can prove against.
The gateway then exposes that state through five distinct permission surfaces: anonymous market reads, wallet-authenticated account views, signed trading flow, operator-only telemetry routes, and value-transfer routes that require both signature and a server-side allowlist. No token issued for one surface is honored by another, so a compromised product session never inherits treasury authority and a public read key never inherits operator visibility.
On Base, the contract layer adds a second perimeter that the runtime cannot override. Guardian pause flags can halt deposits, withdrawals, or the entire settlement pipeline within a single transaction. Root guards reject any commit whose timestamp, nonce, or referenced parent disagrees with on-chain history. Fraud-verifier hooks and the configurable disputeWindowSec keep questionable roots in a contestable state until the window expires. Together they guarantee that settlement always slows or stops when runtime conditions are stale, disputed, or under review — even if the runtime itself believes everything is fine.
#Why proof-based exits matter
USDC leaves the vault only when four independent conditions agree at the same block: the user's requestWithdraw nonce exists on-chain, the runtime has included that request in a settlement root, the submitted Merkle proof reconstructs the user's leaf against that exact root, and disputeWindowSec has elapsed without a successful challenge. A balance the runtime believes it owes you is not sufficient. The contract must independently verify that the published state actually says so.
This matters because route authentication and state correctness are different threats. A stolen operator key would let an attacker call privileged endpoints, but it cannot fabricate a Merkle proof against a root whose leaves are publicly reconstructable. A buggy runtime might publish a wrong root, but the dispute window keeps it contestable through challengeRootFraudProof, challengeRootInvalidLeaf, or challengeRootConflict before any USDC moves. Both perimeters have to fail at once for a bad payout to land.
runtime stays single-writer
-> gateway exposes separated auth surfaces
-> root and commitment context are published on Base
-> withdrawals require nonce + proof + root history
-> disputeWindowSec stays open for fraud-proof challenges
-> only then does finalizeWithdraw release USDC#What security means in practice
For a funded trader, the security model determines a small number of concrete things. Profit-share withdrawals up to $5K and outside the leaderboard podium top three are queued for automated processing and target release within 24 hours of Sumsub-class KYC clearing. Anything above $5K, any podium top-three payout, and any first-time payout above $50 cumulative are routed to manual review by the operations multi-sig — the same 2-of-3 threshold that signs every treasury movement above $10K. Wallets from the IR, KP, SY, and CU jurisdictions are blocked at request time, and every request is screened against OFAC, EU, and UK sanctions lists before it reaches the queue. Nothing about that flow is optional or negotiable.
What you should expect from a venue worth trusting with funded capital: a stale price never looks tradable, a constrained market never looks live, a treasury route never inherits a public read's permissions, and a withdrawal never finalizes on an operator assertion alone. Dexter is designed so failure is loud and contestable instead of silent — and so every sensitive transition has to pass through more than one healthy assumption at the same time.