Limit
The limit order kind: what it does, which of the 14 venues wire it, and how an unsupported combination is refused before it reaches a wire.
Limit — rests at a price and fills only at that price or better. It is one of the five canonical order kinds
(vike_model::venue_caps::ORDER_KINDS), the vocabulary a strategy submits in and every venue
adapter translates from. The names are the platform's, not any venue's wire strings: a bridge maps
limit onto whatever its exchange calls the same thing, and refuses the order outright where
the venue has no equivalent.
A limit order is the maker's instrument: it joins the book and waits, so it earns the maker side of the fee schedule and takes queue risk instead of spread cost. Whether it may ONLY make is the post-only capability, which is per venue.
Which venues take it
Rendered from each venue's capability row, which is read from what its adapter actually wires — not from what the exchange documents.
| Venue | Supported | |
|---|---|---|
| binance | yes | — |
| bybit | yes | — |
| okx | yes | — |
| deribit | yes | — |
| oanda | yes | — |
| ig | yes | — |
| fxcm | yes | — |
| dukascopy | yes | — |
| polymarket | yes | — |
| ibkr | yes | — |
| ctrader | yes | — |
| alpaca | yes | — |
| aster | yes | — |
| hyperliquid | yes | — |
14 of 14 venues wire it today.
Before it reaches a venue
Every order passes a preflight that refuses what a venue cannot do, with a machine-readable reason rather than a wire error: an unsupported kind, an unsupported time in force, a reduce-only flag on a venue that has none. That is what makes an unsupported combination a local, immediate, explicable refusal instead of a silent divergence between what you asked for and what rests on the book.
Where this comes from
vike_model::venue_caps's ORDER_KINDS and each venue's supported_order_kinds, exported as
rosters.json and venues.json at every release. Adding a venue reddens the capability table's
completeness test until its row is filled in, so the matrix above cannot be missing a venue.