Anzeigemodus

Introduction

OKX Intent Overview#

OKX Intent adopts a parallel auction mechanism: the system advances multiple auctions concurrently across different time windows and batches, and triggers the solve and winner-selection process for solvers in parallel. It does not wait for the previous round to be fully settled before starting the next one. This makes better use of solver compute capacity and on-chain block time slices, significantly reducing the end-to-end latency from order placement to settlement and providing users with a more stable and faster trading experience.

Terminology#

Terminology	Description
Intent Order	A user's intent-based order, containing fields such as `fromTokenAddress`, `fromTokenAmount`, `toTokenAddress`, `toTokenAmount`, `validTo`, etc.
Quote	A price estimate for the order that the user obtains from a solver.
Orderbook	The entry point for user interaction with the protocol. It receives user quote requests, validates and stores user-signed orders.
Autopilot	The protocol's core orchestration engine. It maintains the global state, creates batch auctions, distributes them to solvers, and selects the best solution.
Settlement contract	The on-chain contract that executes trades. Only allowlisted solvers are permitted to call it.
Auction	A batch auction mechanism that aggregates all pending orders within a time window and lets solvers compete to produce the best solution.
Parallel Auction	Multiple auctions running concurrently (distribution, solving, winner selection, and settlement can overlap) to reduce user waiting time.
Solution	An executable plan submitted by a solver for a given auction, specifying which orders are filled, execution amounts, clearing prices, etc.
Clearing Prices	In a single auction settlement, each token has a clearing price. These prices are used to compute execution amounts during settlement and to verify that each order's minimum received amount is satisfied.
Minimum Received Amount	After obtaining the best quote, the user signs an intent order specifying the required minimum received amount.
Baseline	The reference quote provided by the baseline solver, used as a benchmark to evaluate whether a solver's quote is below typical market performance.
Surplus	The difference between the final execution outcome and the user's minimum acceptable price obtained from the quote.
Score	The sum of surplus across all orders within a solution.

System Overview#

Flow#

Trader: Requests a quote → selects an offer → signs the order (EIP-712 / eth_sign / EIP-1271 / presign).
Orderbook: Validates and stores the order.
Autopilot: Periodically batches orders, and in parallel distributes the orders / clearing prices / constraints to solvers.
Solver: Computes the optimal matching/routing solution and submits a solution; Autopilot selects the winner with the best score.
Winner solver (on-chain): Calls Settlement.settle(tokens, clearingPrices, trades, interactions[0..2]) to settle in a single transaction.

Onboarding Prerequisites#

Solver KYB#

Complete CeFi KYB and provide the UID.

Solver Address Allowlist#

Supported address types: EOA / contract wallet
Allowlist application flow: After KYB completion → submit the address → the on-chain allowlist takes effect

Materials / Information the Solver Side Must Provide#

Contract whitelisting materials:

Chain
Solver address

Gateway whitelisting materials:

Access domain name

Configuration platform whitelisting materials:

Chain ID
Solver address
Access domain name
Whether there is a rate-limiting requirement

Integration Testing Process#

Beta testing: Use the beta environment with beta contracts. Test /quote, /solve, and /settle APIs in the beta environment, including fee testing and stress testing, covering the full end-to-end flow. The solver tests using non-production orders. For placing orders via OKX, coordination/support from OKX is required.
Shadow testing: Use production contracts for testing. A JS script will be provided for solvers to place orders and test the full /quote, /solve, /settle flow. Each chain requires 15 successful orders with a success rate above 80%.
Staging testing: Use production contracts and compete with existing solvers in the production environment. At this stage, no real user orders are received. Solvers must place orders themselves via JS scripts. Each chain requires 5 successful orders with a success rate above 80%.
Go live: Use the production environment with production contracts and production orders. This phase is the official go-live.

SLA / Performance Requirements#

/quote Latency & Availability#

SLA: all chains ≤ 2.5s; timeouts are treated as forfeiting the quote.

Metric	Chain	Pass
Response time	ALL	≤ 2.5s

Single-Order Auction Response Time#

SLA: all chains ≤ 4s.

Metric	Chain	Pass
Response time	ALL	≤ 4s
Timeout forfeit rate	ALL	≤ 10%

Multi-Order Auction Response Time (per chain)#

Metric	Chain	Pass
Response time	ETH	≤ 8s
Response time	ARB	≤ 4s
Response time	Base	≤ 4s
Response time	BSC	≤ 6.75s
Timeout forfeit rate	ALL	≤ 20%

Solution Quality#

Metric	Chain	Pass
Solution return rate	ALL	≥ 80%
On-chain success rate (1hr window)	ALL	≥ 80%

On-Chain Rate Within Deadline — Multi-Order Auction#

Metric	Chain	Pass
Settled within block deadline	ETH	≥ 80% (3 blk)
Settled within block deadline	ARB	≥ 80% (40 blk)
Settled within block deadline	Base	≥ 80% (18 blk)
Settled within block deadline	BSC	≥ 80% (40 blk)

On-Chain Rate Within Deadline — Single-Order Auction#

Metric	Chain	Pass
Settled within block deadline	ETH	≥ 80% (2 blk)
Settled within block deadline	ARB	≥ 80% (30 blk)
Settled within block deadline	Base	≥ 80% (10 blk)
Settled within block deadline	BSC	≥ 80% (22 blk)

Stress Test (/quote)#

Send /quote requests at 30 QPS concurrently to verify solver stability under high load.

Metric	Chain	Pass
Target QPS	ALL	≥ 30 QPS
/quote response time under load	ALL	≤ 2.5s
/quote timeout rate under load	ALL	≤ 10%

Solver API#

Endpoint List#

Forward compatibility: New fields may be added to request/response bodies at any time. Your implementation must ignore unknown fields. Do not enforce strict field validation.
Solvers should implement the APIs according to our specification.
All endpoints use the POST method with JSON request bodies.
All timestamps are in milliseconds (e.g., 172120120102).
For EVM-compatible chains, all addresses use lowercase 0x-prefixed hex encoding (20 bytes). Non-EVM chains retain their native address format.
Amount fields use String type, representing values in the smallest unit.
Solvers must return responses within the time specified by deadline.
Use the DIP service — no allowlisting is required.
- If IP allowlisting is needed: 47.243.1.144-159, 47.254.152.31, 47.89.234.165, 18.157.58.16, 3.65.240.18, 63.181.55.143 (21 IPs total).

Endpoint	Method	URL	Description
Quote	POST	`https://your-api-endpoint.com/OKXDEX/intent/quote`	Get a price estimate (quote).
Solve	POST	`https://your-api-endpoint.com/OKXDEX/intent/solve`	Solve the incoming auction.
Settle	POST	`https://your-api-endpoint.com/OKXDEX/intent/settle`	Settle the solved auction on-chain.
Notify	POST	`https://your-api-endpoint.com/OKXDEX/intent/notify`	Receive system notifications (e.g., disabled).

Unified Response Structure#

Response parameters

Parameter	Type	Required	Description
`code`	Integer	Yes	Status code. `0` indicates success; non-zero indicates failure.
`msg`	String	No	Success or error message.
`data`	Object	No	Response payload (returned on success).

Success response example

json

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

Error response example

json

{
  "code": 500,
  "msg": "Internal server error",
  "data": null
}

Table of contents

Flow

Solver KYB

Solver Address Allowlist

Materials / Information the Solver Side Must Provide

SLA / Performance Requirements

Endpoint List