VAULT AND TREASURY
Dexter separates custody, treasury, insurance, and income-side accounting on purpose.
These balances do not answer the same question and should not move under the same permissions.
| Layer | What it holds | How it is meant to move |
|---|---|---|
| User collateral | Deposit-backed user balances and withdrawal requests | Through vault settlement rules and proof-based withdrawal flow |
| Treasury | Protocol-owned fee balances | Through governed treasury actions |
| Insurance reserve | Protocol reserve buffer for stressed conditions | Through explicit reserve accounting and controlled adjustments |
| Income-side accounting | Participation-linked balances | Through income-pool accounting rules, not through custody logic |
#Custody, settlement, and protocol balances
User collateral is held in the vault system.
Deposits, withdrawal requests, nonce tracking, and final withdrawal execution all pass through contract logic rather than through the exchange runtime alone.
That is the first architectural point that matters.
The runtime can coordinate markets quickly, but it cannot simply rewrite custody outcomes because those outcomes are tied to contract-side state and contract-side permissions.
The vault does more than hold token balances.
It also stores the settlement references that describe what the runtime believed when a state update was published.
That can include the active state root, the root id, the timestamp, the schema version, the sequence commitment, the oracle-source hash, and the order-batch commitment.
Root history remains available so settlement can be tied back to a specific published exchange state instead of to a vague statement that the operator says the ledger changed.
The same system also keeps protocol-owned balances separate.
Fees accrued by trading activity are protocol revenue.
Insurance reserves are the protocol reserve buffer for stressed conditions.
Income-side accounting belongs to a participation layer.
None of these balances should be treated as user margin, and none of them should move under the same assumptions as a user withdrawal.
#Why custody and protocol value stay separate
The purpose of this design is not to claim that a vault is magically impossible to attack.
No serious venue should promise that.
The purpose is to make a compromise in one layer less powerful than a compromise of the whole system.
If the runtime is degraded, the custody layer still keeps explicit withdrawal rules.
If a treasury action is needed, it moves through separate recipients, pause flags, and governed permissions.
If the protocol later routes part of revenue into income-side accounting, that route is still separate from user collateral and separate from insurance reserves.
This is what makes the vault and treasury architecture readable under stress.
A reviewer should be able to answer three questions without guessing: where user funds are held, what belongs to the protocol, and which controls must be satisfied before those balances can move.