国库、保险与收入会计
Dexter 收取你的交易手续费之后资金的去向、保险储备如何由 50% 清算残余分配补给、赛季奖励池的资金来自何处,以及坏账亏损如何被吸收,是四条独立的会计流程——出于设计目的保持分离,使排行榜奖金、资金交易者利润分成提款、保险支取与国库行为永远不会互相干扰。运行时以 USD18 精度保留这些总额;调和器将增量推送到链上,使 Base 上的四个金库合约与交易所活动保持对齐,而无需在每个区块重新计算完整账本。下文精确说明每一项余额如何移动以及由哪些控制门控。
| 余额桶 | 在协议内的角色 |
|---|---|
| feesAccrued | 来自 maker/taker 手续费、资金费率价差以及挑战赛套餐入场的协议收入;进入 Base 上的运营国库合约 |
| insuranceReserve | 每笔清算残余的 50% 以及任何初始缓冲;吸收坏账溢出与承压结果,同时不触及用户抵押品或运营国库 |
| rewardPool | 在赛季开始时从运营国库注资到专用奖励池合约;支撑当前赛季已公布的排行榜档位 |
| 收入端余额 | 面向 DIP 持有人与收入分成接收方的参与挂钩会计层;叠加在手续费/保险会计之上,绝不叠加在用户抵押品之上 |
#协议自有价值如何处理
交易手续费、资金费率价差以及挑战赛套餐入场收入($49 / $99 / $199 / $299 套餐),从被收取的那一刻起就累计进入协议自有会计——它们绝不在用户抵押品金库内停留,也不会被用户提款逻辑触及。运行时在自身的会计模型中以 USD18 精度跟踪手续费与保险总额;调和器对增量进行快照,并仅通过 vaultAddFees、vaultAddInsurance 与 vaultSubInsurance 将这些增量推送到链上。因此金库合约从不尝试重新计算完整的交易所账本;它们记录对结算、治理与储备覆盖具有意义的协议自有余额。
保险与国库被有意不合并为一个"协议储备"数字。保险资本存在的目的是一项具体工作:吸收失败的资金账户的压力、剧烈清算的坏账溢出,以及清算在维持保证金之下完成时产生的清算后残余。每笔清算残余按 50% 归触发该例程的 keeper,50% 归保险储备 分配——keeper 激励与及时清算保持一致,同时储备从同一流中得到补充。相比之下,运营国库是可以通过受治理接收方路由的协议收入:赛季开始时的奖励池注资、薪资、基础设施支出、运营资金。将两者混为一谈会让运营行为意外耗尽保险,而独立会计以及保险支取的 3-of-5 外部签署人要求正是为防止这一点而设。
手续费虹吸路径是通往收入端会计的可选桥梁。当治理启用时,在同一调和 tick 上,feesAccrued 的配置份额会被虹吸进入下文描述的收入端层——但只在底层手续费增量已落入链上之后。虹吸绝不先于链上承诺运行。
引擎手续费 / 保险总额(USD18 精度)
-> 调和器相对上一个链上检查点对增量进行快照
-> 增量转换为抵押品单位
-> vaultAddFees (运营国库合约)
-> vaultAddInsurance (保险储备合约,+50% 残余)
-> vaultSubInsurance (保险支取,需要 3-of-5 外部签署人)
-> 可选手续费虹吸 -> 收入端会计层#收入端会计及其保持分离的原因
收入端会计层跟踪参与挂钩余额——DIP 持有人主张、收入分成接收方,以及治理日后启用的任何编程化分配规则。它叠加在上文描述的手续费与保险会计之上,并依赖底层这些数字的正确性。收入可以在明确规则下被虹吸、保留或路由进入收入端层,但该层本身不是托管。它是一个发布每参与者主张的会计层;在主张最终化之前,底层 USDC 仍存放在运营国库合约中。
正是这种分离让协议可以把收入、保险、国库与参与作为四件不同的事情来讨论——而非一个营销友好的"储备"数字。它也让安全审查更清晰。如果一项治理行为错误配置了某个参数,审阅者可以无需从日志推断就看到哪些桶受到影响、哪些没有。如果一次运行时故障产生了错误的手续费增量,链上对账缺口在下一个快照对比中可见,并且可以通过一次有针对性的 vaultAddFees 或 vaultSubInsurance 调用纠正,而不会扰动其他余额。
因此,财务模型是 Dexter 安全设计的一部分,不仅仅是其经济模型。四个金库地址、四套权限、四条独立会计流程,以及一条把它们全部绑回运行时总额的对账纪律——这就是让资金交易者、排行榜赢家、DIP 持有人与推荐钱包都能从同一个协议得到支付,而四条流程从不互相踩踏的原因。