rToken Trading Guide
Overview
rToken refers to Bitget's tokenized US stock trading pairs, identified by symbols prefixed with r (e.g.,
rAAPLUSDT).
For more details about rToken, please refer to:
- Introduction to the Reality Protocol and rToken Tokenization.
- Bitget Stock Spot Trading FAQ: rTokens, Dividends, Fees, and Trading Hours
Order Routing & Matching Mechanism
rToken orders are matched through Super Match, an internal matching layer that sits between Bitget's trading engine and the external broker (used to route unmatched order flow to the US stock market). Every rToken spot order — regardless of whether the US market is open — is first evaluated by Super Match before any unmatched quantity is routed externally.
Order parameter venue: choosing where your order can match
The venue parameter (available on Place Order and
Place Reality Order) controls routing behavior:
venue value | Behavior |
|---|---|
internalization | The order only ever matches inside Super Match, Bitget's internal matching engine. It is never forwarded to the external broker, is not affected by market open/close transitions, and does not participate in the weekend/Monday-pre-open batch re-routing of resting orders. |
lit_market (default) | Super Match first attempts to match the order internally. Any unmatched quantity is then routed to the external broker (lit market). |
As a general guideline:
- Use
internalizationfor quoting/market-making flow that you intend to keep entirely within Super Match. - Use
lit_marketfor flow where you want unmatched quantity to also reach the external broker (e.g., building or reducing inventory).
Order validity is controlled separately via rTokenTimeInForce: gtd (valid for the current trading session) or
gtc (valid for 90 days). See the field descriptions on Place Order and
Place Reality Order for the exact session-boundary rules.
Order modification is not supported
rToken orders cannot be modified. To change the price or quantity of a resting order, cancel it and place a new one.
When your resting order gets filled (market hours)
During US market trading hours, Super Match determines whether your resting limit order can be matched internally using a dynamic price band around the NBBO (National Best Bid and Offer):
- ΔP is a per-order, real-time estimate of the additional slippage a retail order would incur if it were instead routed directly to the external broker. ΔP is calculated per order (not a fixed constant) and widens with the order's size relative to average daily volume, current volatility, the NBBO spread, and how thin external liquidity is at that moment. (ΔP is currently set to 0 and is subject to change in the future.)
- The tradable price band for internal matching is [NBB − ΔP, NBO + ΔP]:
- A retail buy order can match against any resting internal sell (ask) order priced at or below
NBO + ΔP. - A retail sell order can match against any resting internal buy (bid) order priced at or above
NBB − ΔP.
- A retail buy order can match against any resting internal sell (ask) order priced at or below
- Matching within the band walks the book level by level (not only the best level) until the incoming order is
filled or the band is exhausted. Any quantity that cannot be matched within the band is routed externally
(subject to
venue). - The execution price is your resting (quoted) price — not the NBBO, and not the band boundary. If your resting
ask is inside the band and gets hit, the retail taker pays your quoted price, not
NBO + ΔP. This means the full spread captured between your quote and the NBBO accrues to you as the market maker.
Outside regular US market trading hours (pre-market / after-hours / overnight / weekends / holidays)
Outside of regular US market trading hours there is no live NBBO and the external broker is unavailable, so Super Match's internal order book is the only source of pricing. Matching follows standard price-then-time priority, with no ΔP band involved. To prevent erroneous pricing while the market is closed, orders are validated against a price guard: reference price × an off-hours price deviation limit. Orders priced outside that bound are rejected. (The reference price is the last closing price, and the off-hours price deviation limit is currently 20%.)
Pre-market and after-hours sessions are an intermediate case: the NBBO still exists, but external liquidity is thin, so the internally tradable price range is effectively wider than during regular hours.
Liquidity direction
- Only the portion of an
internalizationresting order that is passively matched inside Super Match is recorded as maker; every other fill — including alllit_marketfills and any portion of aninternalizationorder that actively takes liquidity — is recorded as taker.
Core Trading Capabilities
| Category | Function | Implementation | Access | Protocol Support |
|---|---|---|---|---|
| Market Data | Instruments | Reused existing endpoint, returns isReality flag | Public | REST |
| Market Data | Ticker | Reused existing endpoint | Public | REST |
| Market Data | Candlesticks | Reused existing endpoint | Public | REST + WebSocket |
| Market Data | OrderBook (Depth) | Reality-specific endpoint | Whitelist required | REST + WebSocket |
| Market Data | Platform Fills | Reality-specific endpoint | Whitelist required | REST only |
| Market Data | Stock Reference Data (stock info/market states/market calendar) | Reality-specific endpoint | Public | REST only |
| Trading | Place Order | Reality-specific endpoint + regular UTA place-order endpoint | Public | REST + WebSocket |
| Trading | Cancel Order | Reality-specific endpoint + regular UTA cancel-order endpoint | Public | REST + WebSocket |
| Trading | Modify Order | Not supported yet | — | — |
| Trading | Batch Operations | Not supported yet | — | — |
| Assets | Asset Balances | Reused existing endpoint | Public | REST + WebSocket |
Note: Reality market data endpoints are currently only open to whitelisted users. Please contact your BD to apply.
Market Data
| API | Description |
|---|---|
| Get Instruments | rToken can be identified via the isReality field. yes indicates a Reality stock token, no indicates a non-Reality stock token |
| Get Tickers | Pass an rToken symbol (e.g., RMUUSDT) to symbol to get its ticker data |
| Get Reality OrderBook | Get the merged (onshore + offshore) order book depth snapshot. Requires whitelist access |
| Reality Orderbook Channel | Subscribe to the merged (onshore + offshore) order book depth. Requires whitelist access |
| Get Reality OrderBook Segmented | Get the order book depth snapshot with onshore (internal) and offshore (external) quantities reported separately. Requires whitelist access |
| Reality Orderbook Segmented Channel | Subscribe to the segmented depth (onshore/offshore quantities reported separately). Requires whitelist access |
| Get Kline/Candlestick / Get Kline/Candlestick History | Get rToken candlestick data - Note: For candlesticks before July 9, 2026, volume/turnover may be empty |
| Candlestick Channel | Subscribe to rToken candlestick data |
| Get Recent Public Fills | Returns Bitget-platform fills executed internally (onshore) for rToken trading pairs |
| Public Trades Channel | Outside of US market trading hours, this channel also pushes internally (onshore) executed trades for rToken trading pairs |
| Get Reality Fills | Query the latest 100 platform fill records for rToken from the last 3 months, covering both market hours and off-hours. Requires whitelist access |
Notes for Reality (rToken) candlesticks
- rToken only supports the
marketcandlestick type. - rToken only supports the
1m,5m,15m,1H,4H,1Dintervals. - For the WebSocket Candlestick Channel, the
1minterval push data does not includevolume/turnover.
Depth: merged vs. segmented
Get Reality OrderBook / Reality Orderbook Channel return the merged depth — onshore (Super Match internal) and offshore (external broker) liquidity combined into a single view of each price level, without distinguishing where the liquidity originates.
Get Reality OrderBook Segmented / Reality Orderbook Segmented Channel return the same price levels but report onshore and offshore quantities separately at each level, so you can see how much of the depth at a given price is internal versus external.
Both WebSocket channels push depth updates at the same cadence: every 500ms when the depth snapshot has changed, or every 10s if it has not changed.
Additional notes
During market hours (pre-market/regular/after-hours), the Bitget API/WebSocket returns/pushes market-maker depth
data in addition to the top-of-book levels present in the US stock market's L2 data. The order book shown to
App/Web users, however, filters out levels that are not also present in the US stock market's L2 data, rounds
displayed quantities down, and merges price levels at a coarser precision.
This is a display-only behavior
for the Web/App front end — it does not affect which levels are actually matchable via Super Match.
Standard depth channels behave differently for rToken pairs
Outside of the rToken-specific endpoints above, the standard depth channels change behavior for rToken trading pairs:
| Channel / Endpoint | During US market trading hours | Outside US market trading hours |
|---|---|---|
WebSocket books1 | Pushes the merged best bid/ask, as usual | Continues to push the merged best bid/ask |
WebSocket books5 / books50 / books | Does not push for rToken pairs | Pushes internal (onshore) depth only; every 30s if unchanged |
REST standard order book (orderbook) | Returns only 1 level for rToken pairs | Returns the full internal (onshore) depth, up to the requested limit |
Trade data coverage
| Source | During US market trading hours | Outside US market trading hours |
|---|---|---|
Public Trades Channel (publicTrades) | Not available for rToken pairs | Pushes internal (onshore) trades |
Get Recent Public Fills (fills) | Internal (onshore) trades only | Internal (onshore) trades only |
| Get Reality Fills (whitelist) | Full coverage (internal + external) | Full coverage (internal + external) |
| Private Fast Fill channel | Covers both internal and external fills for your own orders | Covers both internal and external fills for your own orders |
Stock Reference Data
The following endpoints provide reference information about the underlying US stock for rToken (tokenized US stock) trading pairs. These are all public endpoints and do not require whitelist access.
| API | Description |
|---|---|
| Get Stock Info | Get the underlying US stock information for a specified rToken trading pair |
| Get Market States | Get the current US stock market trading session status (pre-market/regular/after-hours/overnight) |
| Get Market Calendar | Get the market holiday and closure calendar for US stocks |
Trading
| API | Description |
|---|---|
| Place Reality Order | rToken order placement endpoint. Default rate limit:5/sec/UID; whitelisted users:30/sec/UID |
| Cancel Reality Order | rToken order cancellation endpoint. Default rate limit:5/sec/UID; whitelisted users:30/sec/UID |
Note: The regular UTA Place Order and Cancel Order endpoints and the WebSocket place-order/cancel-order channels now support Reality trading pairs, subject to a separate rate limit for rToken orders.
Order modification is not supported. Batch order placement and batch cancellation are not supported for rToken
trading pairs — if you need to adjust a resting order, cancel it and place a new one individually.
Limit Order Trading Rules for rToken
1. Trigger conditions
The system monitors the status of terminal orders for each UID on each trading pair over a statistical cycle. The limit order function will be restricted when both of the following conditions are met:
- The total number of terminal orders for a single UID on a single trading pair exceeds 2,000 within the statistical cycle;
- The fill rate is below 10%.
Filled order: an order that is fully filled.
Fill rate = number of filled orders / total number of orders.
2. Restriction details
Once the above conditions are triggered, the spot limit order function for the corresponding trading pair of that UID will be restricted.
When the user attempts to submit a limit order, the system will return:
Code
3. Automatic lifting mechanism
- If the UID triggers the above conditions again in the next statistical cycle, the limit order restriction will remain in effect;
- If the restriction conditions are not triggered again within a new statistical cycle, the system will automatically lift the restriction and resume normal limit order functionality;
- The system recalculates and re-evaluates at the start of each new statistical cycle (04:00 UTC+8 daily).
Please use the limit order function reasonably and avoid high-frequency, large-volume orders with abnormally low fill rates.
Assets
rToken assets have no dedicated asset query endpoint — reuse the existing Get Account Assets endpoint to query them.