# Maker Integration :::caution **Status: Beta (v0.1) — dark-launched.** The discovery channel is implemented; **server-side filtering is not** — at v0.1 you receive every `requestForStream` event and filter client-side (PREDICT-4732). The filter model below describes the intended end state. Specific rebate values and operational policies are strawmen for partner review. These pages are intentionally not linked from the sidebar during the rollout. ::: This page covers the **RFS-specific** parts of integrating as a maker: how to discover newly opened combos and how combo trading integrates with existing maker programs. Order entry, cancel discipline, account events, SLAs, self-trade prevention, and margining are not RFS-specific — they apply on combo orderbooks the same way they apply on every other instrument on the venue. ## Who can quote on combos Anyone approved as a market maker on Gemini Predictions. No separate program, no separate gating, no separate obligations beyond the venue's existing maker-program terms. Combos use the same fee schedule, margin model, and settlement behavior as every other instrument on the venue, whether they were pre-listed or created by an RFS. For a firm already running an orderbook market-making operation, participating in RFS is a configuration change: subscribe to `requestForStream`, expand the universe of `comboSymbol`s your bot is willing to quote on, and continue using your existing order-entry plumbing. ## Discovery feed: `requestForStream` The single RFS-specific entry point. Subscribe once; receive every incoming request — whether it created a new combo or re-solicited liquidity on one that already exists. Either way it's a signal that there's fresh demand on `comboSymbol` worth quoting. ```js ws.subscribe(["requestForStream"]) ``` See [WebSocket Reference — `requestForStream`](/prediction-markets/combos-rfs/websocket-streams#requestforstream) for the full message shape and field keys. :::note v0.1: filter client-side At v0.1 the channel broadcasts **every** request to **every** subscriber — there is no server-side filter, and `assetClasses` is not yet populated (PREDICT-4732). Apply the matching logic below in your own client against the message fields (`l` legs, `st` structureTypes, `sz`/`n` size/notional). The filter dimensions and patterns in this section describe the intended server-side model and the client-side logic you'd implement today. ::: ### Filter dimensions (intended model) | Dimension | Match rule | |---|---| | Asset classes | **Subset match.** A request is admitted only if *all* of its asset classes are in your set. A crypto-only filter never sees a cross-class request that also touches macro or sports — you're never shown a structure you haven't opted to price in full. (Pending `assetClasses` population, PREDICT-4732.) | | Leg instrument globs | **Any match.** Admitted if at least one leg (`l[].i`) matches at least one glob. Standard `?`/`*` wildcards on instrument symbol. | | Min / max notional | Range match on the request's indicative size/notional (`sz` / `n`). | | Structure types | **Any / none match.** Admitted if the request's `st` carries at least one wanted value (and none excluded). Values: `SAME_EVENT`, `CROSS_EVENT`, `BASKET`, `SPREAD`, `CONDITIONAL`, `CROSS_CLASS`, `ANY`. | Combine dimensions with AND. All matching is content-based: it describes the request, not the taker. There is no taker-identity match because requests carry no taker identity. ### Maker archetypes and matching patterns Different desks specialize in different parts of the request universe. A few illustrative client-side matching profiles: **SGP specialist (one league):** sports legs (`l[].i` matching `GEMI-NFL-*`) tagged `SAME_EVENT`. **Cross-game sports book (uncorrelated parlays):** sports legs tagged `CROSS_EVENT` or `BASKET`, excluding `SAME_EVENT`. **Macro desk:** legs matching `GEMI-CPI-*`, `GEMI-FOMC-*`, `GEMI-NFP-*`, `GEMI-GDP-*`. **Cross-class generalist:** `st` includes `CROSS_CLASS` and indicative notional ≥ $50,000. A single firm may run multiple subscriptions on different connections to keep desks independent. ### From discovery to trading After a `requestForStream` event: note the `comboSymbol` (field `s`), decide whether to quote, and post regular orders on `comboSymbol` via the standard order-entry path. There is no RFS-specific order shape and no refresh primitive — your orders on the combo book are orders, and you decide how long they stay live. The full step-by-step and pseudocode are on the [WebSocket Reference](/prediction-markets/combos-rfs/websocket-streams#end-to-end-maker-flow). ### Timing: the first few seconds matter Many retail-facing clients wrap submission in a bounded "Fetching prices…" UI window — typically 5–15 seconds — during which the user is watching for a price to accept. Makers may quote tightest in this window, where the probability of an immediate fill is highest. After it, the combo book is just resting depth in the long tail; makers leave orders open or cancel them on their own schedule. The protocol enforces no window — the behavior is emergent from the retail UX pattern. Institutional bots see the same flow without the externally-imposed urgency. ## Rewards integration RFS-sourced volume composes into existing maker programs on equal terms with orderbook volume: - **Fees** follow the same [fee schedule](https://www.gemini.com/fees/predictions) as combo orderbook fills. - **Bootstrap rebate (proposed).** An additional rebate may layer on top of the existing maker rebate for trades on a combo within a short window after it first opens. Intended to encourage makers to quote on newly opened books before they build resting depth. Final structure under product review. - **[Maker Rebate Program](/prediction-markets/maker-rebate-program)** tier qualification counts combo volume identically to single-contract volume. - **[Liquidity Rewards Program](/prediction-markets/liquidity-rewards-program)** time-weighted quote-presence credit accrues for orders on combo books the same way it does for orders on any other instrument. ## Anonymity RFS requests carry no taker identifier on the wire. **Makers see the level of interest in the market — the legs being requested, the indicative side and size, the structure classification — but not who is taking.** The signal is "demand exists for this structure," not "this firm wants this trade." Once the combo book is open, orderbook anonymity follows the **standard combo orderbook model** — opaque session-scoped order IDs, no firm-level attribution in public data. There is no opt-in bilateral attribution. ## Hedge-leg access Combo makers hedge by trading the underlying single-contract orderbooks. RFS does not change hedging: - Order entry on `comboSymbol` and on each leg's single-contract book can share a connection family. - Latency between observing `requestForStream` and posting a hedge is the same as for any orderbook participant on equivalent connectivity. Co-location is available per the existing market-maker program. - There is no atomic "quote combo + simultaneously lift underlying" primitive. Hedges go through after fill, via the standard order entry path. The minimum-viable maker bot — subscribe to `requestForStream`, price the legs, post orders to `comboSymbol` — is shown as runnable pseudocode on the [WebSocket Reference](/prediction-markets/combos-rfs/websocket-streams#end-to-end-maker-flow). Everything after the order submission is the maker's existing infrastructure: cancel discipline, hedge mechanics, position reconciliation, reporting. RFS adds one channel; the rest is the maker's existing code path. ## What's *not* covered on this page Venue-wide concerns that apply to maker activity on combos but are not RFS-specific: - Order types, time-in-force, post-only flags, cancel-on-disconnect — standard order entry. - Fill-ratio SLA, matcher latency — venue-wide. - Self-trade prevention — venue policy by firm/group ID. - Margin and risk treatment — standard combo margining. - Settlement notifications, drop-copy, reporting cadence — standard. See the broader Predictions operational docs for those.