安全
Dexter 是首家链上 prop 公司。交易者支付 $49、$99、$199 或 $299 购买挑战赛套餐,达到 +10% 目标且不突破 -4% 单日或 -8% 跟踪上限,即可获得 90 / 10 资金账户,其每一笔支付都发布在 Base 上。该出纳背后的安全模型决定利润分成是否能到账。本页阐明边界——单写入者运行时、分离的网关权限面、受证明门控的提款、对 $10K 以上动用 2-of-3 运营多签的金库控制、至少一名外部签署人的 3-of-5 治理、守护者暂停标志,以及每个已发布结算根上的争议与挑战窗口。更深入的机制详见随后三页。
权限被拆分到五个层次,使任何单一组件都无法仅凭自身主张移动国库价值或最终确认提款。每一层都有不同的签署人集合、不同的爆炸半径与不同的恢复路径。
| 安全边界 | 它保护什么 |
|---|---|
| 运行时纪律 | 成交、资金费率、清算与标记更新的单写入者排序;没有竞争性写入者可以改变交易所状态 |
| 网关边界 | 公开读取、已认证账户视图、已签名交易路由与运营者专用路由各自携带不同的认证——公开令牌永远不会触及国库面 |
| 证明与挑战轨道 | 提款仅对已发布根、匹配的 Merkle 证明、绑定的 nonce 以及已满足的争议窗口最终确认 |
| 金库与治理多签 | 对 $10K 以上的移动采用 2-of-3 运营多签;对参数与储备变更采用至少包含一名外部签署人的 3-of-5 治理与保险 |
| 监控与恢复 | 持续的数据源新鲜度、根活跃度、网关健康度与国库对账信号,守护者对其中任一项均拥有暂停权限 |
#安全不是单一控制平面
交易所状态通过单写入者运行时推进,该运行时拥有资金费率累计、标记更新、清算触发、偏斜控制以及结算状态的发布权限。其他任何组件都不被允许并行变更该状态,这是每个下游保证的前提——证明只能在确切存在一条规范历史可供其证明的情况下才被信任。
网关随后通过五个不同的权限面暴露该状态:匿名市场读取、钱包认证账户视图、已签名交易流、运营者专用遥测路由,以及同时需要签名与服务器端白名单的价值转移路由。一个面上签发的令牌不会被另一个面承认,因此被入侵的产品会话永远不会继承国库权限,而公开读取密钥永远不会继承运营者可见性。
在 Base 上,合约层添加了运行时无法覆盖的第二道边界。守护者暂停标志可以在单笔交易内停止存款、提款或整个结算管道。根守卫拒绝任何时间戳、nonce 或引用父节点与链上历史不一致的提交。欺诈验证者钩子与可配置的 disputeWindowSec 让可疑根保持在可被反驳的状态,直至窗口到期。它们共同保证当运行时条件过期、有争议或在审查中时,结算总是放缓或停止——即使运行时自身认为一切正常。
#为什么基于证明的退出很重要
USDC 仅在同一个区块上四个独立条件同时一致时离开金库:用户的 requestWithdraw nonce 存在于链上;运行时已将该请求纳入某个结算根;提交的 Merkle 证明根据该精确根重构了用户的叶子;disputeWindowSec 已经结束且没有成功挑战。运行时认为它欠你某个余额是不够的。合约必须独立校验已发布状态确实是这么说的。
这之所以重要,是因为路由认证与状态正确性是不同的威胁。被窃取的运营者密钥会让攻击者调用特权端点,但它无法针对叶子可公开重构的根伪造 Merkle 证明。有 bug 的运行时可能发布错误的根,但争议窗口通过 challengeRootFraudProof、challengeRootInvalidLeaf 或 challengeRootConflict,在任何 USDC 移动之前都让其保持可被反驳。两道边界必须同时失败,坏支付才会到账。
运行时保持单写入者
-> 网关暴露分离的认证面
-> 根与承诺上下文发布在 Base 上
-> 提款需要 nonce + 证明 + 根历史
-> disputeWindowSec 对欺诈证明挑战保持开放
-> 只有这样 finalizeWithdraw 才释放 USDC#实践中安全意味着什么
对资金交易者而言,安全模型决定了少数几件具体的事。低于 $5K 且不属于排行榜领奖台前三的利润分成提款会进入自动处理队列,目标是在 Sumsub 级 KYC 通过后 24 小时内释放。任何高于 $5K、任何领奖台前三的支付,以及任何首次累计高于 $50 的支付,都会被路由到运营多签的人工审核——与签署每一笔 $10K 以上国库移动相同的 2-of-3 阈值。来自 IR、KP、SY 与 CU 司法管辖区的钱包在请求时被屏蔽,每个请求在进入队列之前都会针对 OFAC、欧盟与英国制裁名单进行筛查。该流程没有任何部分是可选或可协商的。
对一个值得托付资金资本的平台,你应该预期:过期价格永远看起来不可交易、受约束的市场永远看起来不像 live、国库路由永远不继承公开读取的权限,且提款永远不仅基于运营者主张最终确认。Dexter 的设计目标是让故障响亮且可被反驳,而非沉默——并且每一次敏感过渡都必须同时经过不止一项健康假设。