# 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)
- [Transfer US Stocks to Bitget](https://www.bitget.com/support/articles/12560603897720)
## 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 |
|:-------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------|
| 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`.
:::warning{title="venue enum adjustment (effective November 5, 2026)"}
- `internalization` is renamed to `internal_market` with no change in meaning. Please replace this enum value with `internal_market`.
- Orders previously shown as `lit_market` in order details (matched internally at the best price first, with any unfilled portion submitted to the broker) are now shown as `default`. Please update your order-detail parsing logic accordingly.
- The new `lit_market` means "orders are submitted to the broker for execution and are not matched within the exchange", which differs from the meaning of `lit_market` shown in order details before the adjustment. Please distinguish between the two carefully.
:::
**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](/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
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](/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 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](/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. 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](/docs/catalog/reality/trading#cancel-reality-order) | rToken order cancellation endpoint. Rate limit follows the same rules as Crypto |
**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. 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
:::warning{title="Scope"}
These rules apply to off-exchange trading only; on-exchange trading is not subject to these restrictions.
:::
**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.
## 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](https://www.bitget.com/trade-info/discount-rate).
**How to enable and more details:** [How Does Delta Neutral Mode Work in the Unified Trading Account?](https://www.bitget.com/support/articles/12560603881602)
### 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](/docs/catalog/market/market-data#get-instruments) (`category=SPOT`) |
| Bitget Futures trading pair | Stock ticker + USDT | `AAPLUSDT` | `instrumentType` = `stock` / `etf` in [Get Instruments](/docs/catalog/market/market-data#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](/docs/catalog/reality/trading#place-reality-order),
or the UTA [Place Order](/docs/catalog/trading/order-management#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](/docs/catalog/trading/order-management#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](/docs/uta/websocket/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](/docs/catalog/reality/market-data#get-reality-orderbook-segmented)
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](/docs/catalog/account/assets-balance#get-account-assets) endpoint to query them.