GMX请求成功却没成交：核keeper执行、frozen订单与Gas退款
链小知 · 进阶 · 核验 · 依官方文档整理
从已有Orders和交易材料分清请求、执行、取消，以及最大网络费和实际退款。
开始前准备
- 准备原chain、account、market、订单类型、request key与交易hash，以及Orders/Trade History和费用截图。
- 仅核原记录，不重发订单、增费、修改buffer、撤单或Claim；直接集成使用的旧合约地址需另核版本。
1. 先区分request和execution
提交请求只把参数存链上；keeper另提交带oracle价格的执行交易。按同一request key关联两阶段，缺execution不能把钱包第一笔success写成已成交。原合约升级可能换handler/router地址，不拿当前地址替历史回执。
检查结果：请求与执行交易分别有记录，原网络/account/key一致。
2. 在Orders辨触发源和未执行分支
原Orders的Limit/TP-SL看方向对应minPrice/maxPrice；图表mark均值或蜡烛high/low不是统一触发价。若原订单frozen，区分用户条件未满足和keeper Gas/oracle失败；后者可能整笔回滚并保留请求。
检查结果：原订单类型、触发源及frozen/仍pending/已取消状态分开。
3. 拆出最大网络费和实际支出
原费用tooltip显示max network fee、estimated refund及Paid from。Classic以原生币Gas，Express以gas payment token和相应余额承担；界面净费用减了预计退款，不能再扣一次。keeper实际Gas和返还另按回执核。
检查结果：支付资产/余额来源、max、预估退款、实际返还有明确值或未知。
4. 核取消和退款的实际结果
当前普通Market订单未执行约六分钟可能由keeper取消；Limit/Stop/TWAP/TP-SL不自动套此规则。TWAP进度3/5只证三段执行，余段可能因执行费不足frozen。取消请求成功也需核返还资产和相应执行/取消记录。
检查结果：区分已成交、部分成交、未执行/取消与实际返还，未用超时推算到账。
怎样确认完成
- 形成同request key两阶段状态和费用对照；未知执行/返还保留证据缺口。
- documentation：未操作GMX客户端、keeper或资金。
常见错误与边界
- 预计退款、订单冻结、订单取消和钱包实收不是同一种结果。
- 9月v2.2b停用快讯面向直接集成，不等App用户要重新存款或授权。