Market Maker Integration#

Overview#

OKX DEX routes swap demand to professional market makers through RFQ (Request for Quote). Market makers provide executable price levels off-chain, and final settlement takes place on Solana after the user signs the transaction.

The OKX DEX smart router aggregates liquidity from multiple market makers and AMMs, selecting or splitting routes based on price and fillability. This specification covers only the Solana RFQ Pricing and Firm Order interfaces.

API surface#

Both endpoints are implemented by the market maker and called by OKX. The Base URL is agreed during onboarding and integration testing.

Integration and performance requirements#

1. Update Pricing levels for every token pair at least once per second; quotes older than one second are stale.

2. Support 50 RPS on Pricing and 200 RPS on Firm Order.

3. Target a 50 ms Firm Order response time, with a 400 ms maximum; slower responses may be dropped and treated as failures.

4. Maintain a successful response rate above 90%, with at least 90% of orders executing successfully on-chain.

5. Provide independent, non-cumulative levels; the router may request partial fills based on streamed depth.

6. Ensure signing keys, Solana balances, associated token accounts, and RPC/broadcast capability support the selected settlement mode.

Production sizing These performance targets come from the current online integration guide. Confirm Solana production traffic, load-test methodology, and alert thresholds with OKX during onboarding.

Market maker ATA readiness#

For every SPL token that a market maker intends to quote or provide liquidity for, the market maker must create and initialize the corresponding Associated Token Account (ATA) for makerAddress before enabling the pair. Pricing must not advertise a pair until all required maker ATAs are ready.

Recommended approach: the market maker pre-creates the ATAs and funds their account rent during onboarding or before liquidity is enabled. Do not add ATA-creation instructions to the swap transaction by default.

Rationale: creating an ATA inside the swap transaction consumes additional instruction and message space, adds account metas, and introduces rent-payer responsibility. Under the current validation rule, maker-related accounts must not appear in unrelated instructions. Therefore, even an idempotent CreateAssociatedTokenAccount instruction would conflict with the existing instruction-account validation, and the maker cannot act as the rent payer through that instruction.

Operational handling: before publishing Pricing, validate that each required ATA exists and has the expected owner, mint, token program, and initialized state. Re-check periodically and suspend affected pairs when an ATA is missing or invalid. Transaction-time ATA creation should be considered only if OKX intentionally revises the account-validation policy, defines the rent payer, and re-evaluates Solana transaction size and compute limits.

Execution flow and settlement modes#

1. OKX calls Pricing to obtain supported pairs and current price levels for the chain.

2. OKX builds the swap transaction from the selected quote and presents it to the user for signing.

3. After the user signs, OKX submits the rfqId and Base58-encoded callData to Firm Order.

4. The market maker validates the RFQ, transaction contents, user signature, execution price, current liquidity, and executability.

5.The market maker adds the required signature.

6.The market maker returns either txHash (MM broadcast) or signedTx (OKX broadcast).

7.OKX tracks the on-chain settlement state and resolves uncertain outcomes through timeout handling.

XOR rule A successful response must contain exactly one of txHash and signedTx. They must never be returned together or both omitted.

Settlement mode A: MM broadcast#

After validation and signing, the market maker broadcasts the transaction. Return txHash as soon as a deterministic transaction hash is available; do not wait for an RPC submission response, landing, Confirmed, or Finalized status. If a pre-response broadcast attempt fails, code 82004 may be returned; otherwise, broadcast and confirmation may continue after the Firm Order response.

Settlement mode B: OKX broadcast#

After validation and signing, the market maker returns the complete Base58 transaction containing both the user and MM signatures as signedTx. OKX then broadcasts it, obtains the transaction hash, tracks on-chain status, and resolves the final order state.

Settlement mode comparison#

General conventions#

Base URL and content type#

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

GET requests use query parameters and POST requests use JSON bodies. Business quantities should be transported as strings to avoid precision loss.

API key authentication#

Every request must carry an API key. Use the standard online spelling X-API-KEY; HTTP header names are case-insensitive. Reject requests with a missing or invalid key.

Standard response envelope#

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

Solana encoding#

Solana transactions, signatures, and transaction hashes use Base58 encoding. callData is the user-signed transaction; signedTx is the complete transaction containing both user and MM signatures.

Solana RFQ program deployment#

Deployed Program ID: RFQ27dg5gSha2cDzQxuGyhfkz5CK2fUSy3Sjw4Rptyj

Source repository: https://github.com/okxlabs/web3-solana-rfq-v2

Market makers must verify that transactions reference the agreed deployed Program ID. Any environment-specific or future replacement Program ID must be confirmed with OKX before use.

Timeout and exception fallback#

The market maker does not need to expose a separate order-status endpoint. Uncertain states after Firm Order are handled by OKX on-chain tracking and timeout jobs.

Onboarding checklist#

1. Provide production and test Base URLs to OKX.

2. Agree on secure X-API-KEY exchange, rotation, and revocation.

3. Confirm supported Solana mint pairs, makerAddress, and ATA readiness.

4. Confirm Pricing amount units, precision, and minTakerAmount semantics.

5. Select MM broadcast or OKX broadcast and validate the txHash/signedTx XOR rule.

6. Load-test Pricing and Firm Order against the published capacity targets.

7. Test invalid API keys, stale RFQs, bad signatures, liquidity changes, RPC failures, and duplicate requests.

8. Provide the project logo and official website URL to the OKX team.