Whitepaper / TREASURY, INSURANCE, AND INCOME ACCOUNTING
Dexter whitepaper

TREASURY, INSURANCE, AND INCOME ACCOUNTING

Where the money goes after Dexter collects your trade fee, how the insurance reserve is fed by the 50% liquidation-residual split, where the season reward pool is funded from, and how bad-debt losses are absorbed are four separate accounting flows — kept separate by design so a leaderboard prize, a funded-trader profit-share withdrawal, an insurance draw, and a treasury action never interfere with each other. The runtime keeps these totals in USD18 precision; a reconciler pushes the deltas on-chain so the four vault contracts on Base stay aligned with exchange activity without recomputing the full ledger every block. Below is exactly how each balance moves and which controls gate it.

Page last sync: May 24, 2026
Sections 2 Read 1 min Whitepaper chapter
Balance bucket Role inside the protocol
feesAccrued Protocol revenue from maker/taker fees, funding spread, and challenge-pack entry; lands in the operating treasury contract on Base
insuranceReserve 50% of every liquidation residual plus any seeded buffer; absorbs bad-debt spillover and stressed outcomes without touching user collateral or operating treasury
rewardPool Funded at season open from operating treasury into the dedicated reward-pool contract; backs the published leaderboard brackets for the active season
Income-side balances Participation-linked accounting surface for DIP holders and revenue-share recipients; layered on top of fee/insurance accounting, never on top of user collateral

#How protocol-owned value is handled

Trading fees, funding spread, and challenge-pack entry revenue ($49 / $99 / $199 / $299 packs) accrue into protocol-owned accounting from the moment they are collected — they never sit inside the user collateral vault and never get touched by user-withdrawal logic. The runtime tracks fee and insurance totals in USD18 precision in its own accounting model; a reconciler snapshots the deltas and pushes only those deltas on-chain via vaultAddFees, vaultAddInsurance, and vaultSubInsurance. The vault contracts therefore never try to recompute the full exchange ledger; they record the protocol-owned balances that matter for settlement, governance, and reserve coverage.

Insurance and treasury are deliberately not collapsed into one "protocol reserve" number. Insurance capital exists for a specific job: absorb the stress of failed funded accounts, bad-debt spillover from violent liquidations, and the post-liquidation residual when a liquidation closes below maintenance. Every liquidation residual is split 50% to the keeper that triggered the routine, 50% to the insurance reserve — keeper incentives stay aligned with timely liquidations while the reserve refills from the same flow. Operating treasury, by contrast, is protocol revenue that can be routed through governed recipients: reward-pool funding at season open, payroll, infrastructure spend, runway. Conflating them would let an operations action accidentally deplete insurance, which is exactly what the separate accounting and the 3-of-5 external-signer requirement on insurance draws prevent.

The fee-siphon path is the optional bridge into income-side accounting. When governance enables it, a configured share of feesAccrued is siphoned on the same reconciliation tick into the income-side layer described below — but only after the underlying fee delta has landed on-chain. The siphon never operates ahead of the on-chain commitment.

TEXT
 engine fee / insurance totals (USD18 precision)
   -> reconciler snapshots deltas vs last on-chain checkpoint
   -> deltas converted to collateral units
   -> vaultAddFees      (operating treasury contract)
   -> vaultAddInsurance (insurance reserve contract, +50% residual)
   -> vaultSubInsurance (insurance draw, requires 3-of-5 external signer)
   -> optional fee siphon -> income-side accounting layer

#Income-side accounting and why it stays separate

The income-side accounting layer tracks participation-linked balances — DIP holder claims, revenue-share recipients, and any future programmatic distribution rule governance enables. It sits on top of the fee and insurance accounting described above and depends on those numbers being correct underneath it. Revenue can be siphoned, reserved, or routed into the income-side layer under explicit rules, but the layer itself is not custody. It is an accounting surface that publishes per-participant claims; the underlying USDC still lives in the operating treasury contract until a claim is finalized.

This separation is what lets the protocol talk about revenue, insurance, treasury, and participation as four distinct things — not as one marketing-friendly "reserve" number. It also makes security review cleaner. If a governance action misconfigures one parameter, the reviewer can see which buckets are affected and which are not without inferring from logs. If a runtime fault produces a wrong fee delta, the on-chain reconciliation gap is visible against the next snapshot and can be corrected by a targeted vaultAddFees or vaultSubInsurance call without disturbing the other balances.

The finance model is therefore part of Dexter's safety design, not just its economics. Four vault addresses, four sets of permissions, four independent accounting flows, and one reconciliation discipline that ties them all back to the runtime totals — that is what lets a funded trader, a leaderboard winner, a DIP holder, and a referral wallet all be paid out of the same protocol without the four flows ever stepping on each other.