TREASURY, INSURANCE, AND INCOME ACCOUNTING
| Balance bucket | Role inside the protocol |
|---|---|
| feesAccrued | Tracks protocol revenue created by trading activity |
| insuranceReserve | Tracks capital used to absorb stressed outcomes |
| Income-side balances | Track participation-linked accounting separately from custody |
#How protocol-owned value is handled
Trading fees accrue into protocol-owned accounting from the start.
Those balances are separate from user collateral before any treasury action is ever taken.
The off-chain engine tracks fee and insurance totals in its own accounting model, and a reconciler later pushes only the required deltas on-chain so the vault-side balances remain aligned with exchange activity.
That means the vault is not trying to recompute the whole exchange ledger on-chain.
It is recording the protocol-owned balances that matter for settlement and governance.
Insurance reserves are also tracked separately because they serve a different purpose.
Insurance capital exists to absorb stress and bad-debt spillover.
Treasury balances exist for protocol-owned value that may later move through governed recipients and governance-controlled actions.
Those two things should never be described as one generic reserve.
engine fee / insurance totals (USD18)
-> reconciler snapshots deltas
-> deltas are converted into collateral units
-> vaultAddFees / vaultAddInsurance / vaultSubInsurance
-> optional fee siphon updates the income-side layer#Income-side accounting and why it stays separate
Dexter also maintains an income-side accounting layer for participation-linked balances.
This layer depends on fee and reserve accounting being correct underneath it.
Revenue may be siphoned, reserved, or routed into that layer under explicit rules, but that still does not turn the income-side model into custody.
It remains a separate accounting surface.
That separation is what lets the protocol talk clearly about revenue, insurance, treasury, and participation without collapsing them into one marketing phrase.
It also improves security review.
If one value bucket is misconfigured, the reviewer should still be able to see which other balances remain unaffected.
In other words, the finance model is part of the protocol's safety design, not only part of its economics.