WITHDRAWAL PROOFS, DISPUTES, AND ROOT CHALLENGES

Page last sync: March 21, 2026

Sections 2 Read 1 min Whitepaper chapter

Mechanism	What it protects
requestWithdraw nonce	Binds user intent to an explicit on-chain request
State root history	Preserves the settlement state that withdrawals must point to
Merkle proof	Proves the account leaf against a committed root
disputeWindowSec	Creates time for challenge before finalization
challengeRootFraudProof	Challenges a root through fraud-verifier logic
challengeRootInvalidLeaf	Challenges a malformed or inconsistent leaf
challengeRootConflict	Challenges inconsistent roots or conflicting history

#The withdrawal path is proof-gated

A user first creates an on-chain withdrawal request.

The runtime later includes that request in the next published settlement state. Only after the relevant root is committed, the proof path is available, and the dispute conditions are satisfied can the withdrawal finalize.

That means the withdrawal path depends on more than one statement being true at once.

The request nonce has to exist.

The published root has to exist in history.

The proof has to match the committed state.

The dispute window has to be satisfied.

TEXT

 requestWithdraw(amount)
   -> nonce is created on-chain
   -> runtime includes request in the next published state
   -> root history is updated
   -> user receives leaf data and Merkle proof
   -> finalizeWithdraw(...) verifies proof, nonce, and root context

#Why challenges and fraud proofs exist

Dexter's settlement model is not secure just because roots are published.

It is secure only if questionable roots can still be challenged before value leaves the vault.

That is why the system carries dispute windows, fraud verifiers, and challenge methods such as challengeRootFraudProof, challengeRootInvalidLeaf, and challengeRootConflict.

Those controls narrow the circumstances in which a bad publication could become a bad withdrawal outcome.

The result is a settlement path that is not based on trusting a runtime claim in isolation. It is based on committed state, proof verification, root history, and the ability to dispute a bad state before funds finalize.