金库与国库

这四份余额回答四个不同的问题,并在四套不同的权限下移动。该表是合约布局,而不是营销抽象——每一行都是 Base 上的一个已部署地址,带有自己的签署人策略与自己的会计记录。

#托管、结算与协议余额

用户抵押品保存在 Base 上的专用金库合约中。存款、提款请求、每账户 nonce 记录,以及将 USDC 释放回钱包的最终确认步骤,都经过合约逻辑——绝不仅由运行时单独处理。运行时足够快可以实时协调撮合与风控,但它无法改写托管结果,因为每次释放都受到针对金库合约已接受状态根的 Merkle 证明门控。完整的请求到释放流程记录于 结算与提款;此处的要点是运行时与金库被有意解耦。

金库存储的不只是代币余额。它还存储描述运行时在每次状态更新被封存时所信内容的结算引用:激活的状态根、根 id、发布时间戳、 schema 版本、序列承诺、来自价格层的预言机来源哈希,以及订单批次承诺。根历史在链上保留,因此任何结算交易都可以与一个具体的已发布交易所状态绑定——而不是与运营者声称账本已改变的模糊主张绑定。

另外三个金库地址并行存在,带有各自的权限策略与会计桶。运营国库持有交易活动产生的手续费收入。保险储备持有 50% 清算残余份额,以及用于吸收承压结果的任何初始缓冲——每次清算残余的另外 50% 归触发该例程的 keeper。奖励池持有当前赛季已公布的排行榜现金,在赛季开始前完成注资,以确保档位无法在赛季中悄悄削减。这些都不是用户保证金,且没有一个按用户提款规则释放。

#为什么托管与协议价值保持分离

此架构并不声称金库无法被攻击——没有严肃的平台应该作出此类承诺。它做到的是让任何单点入侵的破坏力低于对整个系统的入侵。运行时故障无法移动用户抵押品,因为金库只对匹配已接受根的证明释放。运营国库上的签署人入侵无法支付奖励池,因为奖励池是一个带有不同签署人集的不同合约。某个资金账户上一次清算飙升无法抽干运营国库,因为损失在单独的会计桶下从保险中支取。

权限策略在每一层都明确。运营国库超过 $10K 的流出需要运营组的 2-of-3 多签。保险储备支取需要 3-of-5 多签,且必须包含运营组之外的外部签署人,因此仅由内部人构成的法定人数无法耗尽该储备。治理行为——参数变更、合约升级、接收方变更——遵循同样的带外部签署人的 3-of-5 要求。暂停标志与根守卫逻辑为合约层提供了在争议或事件调查期间冻结释放的方式,而这些标志同时不允许任何单方面移动。

结果是一种审阅者可以通过三个问题来读懂的布局:用户资金在哪里(抵押品金库,由证明释放)、什么属于协议(运营国库与保险储备,带有各自的签署人策略),以及在任何余额移动之前必须为真什么(上面列出的链上规则)。答案的任何部分都不需要相信运营者的话。

#这如何保护你的支付

• 你的抵押品无法为别人的支付提供资金。用户抵押品金库仅对已发布状态根与匹配的 Merkle 证明释放 USDC。运营国库无法伸手进入其中,以填补排行榜档位、推荐现金批次或保险缺口。出纳 UI 在最终确认时显示根 id 与证明;你可以在 Basescan 上自行核对针对同一根的链上释放。
• 保险是一个带有自身签署人策略的独立合约。每一笔清算残余按 50% 归触发它的 keeper,50% 归保险 分配。失败的资金账户产生的坏账溢出由保险吸收,而非由运营国库或用户抵押品承担——正因如此,一连串清算不会拖慢合法提款。保险支取本身需要包含外部签署人的 3-of-5 多签。
• 奖励池在赛季开始时注资,而非赛季结束时。当前赛季的排行榜现金在赛季开始前移入专用奖励池合约。已公布的档位($X 给 #1、$Y 给 #2–3 等)无法在赛季中被悄悄削减,因为现金已不在运营钱包中。领奖台(前 3 名)结果在赛季结束的批次交易离开国库前完成审核;超过 $5K 的单笔提款触发同样的高价值审核。
• 多签门控每一次协议端的移动。运营国库超过 $10K 的流出需 2-of-3;保险储备支取与治理行为需带外部签署人的 3-of-5。每一笔交易都在 Base 上公布,因此从这四个金库中任何一个突然流出的资金,对监视该地址的任何人都是可见的。

每个金库地址都公布在安全控制页面上,并可以固定到 Basescan 监视列表。如果 dexter.market 的"已验证奖励"排行榜总额与奖励池地址流出交易之和不一致,则以链上记录为准——而且你会先于我们告知之前看到差异。释放用户抵押品的结算机制记录于 结算与提款;手续费与保险的会计流程记录于 国库与会计。