ch03-09 DEEP token 在费用、staking、rebate 中的位置

先抓住结构

读“DEEP token 在费用、staking、rebate 中的位置”时先画边界。一个真实协议最容易读乱的地方，不是函数太多，而是不知道 Pool、Book、State、Vault 和 BalanceManager 各自负责哪一段。

先把架构坐标钉在这些文件上。读这一节时不需要展开所有实现，只要看清对象分工、入口函数和后续会反复回来的状态边界。

这些入口是架构地图上的锚点。先标注每个模块负责的状态，再顺着一次下单或结算回到具体函数。

DeepBookV3 中 DEEP 出现在三条路径：

下单费用：pay_with_deep 为 true 时，pool::place_order_int 从 deep_price 生成 OrderDeepPrice，order_info.calculate_partial_fill_balances 计算 DEEP fee。
治理和费率：state::process_create 根据 stake、交易量和 trade_params 计算 taker fee；state::process_stake、process_unstake 更新账户 stake 和治理投票权。
rebate 和销毁：state/history/governance 记录费用与 rebate，pool.move 也包含 DeepBurned 事件和 vault.withdraw_deep_to_burn 路径。

不要把 DEEP 仅理解成手续费代币。它同时影响用户费率、池治理、maker rebate 和协议统计。

DEEP 在 DeepBook 中不是普通展示积分。它会出现在 fee 支付选项、stake 与治理权重、rebate 历史和 burn 路径中；不同路径对应的余额方向和事件也不同。

阅读 DEEP 相关逻辑时先判断它是费用计价、实际支付资产、stake 资产还是统计字段。尤其是 pay_with_deep 打开时，订单结算会多一条 DEEP 资金线，需要与 base/quote 分开记录。