Providing Quotes to OKX DEX: Onboarding, Signatures, and Inventory Risk

OKX

22 October 2026

Providing quotes to OKX DEX is not something you can start by simply registering and depositing funds like a regular user. It is a professional RFQ (Request for Quote) integration process designed for market makers. First, you need to pass OKX's review to become an approved market maker. Then, you build your own HTTP endpoint so OKX's servers can pull your quotes in real time and submit firm orders. The core challenges are not the quoting action itself, but onboarding approval, signature compliance, and continuously meeting performance requirements. OKX's public documentation says very little about inventory risk management; the initiative largely rests with the market maker.

OKX Exchange
A leading global cryptocurrency platform,suitable for both beginners and experienced traders.
New user benefit: 20% off trading fees upon registration!！

Onboarding: Pass the Review Before Technical Integration

OKX has a clear screening process for market makers. The official explanation is that they expect market makers to have sufficient assets and experience to provide legal, timely, and competitive quotes, so potential market makers undergo strict review. There are two application paths: if you already have an OKX account, contact your account manager; if you are a new user, fill out the official market maker application form and the team will follow up to guide you through the next steps.

This means there is no self-service onboarding option. You cannot find a button on the OKX website or app to start quoting to the DEX. After approval, OKX will give you an API Key and ask you to provide Base URLs for production and test environments for further integration testing.

You Need to Build Your Own Quote Endpoint

The OKX DEX RFQ system is designed so that the market maker implements the interface, and OKX calls it. You do not need to call OKX's API to pull data. Instead, your server exposes two endpoints that OKX's servers will request.

On EVM chains, the two core endpoints are /pricing (GET) and /firm-order (POST). The first is used by OKX to periodically pull your quotes. The second is used when a user initiates a trade, and OKX sends your quote along with the user's signature to you, so you can perform final validation and return your signature. Solana's interface structure is similar, and the Base URL is determined by both parties during onboarding and testing.

Hard Requirements for Quotes: Push Every Second, Non-Cumulative

Your /pricing endpoint needs to continuously output quotes. OKX's rule is: each token pair must update its price level at least once every 1 second. Quotes older than 1 second will be considered expired and ignored. OKX will ping your endpoint every second. If a token pair has not been updated for more than 10 seconds, the quote for that pair on that chain becomes invalid.

There is one easily mistaken part of the quote data structure: it must be a non-cumulative, level-by-level quote. Each level independently represents the quantity and exchange rate available at that level. Do not add the quantity from the previous level to the next level. For example, if a market maker is willing to buy 0.26 WETH at one price and 0.99 WETH at another price, these two levels are parallel, not "0.26 for the first level and 1.26 cumulative for the second." Also, the cumulative value of the quote must exceed 200 USD, otherwise the system will ignore it.

Signatures: EIP-712 or EIP-1271 on EVM, Base58 on Solana

When a user accepts a trade containing your quote, OKX calls your /firm-order endpoint. You need to validate the transaction (RFQ, trade details, user signature, execution price, current liquidity, executability), then add your own signature and return it.

Two signature schemes are supported on EVM chains: EIP-712 and EIP-1271. If you use Permit2 for authorization, you also need to handle permit2-related signature fields. On Solana, only Base58-encoded signatures are accepted. Signatures are not optional—OKX's documentation explicitly requires market makers to "return the signature for the taker to execute." Your private key management and the availability of your signing service directly determine whether you can continuously accept orders.

There is also a prerequisite at the authorization level: you need to ensure you have granted sufficient approval to the OKX DEX settlement contract or Permit2 contract to cover your liquidity level and quote size. Otherwise, even if a user accepts the quote, on-chain settlement may fail.

Performance: Different Metrics for Quotes and Firm Orders

OKX has separate throughput requirements for the two endpoints: /firm-order must handle 200 RPS, and /pricing must handle 50 RPS. The response time for firm orders should ideally be under 200 ms, and must not exceed 500 ms. Responses that time out will be discarded and marked as failed. Overall, you need to maintain a success rate above 90%, and at least 90% of orders must execute successfully on-chain.

These metrics are not "suggestions"; they are ongoing requirements after onboarding. If your endpoint slows down under pressure or your signing service becomes unavailable, OKX's router will exclude your quotes from candidates, and you will not receive orders.

Inventory Risk: What the Docs Do Not Cover Is the Real Challenge

OKX's public integration documentation barely discusses how market makers should manage inventory, hedge, or set exposure limits. This is understandable: inventory risk management is the market maker's own core competency. The platform will not do it for you, nor will it specify it in the integration docs.

However, there are several technical details directly related to inventory worth thinking through in advance:

Non-cumulative quotes themselves limit single-trade exposure. The quantity you quote at each level is the maximum you are willing to trade at that price. If you do not want to have too much inventory taken at a certain price, set the quantity for that level smaller, or do not quote that level at all. OKX does not require minimum liquidity, so you can quote only at depths you are willing to accept.

Solana ATAs must be prepared in advance. Market makers need to create and initialize the corresponding Associated Token Account under makerAddress for every SPL token they plan to quote. The documentation explicitly recommends not creating ATAs temporarily within swap transactions, because it consumes extra instruction space, introduces rent payer issues, and conflicts with current account validation rules. If your ATA is not ready, on-chain settlement will fail even if the quote is accepted. The on-chain destination for your inventory must be set up first.

EVM Permit2 approval amount is your total exposure cap. The approval amount you grant to the OKX settlement contract or Permit2 effectively limits how many assets can be taken from you. The approval amount should match your inventory strategy, not be set to unlimited in one go.

Trade expiration times are mandatory and fixed. 36 seconds on Ethereum, 32 seconds on EVM L2s. The window from when your quote is pulled by OKX to when the user finally signs and settles on-chain is very short. If your inventory hedging or rebalancing depends on longer cycles, you need to account for this.

Our Take

If you do not have a market maker background, low-latency infrastructure, or experience managing on-chain assets and signing services, this is not a project you can simply "learn as you go." Onboarding review, per-second quoting, 500 ms signature response, and 90% on-chain execution success rate—these combined requirements filter for teams or institutions that already have professional market-making capabilities.

If you are indeed in the market-making business, OKX DEX RFQ integration is worth evaluating. Its technical barriers are clear (two endpoints, non-cumulative quotes, explicit signature formats), and performance metrics are stated openly, so there is no guessing. The cost is that you need to maintain a highly available quote endpoint specifically for OKX, and you must handle inventory risk yourself—the platform provides no fallback or guidance.

If you do not have an OKX account yet, you can use the referral code 24U2795 when registering through this site; the referrer field is optional in the registration form. However, this code has no connection to market maker onboarding—market maker applications go through a separate business and review process and do not depend on the referral relationship of a regular registration.