OKX’s tool for large and multi-leg trades at firm prices. I brought building, monitoring and executing onto a single screen.
Before: build on one tab, monitor and execute on another.After: one tab to build, monitor and execute.
Request for Quote is OKX’s advanced trading experience for large or complex trades at firm prices. Instead of placing orders on a public order book, traders send an RFQ to several counterparties and get competitive buy and sell quotes in real time.
It supports predefined and custom multi-leg strategies across spot, derivatives and options in a single request, with two-click atomic execution that limits slippage and execution risk in volatile markets. Its users are advanced retail and institutional traders, for whom speed, clarity and confidence at execution matter most.
RFQ was a powerful tool, but the old experience added friction at exactly the moments when speed and clarity mattered most.
Building an RFQ happened on one tab and monitoring quotes and executing on another, while the same tab bar also led to Nitro Spreads, a separate product with a different mental model. Traders had to switch context at decision-critical moments, and the blurred boundary left them unsure where they were.
What changedUnify the workflow. Builder and board now live on one screen, so traders build, monitor and execute without losing context.
K-line charts, detailed position data and advanced controls filled the builder, yet feedback showed they were rarely used at this stage. Traders came to construct a strategy, not analyse the market, and adding legs or adjusting quantities competed with secondary data.
What changedReduce non-essential information. Charts and secondary market data came out, so the core actions lead.
Parts of RFQ still used legacy components that no longer matched the design system. In a high-stakes product, inconsistent patterns add cognitive load and visual mismatches lower perceived quality, which makes it harder to trust the tool with significant capital.
What changedMove to the design system. Standard components bring consistency, familiar patterns and a higher perceived quality.
Where should the builder live? I explored three answers before settling on one screen.
Traders land on the board and the builder opens over it. Fine for light tasks, but complex multi-leg strategies get confined to a temporary surface, adding context shifts.
Not chosen
Better continuity than a dialog, but the collapsible sheet invites constant expanding and collapsing, and less vertical space makes dense multi-leg setups harder to scan.
Not chosen
The builder sits above the board in one vertical layout. Building, monitoring and executing stay visible together, with no extra modes, which supports sustained focus on multi-leg strategies.
Chosen
1/5 Land on RFQ The builder starts minimised. Create RFQ, or the dropdown, expands it.
2/5 Pick token and strategy The builder expands. Choose a token and a strategy type.
3/5 Add legs Add legs to complete a multi-leg strategy.
4/5 Size it and choose who quotes Set instrument types and position sizes, and select counterparties.
5/5 Send, review, execute Send the RFQ and the builder collapses. Quotes arrive below to review and execute.
Builder, board and history live together. No tab switching, no lost context.
At the top, expanded or minimised as needed. Token and strategy selection is simplified and ordered by popularity.
Always visible below the builder, so every active quote is in view at a glance.
At the bottom: there when needed, out of the way during active trading.
Consolidating building, monitoring and execution into one workflow cut navigation friction. Traders built and evaluated RFQs with fewer context switches, which made comparing quotes and executing clearer, especially for complex multi-leg strategies.
The new structure and components also gave future RFQ work a more consistent, scalable foundation. In preliminary internal testing, the average time to build and send an RFQ dropped by about 20%.
Tell me about the role or the project.
