SECURITY
Security in Dexter comes from explicit boundaries, narrow permissions, proof-based exits, and failure states that are visible instead of hidden.
The runtime, gateway, monitoring layer, and contracts do not all have the same authority, and that split is what keeps one unhealthy component from automatically owning the whole system.
| Security boundary | What it protects |
|---|---|
| Runtime discipline | Ordered exchange state and single-writer coordination |
| Gateway boundaries | Public reads, authenticated views, and protected operator routes with separate auth paths |
| Proof and challenge rails | Withdrawals cannot finalize on unproven or disputed state |
| Contract controls | Custody, treasury movement, and governed configuration |
| Monitoring and recovery | Early detection of stale, degraded, or disputed conditions |
#Security is not one control plane
The exchange state advances through a narrow write path.
Funding, liquidation, mark updates, skew controls, and publication all move through one runtime flow rather than through competing writers.
The gateway then exposes that state through separate permission surfaces instead of giving every route the same authority.
Public market reads, authenticated account views, governed value-transfer paths, protected operator routes, and monitoring routes should not collapse into one token or one session model.
The contract side remains stricter still.
Pause flags, guardian powers, governance ownership, root guards, dispute settings, and verification hooks exist so settlement can slow down or stop when runtime conditions are stale, disputed, or under review.
#Why proof-based exits matter
User collateral does not leave the system because the runtime claims a balance exists.
It leaves only when a withdrawal request, a committed root, a nonce path, and a Merkle proof all line up inside the vault's settlement rules.
Challenge windows and fraud-proof hooks exist so a questionable root can be disputed before it becomes a completed withdrawal outcome.
runtime stays single-writer
-> gateway exposes separated auth surfaces
-> root and commitment context are published
-> withdrawals require nonce + proof + root history
-> dispute and fraud-proof rails stay available before finalizationThat is why proof and challenge rails belong in the main security story, not only in the settlement chapter.
Route auth protects who can request a sensitive action.
Proof and dispute protect whether the claimed state is valid enough to settle at all.
#What security means in practice
Dexter is not designed around the claim that nothing can fail.
It is designed so failure becomes legible before it becomes catastrophic.
A stale price should not still look tradable.
A constrained market should not still look live.
A treasury-sensitive path should not behave like a public read.
A withdrawal path should not finalize on an unchallenged operator assertion alone.
A secure venue is one that keeps authority narrow and makes sensitive transitions pass through more than one healthy assumption at the same time.