STATE ROOTS, WITHDRAWALS, AND SETTLEMENT FLOW
Withdrawals advance from request to release only after root reference, proof, and challenge rules line up.
A withdrawal enters the settlement queue.
The claim binds to a committed balance snapshot.
The vault only releases collateral after proof and posture checks pass.
Invalid claims can be contested before final release.
Only verified settlement can leave the vault.
| Stored reference | Why it exists |
|---|---|
| State root | Anchors the published account state |
| Root id and timestamp | Ties settlement to a specific publication event |
| Sequence commitment | Binds ordering and publication context |
| Oracle-source hash | Binds the price-source posture used for the root |
| Order-batch commitment | Binds the batch context surrounding that state |
#How settlement actually works
The vault stores the active root, the root id, and the surrounding settlement references so the contract side has an explicit record of published exchange state.
Root history matters because settlement should not depend on whatever the runtime happens to believe in the latest moment.
It should depend on a committed state that can be referenced, challenged, and proven against.
Withdrawals are therefore request-based and nonce-tracked.
A user first creates a withdrawal request on-chain.
The engine later includes that request inside the next published settlement state.
The user can then finalize the withdrawal against the committed root using the relevant proof data and nonce history.
That is materially different from a model where an operator simply decides when funds leave.
It ties the withdrawal path to a state commitment, a request sequence, and a proof-bearing settlement record.
requestWithdraw(amount)
-> on-chain nonce is created
-> runtime includes the request in the next snapshot
-> state root and commitments are published
-> user receives leaf data and Merkle proof
-> finalizeWithdraw(...) verifies proof, nonce, and root context#Proofs, challenges, and failure handling
The reason proofs matter is simple: the vault is not supposed to trust runtime claims blindly.
The protocol stores root history and carries challenge and invalidation controls so a questionable root or settlement transition can be disputed before value leaves the system.
Guardian controls, pause flags, dispute settings, fraud-verifier hooks, and root-guard logic all exist for the same reason.
They narrow the circumstances in which a bad state update could become a bad withdrawal outcome.
This still does not justify saying the system is unhackable.
It does justify saying that Dexter is designed so withdrawals require more than one healthy assumption at the same time.
The runtime has to publish a coherent state.
The vault has to accept the relevant root.
The request nonce has to line up.
The proof path has to match the committed state.
That layered settlement model is the core of Dexter's custody story.