#grvt 我翻 GRVT 的官方文档时，最让我停下来细看的是它的 Risk Engine 架构。大部分衍生品协议的风险引擎就是一套清算逻辑加一个价格预言机，GRVT 却把它拆成了三层：Pre-trade Risk Check、Position Monitoring 和 Settlement Validation。这三层不是串行的，而是各自独立运行，任何一层发现问题都会触发对应的风控动作。
Pre-trade Risk Check 发生在订单匹配之前。当你提交一笔开仓请求，Risk Engine 会先校验你的 Unified Balance 是否足够覆盖初始保证金、名义价值是否超过账户层级的上限、以及该交易对当前的持仓集中度是否过高。如果任何一项不达标，订单直接拒绝，不会进入匹配队列。我在测试网试过一笔超出账户名义价值上限的开仓，系统在提交阶段就拦截了，没有等到清算才处理。
Position Monitoring 是实时运行的，跟踪每个账户的维持保证金率和杠杆倍数。GRVT 的清算触发不是单一价格线，而是结合了标记价格和预言机价格的加权值，防止单点预言机抖动导致误清算。文档里写的是用 Pyth 和 Chainlink 双源喂价，取加权中位数，偏差超过阈值时会触发价格分歧检查，暂停相关交易对的清算直到价格恢复一致。
Settlement Validation 发生在交易最终结算时，校验链上状态与链下匹配引擎的记录是否一致。如果发现差异，系统会触发 Reconciliation 流程，冻结相关账户直到差异解决。这个机制在衍生品协议里不常见，更多的是在传统金融清算所里才有。
三层校验的好处是把风险拦截在多个入口，而不是等到清算线才处理。代价是每一层都增加了延迟和计算开销。GRVT 文档里写 Pre-trade Check 的目标是 10 毫秒内完成，Position Monitoring 是实时流式计算，Settlement Validation 是异步批量处理。
我个人觉得如果主网上线后这些 SLA 能守住，这套三层风控架构在衍生品协议里算是比较扎实的。@grvt_io
Pre-trade Risk Check 发生在订单匹配之前。当你提交一笔开仓请求，Risk Engine 会先校验你的 Unified Balance 是否足够覆盖初始保证金、名义价值是否超过账户层级的上限、以及该交易对当前的持仓集中度是否过高。如果任何一项不达标，订单直接拒绝，不会进入匹配队列。我在测试网试过一笔超出账户名义价值上限的开仓，系统在提交阶段就拦截了，没有等到清算才处理。
Position Monitoring 是实时运行的，跟踪每个账户的维持保证金率和杠杆倍数。GRVT 的清算触发不是单一价格线，而是结合了标记价格和预言机价格的加权值，防止单点预言机抖动导致误清算。文档里写的是用 Pyth 和 Chainlink 双源喂价，取加权中位数，偏差超过阈值时会触发价格分歧检查，暂停相关交易对的清算直到价格恢复一致。
Settlement Validation 发生在交易最终结算时，校验链上状态与链下匹配引擎的记录是否一致。如果发现差异，系统会触发 Reconciliation 流程，冻结相关账户直到差异解决。这个机制在衍生品协议里不常见，更多的是在传统金融清算所里才有。
三层校验的好处是把风险拦截在多个入口，而不是等到清算线才处理。代价是每一层都增加了延迟和计算开销。GRVT 文档里写 Pre-trade Check 的目标是 10 毫秒内完成，Position Monitoring 是实时流式计算，Settlement Validation 是异步批量处理。
我个人觉得如果主网上线后这些 SLA 能守住，这套三层风控架构在衍生品协议里算是比较扎实的。@grvt_io