How a quote becomes a swap
RFQ stands for request for quote. Instead of posting standing orders or depositing assets into a pool, the market maker prices each request as it arrives:
- Request. A user asks Jupiter to swap one token for another. Jupiter sends the pair and size to connected market makers.
- Quote or decline. Each market maker either returns a firm price for that exact size or declines. Declining a pair or size it does not want to serve is part of the design.
- Acceptance. If the user accepts a route that uses the quote, the swap is passed to the market maker.
- Settlement. The market maker checks and signs its side of the transaction, and the trade settles on-chain, visible like any other Solana transaction.
Jupiter documents two integration paths that run side by side: a webhook-based version and a newer streaming version. According to Jupiter, the streaming version does not replace the webhook version, and market makers can integrate with either or both. Timing rules and other parameters are set by Jupiter and can change, so always check the current documentation rather than figures quoted elsewhere.
RFQ, pools and order books are different routes
RFQ prices are made on request, for a specific size. A pool (AMM) prices trades from the assets deposited in it, according to its formula. An order book shows standing bids and offers that anyone can hit. Each route needs different capital, different controls and different measurements.
For most Solana tokens, RFQ is an addition to pool liquidity, not a replacement. Our guide to designated market making explains the three routes in more detail.
What a market maker needs to quote your token
A token is not quotable on RFQ simply because it trades on Solana. Before a market maker can answer requests for it responsibly, four things must be in place:
| Requirement | Why it matters |
|---|---|
| A reliable pricing input | Every quote is a firm price. Without a reference price the desk can trust, and a rule for when that reference is stale, quoting is unsafe. |
| Inventory on both sides | The market maker must hold the token and the quote asset, with the required token accounts, before it can fill. Jupiter expects makers to advertise only tokens they can actually fill. |
| Technical onboarding | Jupiter onboards market makers through its own integration tests and a pre-production stage before a maker goes live. A new token also has to pass the maker’s own validation. |
| Risk limits | Agreed limits on inventory, size and price movement, and a clear rule for pausing, keep the mandate from turning into an open-ended position. |
The pricing input is often the deciding factor for smaller tokens. Our guide to market making for a low-volume token covers this constraint.
What RFQ cannot do
- It does not create demand. Quotes are only requested when users want to swap. A market maker cannot generate that flow.
- It does not guarantee fills. Whether a quote is used depends on the user’s request and the other routes available at that moment.
- It allows declines. A market maker may decline sizes or directions outside its limits, for example when inventory is one-sided.
- It does not replace a pool. If no RFQ quote is available, the swap still needs on-chain liquidity elsewhere.
A proposal that promises a fixed volume or a price level through RFQ deserves careful reading.
How to evaluate an RFQ market maker for your token
Agree measurements that fit the route. Order-book depth and pool price impact are not meaningful for RFQ; quote behaviour is.
- Quote quality at agreed sizes: how the quoted price compares with a stated reference, measured at the order sizes your users actually trade.
- Availability and declines: over which hours the maker quotes your token, and when and why it declines.
- Settlement reliability: whether accepted quotes are completed on-chain, and how failures are reported.
- Inventory and limits: who supplies the inventory, how it is rebalanced, and what happens when a limit is reached.
- Evidence: quotes, fills, fees and inventory movements that can be reconciled against on-chain records.
Our guide to measurable execution targets turns these into questions for a written proposal.
Where Astrum stands
Astrum is a trading and market-making desk operating its own capital. Our current live execution runs on Jupiter RFQ on Solana and on 1inch Fusion, where we act as an approved resolver on Solana, Ethereum and Base.
Live operation on Jupiter RFQ does not mean every Solana token can be supported. Each token is assessed on its own: pricing input, inventory, trade sizes and technical validation come first, and the scope is agreed in writing before any quoting starts. For our own measured activity and its coverage limits, see the monthly record.
Discuss your Solana token.
Send your token mint address, current venues, typical trade sizes and timeline. We’ll assess whether RFQ quoting fits and what it would require. For the full service scope, see our Solana liquidity services.
Discuss token liquiditySources and scope
RFQ mechanics in this guide follow Jupiter’s official developer documentation: the RFQ overview, the webhook API, quoting and fills and the streaming integration, as published in October 2026. Jupiter can change these rules; its documentation takes precedence over this summary. This guide describes Jupiter’s system and does not imply endorsement of Astrum by Jupiter or eligibility of any particular token.
Published 17 October 2026. Prepared by Astrum Liquidity; meet the founder. This guide is general information, not investment or legal advice.