Copy page

Overview

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
• Transfer US Stocks to Bitget

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
Omitted (default strategy; order details return default)	Super Match first attempts to match the order internally at the best price. Any unmatched quantity is then routed to the external broker (lit market). For certain trading pairs that are tradable on weekends, resting orders still unmatched externally are moved back to the internal order book, and if they remain unmatched over the weekend, they are routed externally again to continue resting;
internal_market	The order only ever matches inside Super Match, Bitget's internal matching engine. It is never submitted to the US stock 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	The order is submitted directly to the US stock broker for execution and is not matched within the exchange (Super Match).

The accepted venue values when placing an order are internal_market and lit_market; omitting venue applies the default strategy. In order details (REST order queries and WebSocket order pushes), venue is returned as one of default / internal_market / lit_market.

As a general guideline:

• Use internal_market for quoting/market-making flow that you intend to keep entirely within Super Match.
• Omit venue (default strategy) for flow where you want internal price-compared matching first, with unmatched quantity also reaching the external broker (e.g., building or reducing inventory).
• Use lit_market for flow you want submitted directly to the US stock broker without internal matching.

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.

When your resting order gets filled

Default strategy (venue omitted; order details return default)

During US market trading hours (pre-market, regular, after-hours, and overnight), 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.

Pre-market, after-hours, and overnight 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.

venue = internal_market

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, does not participate in the weekend/Monday-pre-open batch re-routing of resting orders, and is not subject to the NBBO price band.

venue = lit_market

The order is submitted directly to the US stock broker for execution and is not matched within the exchange (Super Match), so it does not take part in the internal price-band comparison.

When your order takes liquidity (US market trading hours)

Default strategy (venue omitted; order details return default)

When your order enters Super Match as the taker, the system first compares prices, then determines how much is matched internally and how much is routed externally:

1. Price comparison: Super Match takes the better of the external quote (including ΔP) and the best internal level as the best price:

   • Best ask = MIN(NBO + ΔP, best internal ask)
   • Best bid = MAX(NBB − ΔP, best internal bid)

   The order enters internal matching when the buy price ≥ the best ask, or the sell price ≤ the best bid.

2. Internal matching: The order takes resting internal orders within the price band level by level, in price priority — a buy order takes up to NBO + ΔP, and a sell order takes down to NBB − ΔP. The execution price is the counterparty's resting price.

3. Routing the remainder: Once internal liquidity within the band is exhausted, the remaining quantity is routed to the external broker (subject to venue; internal_market orders are never routed externally). If the notional value of the remaining quantity to be routed is less than 2 USD, the order goes directly to a terminal state and is not submitted to the external broker.

Market orders are internally converted into limit orders valid for 2 seconds, with limit price = last traded price × (1 ± slippage (max 1%)). Any quantity still unfilled after 2 seconds is automatically canceled.

Example: A user places a market order to buy 2.5 shares of TSLA. The last price is 100 USD and slippage is 1%, so the order enters Super Match as a limit order at 101 USD. Assume NBO = 100 USD, ΔP = 0.5 USD, and the best internal ask is 1.2 shares at 99.8 USD:

• Price comparison: best ask = MIN(100.5, 99.8) = 99.8 USD; the buy price 101 ≥ 99.8, so the order enters internal matching;
• Internal matching: the 1.2 shares at 99.8 USD are below NBO + ΔP = 100.5 and are fully filled at 99.8 USD; there are no more in-band resting orders internally, so internal matching ends;
• Routing the remainder: the remaining 1.3 shares (≥ 2 USD) are routed to the external broker and filled.

In the end, 1.2 shares are filled internally and 1.3 shares externally, and the order is fully filled.

venue = internal_market

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, does not participate in the weekend/Monday-pre-open batch re-routing of resting orders, and is not subject to the NBBO price band.

venue = lit_market

The order is submitted directly to the US stock broker for execution and is not matched within the exchange (Super Match), so it does not take part in the internal price-band comparison.

Outside regular US market trading hours

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%.)

Liquidity direction

• Only the portion of an internal_market resting order that is passively matched inside Super Match is recorded as maker; every other fill — including all fills of default-strategy (default) and lit_market orders, and any portion of an internal_market 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	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

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.

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 10s 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. Rate limit depends on venue: internal_market (on-exchange) follows the Crypto rate limit, 10/sec/UID; the default strategy (venue omitted) and lit_market (off-exchange) default to 5/sec/UID, 30/sec/UID for whitelisted users
Cancel Reality Order	rToken order cancellation endpoint. Rate limit follows the same rules as Crypto

Note: The regular UTA Place Order and Cancel Order endpoints and the WebSocket place-order/cancel-order channels now support Reality trading pairs. For order placement the rate limit depends on venue (on-exchange follows the Crypto rate limit, off-exchange follows the rToken rate limit); for order cancellation the rate limit follows the same rules as Crypto.
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
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.

Trading Strategies & Use Cases

Delta Neutral Mode

Overview and use cases

Delta Neutral Mode is a toggle in the trading settings of the Unified Trading Account's (UTA) "Advanced Mode", designed for traders running hedging strategies such as funding rate arbitrage and basis arbitrage within the UTA. When enabled, qualifying hedged positions are moved to the back of the auto-deleveraging (ADL) queue — they are only reached after all non-qualifying positions have been processed — reducing the chance that a hedged position is auto-deleveraged in extreme market conditions and leaves the strategy with a "broken leg". This mode only affects ADL ranking priority; it does not change margin calculation, liquidation rules, or risk control policies.

Delta Neutral Mode now supports treating an rToken and its underlying stock as the same asset for hedging calculations. For example, rAAPL and AAPL are calculated together: a user's rAAPL spot holding and AAPLUSDT futures position can form a hedged position and jointly participate in hedge determination and ADL ranking protection. This extension takes effect automatically once the conditions are met, with no additional settings required. This means users can use rToken spot, priced at the "real stock price", as the long leg and the highly liquid stock perpetual futures as the short leg, completing the hedge within a single UTA — while the spot holding itself continues to serve as futures margin.

Typical use cases include: funding rate arbitrage, holding rToken spot and shorting the futures on the same underlying to collect positive funding; basis arbitrage, buying spot and shorting futures when futures trade at a premium to the rToken spot, then waiting for the spread to converge; and position protection, temporarily locking in price risk ahead of earnings or macro events while holding long-term US stock exposure.

Eligibility

Identity requirements: When enabling, you must meet any one of the following — VIP3 or above / Pro user / market maker / institutional loan user. The identity check is performed only once at the time of enabling; subsequent changes in identity do not affect the enabled status. Demo trading is not subject to identity requirements.

Additional rToken requirement: The rToken must be a margin coin supported by the UTA. For the list of rTokens currently supported as UTA margin, see Discount Rate | Bitget Unified Trading Account.

How to enable and more details: How Does Delta Neutral Mode Work in the Unified Trading Account?

Underlying Asset Mapping

rToken vs. underlying stock, spot and futures trading pairs

Each rToken is issued by the Reality protocol and backed 1:1 by a real US stock or ETF held in custody by a licensed broker. On Bitget, the same underlying stock may have both an rToken spot trading pair and a USDT-M stock perpetual futures contract. Naming conventions are as follows:

Instrument	Naming convention	Example (Apple)	How to identify via API
Bitget Spot trading pair	R + stock ticker + USDT	RAAPLUSDT	isReality = yes in Get Instruments (category=SPOT)
Bitget Futures trading pair	Stock ticker + USDT	AAPLUSDT	instrumentType = stock / etf in Get Instruments (category=USDT-FUTURES)

Asset mappings and scope

In Delta Neutral Mode, the following groups of coins are treated as the same asset: an rToken and its underlying stock futures (e.g., rAAPL and AAPL), BGBTC and BTC, BGSOL and SOL, and XAU, XAUT and PAXG.

Note the scope: hedging only applies within the "same underlying"; different assets cannot hedge each other. For example, using rQQQ to hedge an NVDAUSDT short, or using the leveraged ETF rTSLL (Direxion 2x long TSLA) to hedge TSLAUSDT, will not be recognized as a hedged position, because their underlying assets differ. In addition, holding large amounts of stablecoins or other assets cannot hedge the futures position of a given asset; isolated-margin futures positions are not included in the calculation; and the rToken itself must be on the UTA margin coin list.

Trading Examples

Prices and funding rates in the following examples are illustrative only and are used to explain the calculations. Refer to the actual order book, funding rates, and fee tiers in practice.

Example 1: rNVDA + NVDAUSDT funding rate arbitrage

Background: The user is a VIP3 institutional client with Delta Neutral Mode enabled in UTA Advanced Mode, and has 10,000 USDT in the account. NVDAUSDT funding has been consistently positive, and the user wants to collect funding without taking NVDA directional price risk.

Steps:

1. During US market hours, buy rNVDA with a limit order. Assume 50 shares are filled at an average price of 200 USDT, for a notional value of 10,000 USDT (API: Place Reality Order, or the UTA Place Order endpoint with category=SPOT, symbol=RNVDAUSDT; to route unfilled quantity to the US stock market, omit venue to use the default strategy);
2. After confirming the spot leg has actually filled 50 shares, short NVDAUSDT perpetual futures for 50 NVDA in cross-margin mode within the same UTA (API: the UTA Place Order endpoint with category=USDT-FUTURES);
3. The rNVDA holding is now 50 and the net futures position is −50 — opposite directions and equal size. The net futures position = 0 and the ratio is 0% ≤ 5%, so it is recognized as a hedged position and receives ADL ranking protection;
4. While holding, stock futures settle funding every 8 hours; when funding is positive, the short side receives it.

Example 2: Partial fill pushes the ratio over the limit, and rebalancing

Background: Same account as Example 1. The user first places a futures short for 53 NVDA, but the rNVDA limit buy order only fills 50 shares, and the remainder is unfilled.

Determination: rNVDA holding is 50 and the net futures position is −53, opposite directions with |50| < |−53|. Net futures position = |50 − 53| = 3; total position = MAX[50 + 0, |0 − 53|] = 53; ratio = 3 ÷ 53 ≈ 5.66% > 5%. The hedge condition is not met, and the asset participates in ADL ranking under the normal rules.

Resolution: Buy at least 1 more share of rNVDA to bring the ratio down to 2 ÷ 53 ≈ 3.77%, or reduce the futures short to 52 or less. Once the ratio falls back, the system automatically restores the hedged-position determination — there is no need to re-enable the toggle. In practice, "spot first, futures second" is recommended: drive the futures order size from the actual filled quantity of the spot leg, and use the private Fill channel to monitor fills on both legs in real time. Note that rToken orders cannot be modified; to change the price, cancel and place a new order.

Example 3: rTSLA + TSLAUSDT basis arbitrage

Background: During periods of exuberant sentiment, the TSLAUSDT perpetual trades at a premium to rTSLA spot. Assume the rTSLA spot price is 400 USDT and the TSLAUSDT futures price is 404 USDT, a premium of about 1%.

Steps: Buy 20 shares of rTSLA (about 8,000 USDT) and simultaneously short 20 TSLA of TSLAUSDT (about 8,080 USDT). The combined ratio is 0%, so it is recognized as a hedged position. When the futures premium converges to 0, close both legs at the same time: regardless of whether TSLA rises or falls, the locked-in spread profit is about 20 × 4 = 80 USDT (about 1%). If funding is positive while holding, the short side also collects funding.

Things to watch: During market hours, rTSLA execution prices are in sync with the US stock market, so the spread comes mainly from the futures-side premium; use the Reality segmented order book to assess internal and external depth before executing. Outside US market hours, rToken pricing relies on Super Match internal liquidity, orders are protected by "reference price × off-hours price deviation limit (currently 20%)", and depth is thinner — opening or closing large positions outside market hours is not recommended. Significant slippage on the other leg could wipe out the entire basis profit.

Assets

rToken assets have no dedicated asset query endpoint — reuse the existing Get Account Assets endpoint to query them.