RPI Order

1. What is an RPI Order

2. Key Features of RPI Orders

• Applicable Contract Types Supports USDT perpetual contracts, USDC perpetual contracts, coin-margined perpetual contracts, and coin-margined delivery contracts.Please refer to the official announcement for the specific supported futures trading pairs.
• Post-only RPI orders can only act as passive maker orders and will not match immediately with existing orders. If an order immediately matches upon submission, it will be rejected by the system.
• Counterparty Restriction RPI orders can only be matched with non-API retail orders and will not execute against API or algorithmic orders.
• Matching Priority Rules
  • Among RPI orders, price-time priority applies.
  • At the same price level, non-RPI orders always take precedence over RPI orders regardless of order submission time.
• Order Book Visibility RPI orders are visible orders, and their valid price and quantity are displayed on the trading interface and provided through market data APIs.

 3. Example Scenario

• Submitting a sell RPI order at price 99 will be rejected by the system.
• Submitting a buy RPI order at price 99 will remain in the order book, waiting to be matched.
• Submitting a buy API order at price 100 will cause the sell RPI order at the same price (100) to become inactive and temporarily not participate in matching.

• Will not be automatically canceled by the system.
• Will be hidden from the trading interface and not counted in executable depth.
• Remain in the system and will automatically reactivate once market conditions allow matching again.

4. Dynamic Status of RPI Orders

• Inactive If market fluctuations cause the RPI order price to cross with non-matching orders, the RPI order becomes inactive.
• Active When the price condition is met again or unmatched, the RPI order automatically becomes active.
• Order Lifecycle Inactive RPI orders are not automatically canceled. Market makers should manage their orders and may choose to cancel or adjust prices as needed. The system automatically manages RPI order status, but the order itself does not disappear due to status changes; users must monitor and manage associated risks.

5. Submitting RPI Orders

• The order placement interface supports timeInForce = "RPI" parameter:
  • Single order placement
  • Batch order placement
• Order query and historical order interfaces return RPI identifiers to distinguish order types.

• Trade data returns an isRPITrade field to indicate if the trade originated from an RPI order.

• The order book API supports the RPIFilter parameter to control RPI depth visibility:
  • RPIFilter = 0: only non-RPI order book (default)
  • RPIFilter = 1: return both non-RPI and RPI order book
• When enabled, buy/sell depth will display separate quantities for non-RPI and RPI orders.

6. Order Book Display

• Trading Interface Users can view all active RPI orders on the trading interface. Prices and quantities are displayed together with non-RPI orders to reflect the executable market depth.
• API Order Book Using the RPIFilter parameter, users can choose whether to include RPI depth data:
  • Disabled: returns only non-RPI order book
  • Enabled: returns both non-RPI and RPI buy/sell quantities, allowing market makers to manage liquidity more precisely