# 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](https://www.bitget.com/academy/what-is-reality-protocol-and-rtokens-rwa-tokenization-defi-guide).
- [Bitget Stock Spot Trading FAQ: rTokens, Dividends, Fees, and Trading Hours](https://www.bitget.com/support/articles/12560603887176)
## 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](/docs/catalog/trading/order-management#place-order) and
[Place Reality Order](/docs/catalog/reality/trading#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 `internalization` for quoting/market-making flow that you intend to keep entirely within Super Match.
- Use `lit_market` for 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](/docs/catalog/trading/order-management#place-order) and
[Place Reality Order](/docs/catalog/reality/trading#place-reality-order) for the exact session-boundary rules.
:::warning{title="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`.
- 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 `internalization` resting order that is passively matched inside Super Match is recorded
as **maker**; every other fill — including all `lit_market` fills and any portion of an `internalization` order
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](/docs/catalog/market/market-data#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](/docs/catalog/market/market-data#get-tickers) | Pass an rToken symbol (e.g., `RMUUSDT`) to `symbol` to get its ticker data |
| [Get Reality OrderBook](/docs/catalog/reality/market-data#get-reality-orderbook) | Get the merged (onshore + offshore) order book depth snapshot. Requires whitelist access |
| [Reality Orderbook Channel](/docs/uta/websocket/reality/public/Reality-OrderBook-Channel) | Subscribe to the merged (onshore + offshore) order book depth. Requires whitelist access |
| [Get Reality OrderBook Segmented](/docs/catalog/reality/market-data#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](/docs/uta/websocket/reality/public/Reality-OrderBook-Segmented-Channel) | Subscribe to the segmented depth (onshore/offshore quantities reported separately). Requires whitelist access |
| [Get Kline/Candlestick](/docs/catalog/market/market-data#get-kline-candlestick) / [Get Kline/Candlestick History](/docs/catalog/market/market-data#get-kline-candlestick-history) | Get rToken candlestick data
- Note: For candlesticks before July 9, 2026, `volume`/`turnover` may be empty |
| [Candlestick Channel](/docs/uta/websocket/public/Candlesticks-Channel) | Subscribe to rToken candlestick data
|
| [Get Recent Public Fills](/docs/catalog/market/market-data#get-recent-public-fills) | Returns Bitget-platform fills executed internally (onshore) for rToken trading pairs |
| [Public Trades Channel](/docs/uta/websocket/public/New-Trades-Channel) | Outside of US market trading hours, this channel also pushes internally (onshore) executed trades for rToken trading pairs |
| [Get Reality Fills](/docs/catalog/reality/market-data#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 |
:::warning{title="Notes for Reality (rToken) candlesticks"}
- rToken only supports the `market` candlestick type.
- rToken only supports the `1m`, `5m`, `15m`, `1H`, `4H`, `1D` intervals.
- For the WebSocket Candlestick Channel, the `1m` interval push data does not include `volume`/`turnover`.
:::
### Depth: merged vs. segmented
[Get Reality OrderBook](/docs/catalog/reality/market-data#get-reality-orderbook) /
[Reality Orderbook Channel](/docs/uta/websocket/reality/public/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](/docs/catalog/reality/market-data#get-reality-orderbook-segmented) /
[Reality Orderbook Segmented Channel](/docs/uta/websocket/reality/public/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.
:::note{title="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](/docs/uta/websocket/public/New-Trades-Channel) (`publicTrades`) | Not available for rToken pairs | Pushes internal (onshore) trades |
| [Get Recent Public Fills](/docs/catalog/market/market-data#get-recent-public-fills) (`fills`) | Internal (onshore) trades only | Internal (onshore) trades only |
| [Get Reality Fills](/docs/catalog/reality/market-data#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](/docs/catalog/reality/market-data#get-stock-info) | Get the underlying US stock information for a specified rToken trading pair |
| [Get Market States](/docs/catalog/reality/market-data#get-market-states) | Get the current US stock market trading session status (pre-market/regular/after-hours/overnight) |
| [Get Market Calendar](/docs/catalog/reality/market-data#get-market-calendar) | Get the market holiday and closure calendar for US stocks |
## Trading
| API | Description |
|:----------------------------------------------------------------------------------------------|:-----------------------------------------------------------------------------------------------|
| [Place Reality Order](/docs/catalog/reality/trading#place-reality-order) | rToken order placement endpoint. Default rate limit:5/sec/UID; whitelisted users:30/sec/UID |
| [Cancel Reality Order](/docs/catalog/reality/trading#cancel-reality-order) | rToken order cancellation endpoint. Default rate limit:5/sec/UID; whitelisted users:30/sec/UID |
**Note:** The regular UTA [Place Order](/docs/catalog/trading/order-management#place-order) and [Cancel Order](/docs/catalog/trading/order-management#cancel-order) endpoints and the WebSocket [place-order](/docs/uta/websocket/private/Place-Order-Channel)/[cancel-order](/docs/uta/websocket/private/Cancel-Order-Channel) 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:
```
41121 Abnormal trading detected. Limit order functionality has been restricted.
```
**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](/docs/catalog/account/assets-balance#get-account-assets) endpoint to query them.