克隆GMX.io：链下Keeper功能解析与标准实现方案问询

一、Keeper的核心用途 #

GMX的链下Keeper是链上合约的执行层补充，核心职责包括：

• 触发限价订单执行：监控链上挂单的限价条件，价格达标时调用合约完成开仓/平仓，替代用户主动发起交易
• 维护系统资金健康：协助清算风险敞口超标的仓位，避免系统穿仓
• 辅助价格校验：配合Chainlink喂价，交叉验证链下市场价一致性，防止异常价格引发系统问题
• 处理条件类订单：实现链上无法直接完成的止盈止损、时间触发等订单逻辑

二、搭建所需工具与服务 #

• 节点服务：稳定的Arbitrum/Optimism等EVM兼容节点，可选择第三方服务商或自建，保障实时链上数据获取与交易广播
• 价格数据源：同时对接Chainlink喂价与中心化交易所API（如币安、CoinGecko），交叉验证避免价格偏差
• 任务调度框架：用Celery、Airflow或自定义轮询机制，实现7*24小时不间断监控
• 交易签名工具：基于Ethers.js、Web3.py等库处理私钥签名，确保交易安全上链
• 监控与日志系统：用Prometheus+Grafana监控运行状态，ELK栈记录交易日志，便于问题排查
• 容错机制：多实例部署+故障转移，避免单节点宕机导致服务中断

三、标准实现步骤与优化要点 #

基础架构搭建 #

1. 链上事件监听：通过节点eth_subscribe订阅订单合约的OrderCreated事件，实时获取新挂单；同时定时轮询合约未执行订单列表，防止漏接事件
2. 价格验证逻辑：取Chainlink喂价与中心化市场价的合理区间值作为触发依据，避免单一数据源异常导致误触发
3. 交易执行控制：
   • 触发条件满足时，先用eth_call模拟交易验证可执行性，避免gas浪费
   • 设置动态gas价格调整机制，网络拥堵时提高gas确保交易快速上链
   • 加入重试逻辑，交易失败（如gas不足、链上状态变化）时短时间内重试3-5次，异常订单标记后人工处理
4. 状态持久化：用Redis或PostgreSQL存储未执行订单、价格历史、交易记录，Keeper重启后可恢复运行状态

现有监听程序的优化方向 #

你之前的程序未达预期，大概率是以下问题导致：

• 价格数据源单一：仅依赖单一价格存在延迟或偏差，需交叉验证
• 无交易模拟环节：直接调用合约可能因链上状态变化（如仓位额度不足）导致交易失败
• 缺乏容错机制：单实例运行或无重试逻辑，网络波动时易漏触发
• 事件覆盖不全：仅轮询价格未监听链上订单事件，可能错过新挂单

四、参考逻辑（非开源替代） #

GMX未开源Keeper，但可参考同类DeFi项目的实现逻辑：

• 限价订单触发：参考Uniswap V3的TWAP验证逻辑，结合GMX合约executeOrder函数参数要求构造合规交易
• 清算逻辑：参考Aave的清算Keeper，监控用户仓位健康因子，达标时调用GMX清算合约

内容的提问来源于stack exchange，提问作者Shayan Shaikh