Maker Integration
Who can quote
The discovery feed is public — no authentication is required to subscribe. Private deliveries require view_orders; submitting and confirming quotes require place_orders; withdrawing a quote requires cancel_orders. Quoting is all-WebSocket: one authenticated connection can carry discovery, private deliveries, and the quote actions.
The complete maker workflow
Code
Pseudocode:
Code
Quoting rules
- One immutable quote per account per RFQ. No revisions; withdrawing does not free the slot. Price it right the first time.
- Price is per contract, strictly between 0 and 1, on the venue price tick. The default tick is
0.001. - Quantity is your maximum and must cover the complete request to be eligible. A notional-sized RFQ requires
quantity × price >= notional; a quantity-sized RFQ requiresquantity >= requestedQuantity. The execution size isfloor(notional ÷ price)contracts for a notional-sized RFQ orfloor(requestedQuantity)for a quantity-sized one. validUntilis a close-time eligibility deadline. If supplied, it must be in the future. A quote remains eligible whenvalidUntil >= w; a value beforewexpires the quote at close. If omitted, the service sets it tow. It is not checked again after winner selection.- The auction is side-effect-free while quoting. Submission performs a collateral preflight but does not reserve funds. At close, the venue freshly checks candidates in price-time order and falls through to the next quote when a maker lacks available collateral. The requester and maker collateral holds are placed later, at requester acceptance and maker confirmation respectively.
Execution and partial-fill risk
The RFQ's full-size guarantee applies to the requester's fill-or-kill order, not to the selected maker's post-only order.
After the maker confirms, the venue places the maker's order first. Other market participants can trade against it before the requester's order arrives, so the maker can receive a partial fill. If the requester order then fails, the venue cancels only the maker order's unfilled remainder; completed maker fills remain and may create or change a position even though the RFQ ends in FAILED.
The reverse is also possible: the requester can fill in full against other resting liquidity, allowing the RFQ to reach FINALIZED while the selected maker fills only part, or none, of the quoted quantity. Monitor the standard authenticated order, position, and balance streams for actual maker fills rather than inferring them from the RFQ state or f.
Timing
The lifecycle uses a 1-second quoting window, a 5-second requester decision window, and a 1-second maker confirmation window. The authenticated acceptance does not carry a separate confirmation-deadline field. The confirmation window starts when the RFQ enters CONFIRMING, so respond immediately when the ACCEPTED delivery arrives.
| Phase | Timing |
|---|---|
| Maker quoting | Submit or withdraw strictly before w on the public requestForQuote broadcast. w is 1 second after RFQ creation. |
| Your quote's validity | Quote-scoped private deliveries mirror validUntil in vu. The quote is eligible when validUntil >= w; omitting it assigns w. The field has no effect after selection. |
| Requester decision | The requester has 5 seconds from the PENDING_ACCEPTANCE transition to accept the selected quote. |
| Maker confirmation | Confirm or decline strictly before the 1-second deadline measured from the CONFIRMING transition; otherwise the RFQ fails. |
| Hard auction expiry | x (number) on the public broadcast is the absolute upper bound and can shorten either post-close window. |
Authenticated lifecycle deliveries include a durable event ID in i. Treat i as an idempotency key because an at-least-once delivery can repeat the same transition.
Anonymity
- The requester receives no quote submission or withdrawal events while the auction is open. After close, only the selected quote is disclosed; losing quotes remain undisclosed.
- Your identity is never revealed to the requester — quotes are keyed by
quoteIdonly. - The public feed never carries quote contents; losing quotes are never disclosed.
What's not covered here
- Opening RFQs (the requester side) is a retail-facing flow in the Gemini app and website; there is no public API for creating RFQs.
- Settlement mechanics of the resulting combo position follow the standard combo contract lifecycle — see Combo Contracts.
See also
- Quote Methods — full parameter and error tables.
- WebSocket Streams — message shapes.
- Examples — a worked auction end to end.