做市商集成#

概览#

OKX DEX 通过 RFQ（Request for Quote）将用户的兑换需求路由给专业做市商。做市商在链下提供可执行的分档报价，用户完成交易签名后，通过 Solana 链上完成最终结算。

OKX DEX 的智能路由会聚合多个做市商与 AMM 的流动性，并根据价格和可成交性选择或拆分路径。本文仅定义 Solana RFQ 的 Pricing 与 Firm Order 接口。

接口范围#

接口	方法	用途
/OKXDEX/rfq/pricing	GET	返回支持的交易对及非累计分档报价。
/OKXDEX/rfq/firm-order	POST	校验用户已签名的 Solana 交易，完成 MM 签名并返回结算结果。

上述接口均由 MM 实现、由 OKX 调用。Base URL 由双方在准入及联调阶段确定。

接入与性能要求#

每个交易对至少每 1 秒更新一次 Pricing 报价；超过 1 秒的报价将被视为过期。
Pricing 端点应支持 50 RPS；Firm Order 端点应支持 200 RPS。
Firm Order 的目标响应时间为 50 ms，最大响应时间为 400 ms；超过上限的响应可能被丢弃并视为失败。
成功响应率应高于 90%，且至少 90% 的订单应成功完成链上执行。
报价必须为非累计、逐档独立的价格深度；系统可能根据报价深度请求部分成交。
MM 需确保签名密钥、Solana 账户余额、ATA 与 RPC/广播能力满足其选择的结算模式。

生产容量以上性能指标来自当前线上通用接入文档。Solana 生产流量、压测方法与告警阈值应在准入阶段与 OKX 明确。

做市商 ATA 准备要求#

对于 MM 拟提供报价或流动性的每个 SPL Token，MM 必须在启用该交易对之前，为 makerAddress 提前创建并初始化对应的关联代币账户（Associated Token Account，ATA）。所有必需的 maker ATA 准备完成前，Pricing 不得发布该交易对报价，以避免交易失败。

推荐方案：由 MM 在准入阶段或启用流动性前自行创建 ATA 并承担账户租金；默认不在 Swap Transaction 中增加 ATA 创建指令。

理由：在交易内创建 ATA 会增加指令、账户元数据和消息空间。按照当前校验规则，maker 相关账户不得出现在其他无关指令中。因此，即使使用幂等的 CreateAssociatedTokenAccount 指令，也会与现有的指令账户校验冲突，maker 也无法通过该指令作为租金支付方。

处理建议：发布 Pricing 前，校验每个必需 ATA 的存在性、owner、mint、token program 与 initialized 状态；运行期间定期复检，ATA 缺失或无效时暂停受影响交易对的报价。只有在 OKX 主动调整账户校验策略、明确租金支付方，并重新评估 Solana 交易大小与计算限制后，才考虑在交易内自动创建 ATA。

执行流程与结算模式#

OKX 调用 Pricing 获取指定链的支持交易对和最新分档报价。
OKX 根据报价构建 Swap Transaction，并交由用户签名。
用户签名后，OKX 将 rfqId 与 Base58 编码的 callData 提交到 Firm Order。
MM 校验 RFQ、交易内容、用户签名、成交价格、当前流动性与可执行性。
MM 添加所需签名。
MM 返回 txHash（MM 广播）或 signedTx（OKX 广播）。
OKX 跟踪链上结算状态，并通过超时任务处理不确定结果。

互斥规则成功响应中，txHash 与 signedTx 必须且只能返回一个，不得同时出现，也不得同时缺失。

模式 A：MM 广播#

MM 完成校验与签名后自行广播。MM 获得确定的交易哈希后应立即返回 txHash，不应等待 RPC 广播响应、交易上链、Confirmed 或 Finalized。若 MM 在返回前主动提交广播且提交失败，可返回错误码 82004；否则广播及确认可在 Firm Order 响应之后继续。

模式 B：OKX 广播#

MM 完成校验及自身签名后，将包含用户签名与 MM 签名的完整 Base58 交易作为 signedTx 返回。OKX 负责广播、获取交易哈希、跟踪链上状态并处理最终订单结果。

结算模式对比#

项目	MM 广播	OKX 广播
Firm Order 返回	txHash	signedTx
MM 是否签名	是	是
广播责任	做市商 / MM	OKX
链上跟踪	OKX 根据 txHash 跟踪。	OKX 全流程跟踪。
响应时机	签名并获得哈希后立即返回。	联签完成后立即返回。
异常处理	由 OKX 超时兜底；仅响应前提交失败使用 82004。	由 OKX 内部处理。
适用场景	MM 希望控制 RPC、策略与发送时机。	MM 希望简化广播与状态跟踪。

通用约定#

Base URL 与内容类型#

Base URL: https://your-api-endpoint.com/OKXDEX/rfq
Content-Type: application/json

GET 请求通过查询参数传值；POST 请求使用 JSON 请求体。所有数值型业务量应使用字符串传输，避免精度丢失。

API Key 认证#

所有请求必须携带 API Key。推荐使用线上文档中的标准写法 X-API-KEY；HTTP Header 名称不区分大小写。若缺失或无效，MM 应直接拒绝请求。

Header	类型	必填	说明
X-API-KEY	String	是	准入阶段分配或登记的 API Key。

通用响应结构#

json

{
  "code": "0",
  "msg": "",
  "data": {}
}

字段	类型	说明
code	String	"0" 表示成功，其他值表示失败。
msg	String	成功时为空，失败时返回简短原因。
data	Object	各接口定义的业务响应数据。

Solana 编码#

Solana 交易、签名与交易哈希采用 Base58 编码。callData 表示用户已签名交易；signedTx 表示同时包含用户与 MM 签名的完整交易。

Solana RFQ 程序部署信息#

已部署 Program ID：RFQ27dg5gSha2cDzQxuGyhfkz5CK2fUSy3Sjw4Rptyj

源代码仓库：https://github.com/okxlabs/web3-solana-rfq-v2

MM 必须校验交易引用的是双方约定的已部署 Program ID。不同环境或未来替换的 Program ID，均须在使用前与 OKX 确认。

超时与异常兜底#

MM 无需实现额外的订单状态查询接口。Firm Order 后出现的不确定状态由 OKX 的链上跟踪和超时任务处理。

场景	触发条件	OKX 处理
Firm Order 明确失败	MM 返回 82000-82004 等明确业务错误。	直接按失败处理。
响应异常	网络异常、超时或无法识别的返回。	进入异常状态并由超时任务兜底。
未观察到 txHash 链上结果	MM 声明已广播，但预期时间内未观察到结算。	超时任务最终标记失败。
OKX 广播失败	MM 返回 signedTx，但 OKX 广播或链上执行失败。	由 OKX 内部跟踪并处理。

准入检查清单#

向 OKX 提供生产与测试 Base URL。
完成 X-API-KEY 的安全交换、轮换与失效策略。
确认支持的 Solana Mint 对、makerAddress 与 ATA 准备状态。
确认 Pricing 数量单位、精度与 minTakerAmount 口径。
选择 MM 广播或 OKX 广播，并验证 txHash/signedTx 互斥规则。
按线上容量指标完成 Pricing 与 Firm Order 压测。
覆盖无效 API Key、过期 RFQ、签名错误、流动性变化、RPC 异常与重复请求。
向 OKX 团队提供项目 Logo 与官方网站地址。