Create RFQ

Creates an RFQ for the authenticated account.

RFQ creation is asynchronous. Subscribe to the private WebSocket channel rfq before sending the request. A successful HTTP response is 202 Accepted and contains a Paradex request_id; it confirms only that the command was queued. The later WebSocket RESULT event with the same request_id reports whether the venue accepted the command. On success, the event’s top-level rfq_id is the venue-issued identifier used by the read, execute, cancel, and filtered-subscription APIs.

The request accepts up to 25 legs. It must contain at least one strategy leg, represented by omitting price. At least one strategy leg must have side=BUY, and at least one must have ratio=1. A hedge leg is marked by any strictly positive price; the value is ignored and the leg is fixed at the market’s mark price when the RFQ is created, rounded to the nearest price increment. A mark below half an increment is rejected. All quantities and ratios are positive decimal strings. Every leg market must exist on Paradex and be available for RFQ. The strategy quantity must be at least the largest minimum block size among its strategy legs.

The optional side commits the RFQ to one direction of the strategy, BUY or SELL, read the same way as a leg’s side. Omitting it leaves the RFQ two-way. Makers always quote both directions either way; what the commitment changes is the taker’s own side. A committed RFQ may only be executed in that direction, an execute on the other one is rejected, and the collateral held against it covers that direction alone instead of the more expensive of the two. So committing is cheaper for a taker who already knows which way they are going.

An account may hold only one two-way RFQ open at a time, and any number of committed ones up to a total limit. An RFQ stays open until the venue closes it. Cancelling is what closes it, but the cancellation is asynchronous: an account is normally free to create its next two-way RFQ once the WebSocket RESULT event for the cancel reports success, not when the cancel request is sent. A create issued before that, or immediately after it, may be rejected by a RESULT event saying the account already has an RFQ open, and can be retried.

The platform selects eligible counterparties; a client-supplied counterparties value is ignored. The optional strategy field is a draft label and is not sent to the venue.

The optional max_slippage sets the collateral held against this RFQ while it is open, as a fraction of the underlying’s spot price. It replaces the configured bound, must be greater than zero and at most 1, and applies to every underlying the strategy touches; the market’s own price band caps it, so a value beyond the band holds no more. A wider value holds more collateral.

It does not limit the price this RFQ may execute at. A quote worse than it may still be executed: what the execution actually costs is charged against the account at that point, so it is accepted while the account meets its margin requirement at the agreed price. The market’s price band is what bounds the execution, applied to the resulting trade.

Validation or risk-check failures that occur after queueing are reported by the WebSocket RESULT event. Its result.allowed_side is the direction the RFQ was accepted for: the committed side when the request carried one, TWO_WAY when it did not, and BUY or SELL when a two-way request was accepted for one direction only because the account cannot sustain the other.

result.allowed_side is what the commitment and the reserve above are stated in, so it, and not the side that was sent, is the answer to read. Where Paradex does not risk-check the create it is empty, and a side sent with that request commits nothing: the RFQ is two-way, and either direction may be executed.