架构
对交易者而言,Dexter 是一款产品——连接钱包、购买 $49–$299 套餐、交易、获得报酬——底层则是五层。每层只负责一项工作,并只持有该工作所需的权限。降级的预言机无法暂停提款。卡住的运营钱包无法冻结抵押品。挑战引擎无法重写撮合引擎的成交。结算在 Base 上运行,托管位于专用合约中,每一笔支付都可追溯到任何人都能在区块浏览器中验证的已发布状态根。
界面感觉单一,但执行、发布与托管仍清晰分离。
一个可见的平台。
执行之前的策略。
定价、撮合、风控、资金费率、发布。
状态附带上下文一同发布。
抵押品保持受限。
请将该表视为权限图。每一层的第一列是它被允许做的事情;第三列是它从设计上无法做到的事情。表中没有任何一项可以在没有 Base 上相应合约调用的情况下移动用户资金。
| 层 | 主要职责 | 无法做到 |
|---|---|---|
| 产品界面 | 渲染市场、图表、下单、持仓、资产与账户视图 | 不撮合、不托管、不结算 |
| 网关与读取模型 | 将持久化运行时输出归一为一个稳定 API;以代理授权、IOC 与订单承诺策略门控签名入口 | 不做成交决策,不掌握余额权限 |
| 运行时引擎 | 单写入者流程:校验签名订单、施加风控、定价、成交、推进资金费率、准备发布 | 不直接托管、不单方面提款、不变更参数 |
| 发布 | 提交带有序列、预言机、批次与配置绑定的状态根,供金库结算时引用 | 无撮合循环、不写余额 |
| Base 上的合约 | 持有抵押品、排队提款、保留根历史、对国库操作强制多签 | 无实时订单撮合、无链下权限 |
#同一平台,分离的运行层
交易者看到的是一个平台。实现将该平台拆分为五层,是因为把快速执行、可读的产品状态以及与托管密切相关的权限挤进一个组件,正是衍生品平台损失用户资金的常见方式。产品界面负责清晰呈现。网关负责归一化以及对签名流的准入策略。运行时在单写入者模型下持有实时交易状态。发布负责绑定链下状态与链上结算。Base 上的合约负责托管以及国库移动的多签门控。
第三方界面——仪表盘、跟单通道、移动端客户端、机构 API 消费者——与内部应用从同一个网关读取。它们并不构成新的协议层;它们消费的是同样的持久化状态。这就是跟单机器人、零售移动前端与量化席位看到一致成交的结构性原因。
Dexter 以无流动性 vAMM 模式上线。实时平台不依赖挂单 maker 库存;执行压力、偏斜、价差与库存姿态都由运行时基于 vAMM 曲线处理。无论运行时采取何种姿态,托管与提款权利始终绑定于合约。错误的库存决策不会让交易者损失其保证金。
产品界面
-> 网关与读取模型
-> 链下运行时
-> 已发布的承诺
-> Base 上的金库、国库与结算合约#真正的信任边界在哪里
Dexter 并不声称每个组件都在链上。它声称的是一种更狭义、更有用的主张:只要托管、结算引用与协议拥有的价值在链上以明确的规则存在,执行就可以在链下保持快速。用户抵押品、提款请求、nonce 历史、手续费余额、保险储备以及收入端会计全部位于 Base 上的合约治理存储,因为这些都是所有权必须保持明确无误的地方。
运行时推进状态,并发布金库读取所引用的结算上下文。它不会事后重新定义托管,也不会授权合约自身不会兑现的提款。$10,000 以上的国库移动需要 2-of-3 多签;保险与治理移动需要带外部签署人的 3-of-5。运行时无法绕过任一门控。这正是将链下/链上拆分转化为真实的架构边界、而非堆叠在黑箱后端之上的营销语言的关键。