状态根、提款与结算流程
本页解释 USDC 实际上如何离开 Dexter 并到达你在 Base 上的钱包。每一笔支付——你 90% 的资金交易者利润分成、赛季结束的排行榜档位现金、每月的推荐批次——都流经同一条链上结算管道:请求以你的账户 nonce 进入队列;运行时将其纳入下一个状态根并将该根发布到 Base 上;证明窗口打开,期间可对无效根提出挑战;一旦证明匹配,金库合约释放抵押品。每一步都由不同的机制门控,任何单独一步本身都无法将支付推过去。下文说明每一步做什么、为什么受证明门控的释放意味着支付不会被悄悄拖延、拒绝或改道,以及你应对每种支付类型预期的现实时间线。
只有当根引用、证明与挑战规则全部对齐后,提款才会从请求推进到释放。
提款进入结算队列。
该主张绑定于已提交的余额快照。
金库仅在证明与姿态检查通过后才释放抵押品。
无效主张可在最终释放前被反驳。
只有经过校验的结算才能离开金库。
金库接受的每一个状态根都不只是余额快照。它附带五项引用,因此单一根承诺不仅绑定每个账户的价值,还绑定快照被封存时运行时所运行的全部上下文。日后审阅合约的审阅者可以重构产生任意支付的精确配置。
| 已存储的引用 | 它存在的原因 |
|---|---|
| 状态根 | 发布时所有账户余额与待处理提款请求的 Merkle 根;即你最终确认所对应的叶子 |
| 根 id 与时间戳 | 标识封存该快照的发布事件,在链上排序,使结算绑定于具体承诺并无法被追溯重新指派 |
| 序列承诺 | 绑定运行时处理进入该快照的事件顺序——不允许事后插入交易 |
| 预言机来源哈希 | 产生该快照所基于的价格层姿态(活跃发布者、回退启用情况、市场姿态)的哈希,与出纳释放所对应的同一根绑定 |
| 订单批次承诺 | 绑定发布窗口内处理的订单批次,使供给该根的交易日后无法被改写 |
#结算实际如何运作
金库合约保留激活的根、根 id 以及周边承诺,因此合约端持有每一个已发布交易所状态的明确、可查询记录。因此结算永远不会基于运行时最后一秒所信的内容来裁决——它基于一份可从链上引用、在链上挑战并在链上证明的已提交状态裁决。运行时是快速的;金库是最终的。
提款基于请求并以 nonce 跟踪。用户在链上签署一次提款请求,生成由合约跟踪的账户 nonce。运行时在下一个发布周期取走该请求,将其纳入产生下一个状态根的快照中,并附带上文列出的五项绑定引用发布该根。用户(或代表其行动的任何钱包)随后以 Merkle 叶、证明路径以及匹配的 nonce 调用最终确认步骤;金库合约根据已提交的根校验证明、确认 nonce 与账户状态当前一致、检查证明窗口已结束,并释放 USDC。
这与运营者决定资金何时离场的模型有本质区别。运行时无法释放它未封存进根的资金。金库无法对未通过其证明窗口的根释放。即使拥有运行时全部密钥的运营者,在没有产生一致已提交状态加匹配证明的情况下,也无法将支付推过去。这种分层——请求、根承诺、证明窗口、合约释放——使链上支付路径可在不信任任何单一参与者的前提下得到辩护。
requestWithdraw(amount)
-> 链上账户 nonce 被创建
-> 运行时在下一个快照中纳入该请求
-> 状态根 + 4 项绑定承诺发布在 Base 上
-> 证明窗口打开(挑战期)
-> 用户从运行时接收叶子数据与 Merkle 证明
-> finalizeWithdraw(leaf, proof, nonce)
-> 金库根据已提交根校验证明
-> 金库校验 nonce 与账户状态匹配
-> 金库确认证明窗口已结束
-> USDC 释放到 Base 上的钱包#证明、挑战与故障处理
证明之所以重要,是因为金库的设计并不盲目信任运行时的主张。在根发布与最终确认之间,会开启一个证明窗口,任何一方都可以在其中对可疑的根或畸形的结算过渡提出争议。根历史保留在链上,因此挑战可以按 id 引用具体承诺,而非仅是模糊指控。守护者控制与暂停标志可以在争议根仍未解决时冻结进一步释放。欺诈验证者钩子与根守卫逻辑存在的目的,是让坏的状态更新在价值离场之前可见且可被反驳——而非仅在事后记录。
这并不能用来声称该系统不可被攻破。没有严肃的平台应当作出这种承诺。它能用来说明的是:Dexter 经过精心设计,使一笔成功的提款必须同时满足四项假设——运行时必须发布一致的状态、金库合约必须接受相应的根、请求 nonce 必须与用户的链上账户状态匹配,以及证明路径必须根据已提交根校验通过。任意单层的孤立入侵不会产生未经授权的支付。这正是分层结算模型——更少的单点故障,更多的可以由争议拦截不良结果的位置。
#你应该预期的支付时间线
- 利润分成提款(资金账户,90 / 10 分配)。在 app 内的出纳上基于你的资金权益请求。如果钱包已经完成 KYC,目标是从请求到 USDC 到达 Base 不到 24 小时——请求进入下一个发布周期、根发布、证明窗口结束、最终确认步骤释放。如果尚未完成 KYC,第一次利润分成提款会触发 KYC;首次请预留额外 1–2 天。
- 排行榜现金。赛季结束时从专用奖励池合约公布,按档位以单次批量交易支付。已为利润分成提款完成 KYC 的钱包无需重新验证。领奖台(前 3 名)结果在批次离开国库前完成审核——每个赛季,无一例外——因此排行榜漏洞无法通过排名 #1 绕过运营审查。
- 推荐现金。每月以批次支付,在每月第一个工作日,锚定上级钱包。每笔转账都携带被推荐者支付 id 与 Basescan 交易哈希,因此归因事件与到达你钱包的 USDC 之间的关联是端到端可审计的。
- 高价值提款($5K+)。任何单笔高于 $5,000 的请求,在证明窗口开启之前由运营审核。这会增加几个小时,但不会改变链上结算路径——证明、根引用与合约释放完全相同。
受证明门控的设计带来一个重要后果:即使完全访问出纳与运行时,运营也无法将一笔没有有效根引用与匹配 Merkle 证明的支付推过去。出纳 UI 在最终确认时呈现已发布的根 id 与证明;你可以把任一项粘贴到 Basescan 读调用中,并自行根据同一根核验链上释放。如果 dexter.market 上的已公布档位总额与奖励池地址流出交易之和不一致,则以链上记录为真,仪表盘为错——而非相反。金库会计(手续费、保险支取与奖励池注资如何移动)记录于 国库与会计。