BitMEX

Founded in 2014, BitMEX (Bitcoin Mercantile Exchange) is a cryptocurrency derivatives trading platform offering spot, perpetual contracts, traditional futures, prediction markets, and other advanced trading products. This integration supports live market data ingest and order execution with BitMEX.

Overview

This adapter is implemented in Rust, with optional Python bindings for ease of use in Python-based workflows. It does not require external BitMEX client libraries; the core components are compiled as a static library and linked automatically during the build.

Examples

You can find live example scripts here.

Components

This guide assumes a trader is setting up for both live market data feeds, and trade execution. The BitMEX adapter includes multiple components, which can be used together or separately depending on the use case.

• BitmexHttpClient: Low-level HTTP API connectivity.
• BitmexWebSocketClient: Low-level WebSocket API connectivity.
• BitmexInstrumentProvider: Instrument parsing and loading functionality.
• BitmexDataClient: A market data feed manager.
• BitmexExecutionClient: An account management and trade execution gateway.
• BitmexLiveDataClientFactory: Factory for BitMEX data clients (used by the trading node builder).
• BitmexLiveExecClientFactory: Factory for BitMEX execution clients (used by the trading node builder).

:::note Most users will define a configuration for a live trading node (as below), and won't need to necessarily work with these lower level components directly. :::

BitMEX documentation

BitMEX provides extensive documentation for users:

• BitMEX API Explorer - Interactive API documentation.
• BitMEX API Documentation - Complete API reference.
• BitMEX Exchange Rules - Official exchange rules and regulations.
• Contract Guides - Detailed contract specifications.
• Spot Trading Guide - Spot trading overview.
• Perpetual Contracts Guide - Perpetual swaps explained.
• Futures Contracts Guide - Traditional futures information.

It's recommended you refer to the BitMEX documentation in conjunction with this NautilusTrader integration guide.

Product support

:::note BitMEX has discontinued their options products to focus on their core derivatives and spot offerings. :::

Spot trading

• Direct token/coin trading with immediate settlement.
• Major pairs including XBT/USDT, ETH/USDT, ETH/XBT.
• Additional altcoin pairs (LINK, SOL, UNI, APE, AXS, BMEX against USDT).

Derivatives

• Perpetual contracts: Inverse (e.g., XBTUSD) and linear (e.g., ETHUSDT).
• Traditional futures: Fixed expiration date contracts.
• Quanto futures: Contracts settled in a different currency than the underlying.
• Prediction markets: Event-based derivatives (e.g., P_FTXZ26, P_SBFJAILZ26) allowing traders to speculate on outcomes across crypto, finance, and other events. No leverage, priced 0-100, settled in USDT.
• Stock perpetuals: Equity-based perpetuals (e.g., SPYUSDT, CRCLUSDT). Currently on testnet only; not yet supported by this adapter.

Instrument type codes (CFI)

BitMEX uses CFI (Classification of Financial Instruments) codes following the ISO 10962 standard. The adapter recognizes the following instrument type codes:

See BitMEX Typ Values for more details.

Symbology

BitMEX uses a specific naming convention for its trading symbols. Understanding this convention is crucial for correctly identifying and trading instruments.

Symbol format

BitMEX symbols typically follow these patterns:

• Spot pairs: Base currency + Quote currency (e.g., XBT/USDT, ETH/USDT).
• Perpetual contracts: Base currency + Quote currency (e.g., XBTUSD, ETHUSD).
• Futures contracts: Base currency + Expiry code (e.g., XBTM24, ETHH25).
• Quanto contracts: Special naming for non-USD settled contracts.
• Prediction markets: P_ prefix + Event identifier + Expiry code (e.g., P_POWELLK26, P_FTXZ26).

:::info BitMEX uses XBT as the symbol for Bitcoin instead of BTC. This follows the ISO 4217 currency code standard where "X" denotes non-national currencies. XBT and BTC refer to the same asset - Bitcoin. :::

Expiry codes

Futures contracts use standard futures month codes:

• F = January
• G = February
• H = March
• J = April
• K = May
• M = June
• N = July
• Q = August
• U = September
• V = October
• X = November
• Z = December

Followed by the year (e.g., 24 for 2024, 25 for 2025).

NautilusTrader instrument IDs

Within NautilusTrader, BitMEX instruments are identified using the native BitMEX symbol directly, combined with the venue identifier:

from nautilus_trader.model.identifiers import InstrumentId

# Spot pairs (note: no slash in the symbol)
spot_id = InstrumentId.from_str("XBTUSDT.BITMEX")  # XBT/USDT spot
eth_spot_id = InstrumentId.from_str("ETHUSDT.BITMEX")  # ETH/USDT spot

# Perpetual contracts
perp_id = InstrumentId.from_str("XBTUSD.BITMEX")  # Bitcoin perpetual (inverse)
linear_perp_id = InstrumentId.from_str("ETHUSDT.BITMEX")  # Ethereum perpetual (linear)

# Futures contract (June 2024)
futures_id = InstrumentId.from_str("XBTM24.BITMEX")  # Bitcoin futures expiring June 2024

# Prediction market contracts
prediction_id = InstrumentId.from_str("P_XBTETFV23.BITMEX")  # Bitcoin ETF SEC approval prediction expiring October 2023

:::note BitMEX spot symbols in NautilusTrader don't include the slash (/) that appears in the BitMEX UI. Use XBTUSDT instead of XBT/USDT. :::

Quantity scaling

BitMEX reports spot and derivative quantities in contract units. The actual asset size per contract is exchange-specific and published on the instrument definition:

• lotSize – minimum number of contracts you can trade.
• underlyingToPositionMultiplier – number of contracts per unit of the underlying asset.

For example, the SOL/USDT spot instrument (SOLUSDT) exposes lotSize = 1000 and underlyingToPositionMultiplier = 10000, meaning one contract represents 1 / 10000 = 0.0001 SOL, and the minimum order (lotSize * contract_size) is 0.1 SOL. The adapter now derives the contract size directly from these fields and scales both inbound market data and outbound orders accordingly, so quantities in Nautilus are always expressed in base units (SOL, ETH, etc.).

See the BitMEX API documentation for details on these fields: https://www.bitmex.com/app/apiOverview#Instrument-Properties.

Orders capability

The BitMEX integration supports the following order types and execution features.

Order types

Execution instructions

:::note Post-only orders that would cross the spread are canceled by BitMEX rather than rejected. The integration surfaces these as rejections with due_post_only=True so strategies can handle them consistently. :::

Trigger types

BitMEX supports multiple reference prices to evaluate stop/conditional order triggers for:

• STOP_MARKET
• STOP_LIMIT
• MARKET_IF_TOUCHED
• LIMIT_IF_TOUCHED

Choose the trigger type that matches your strategy and/or risk preferences.

• If no trigger_type is provided, BitMEX uses its venue default (LastPrice).
• These trigger references are exchange-evaluated; the order remains resting at the venue until triggered.

Example:

from nautilus_trader.model.enums import TriggerType

order = self.order_factory.stop_market(
    instrument_id=instrument_id,
    order_side=order_side,
    quantity=qty,
    trigger_price=trigger,
    trigger_type=TriggerType.MARK_PRICE,  # Use BitMEX Mark Price as reference
)

ExecTester example configuration also demonstrates setting stop_trigger_type=TriggerType.MARK_PRICE in examples/live/bitmex/bitmex_exec_tester.py.

Trailing stops

BitMEX supports trailing stop orders that automatically adjust the stop price as the market moves favorably. The adapter maps TRAILING_STOP_MARKET orders to BitMEX's pegged orders with TrailingStopPeg price type.

Limitations:

• Only PRICE trailing offset type is supported (absolute price offset, not basis points or ticks).
• The offset sign is handled automatically: sell stops use negative offset, buy stops use positive.
• Trigger type can be combined with trailing stops for additional control.

Example:

from nautilus_trader.model.enums import TrailingOffsetType

order = self.order_factory.trailing_stop_market(
    instrument_id=instrument_id,
    order_side=OrderSide.SELL,
    quantity=qty,
    trailing_offset=Decimal("100"),  # $100 trailing offset
    trailing_offset_type=TrailingOffsetType.PRICE,
    trigger_type=TriggerType.LAST_PRICE,  # Optional
)

:::note BitMEX updates trailing stop prices periodically as the market moves. The stop price freezes when the market moves toward the trigger level. See the BitMEX API documentation for current update cadence details. :::

Pegged orders

BitMEX supports pegged orders (BBO) that automatically track a reference price. The adapter supports pegged orders via the params dict on submit_order, which overrides the order type to Pegged on the exchange side.

Requirements:

• The underlying order must be a LIMIT order. Other order types are rejected.
• peg_price_type is required; peg_offset_value is optional (defaults to 0).
• peg_offset_value can be negative (e.g., sell-side offsets) or fractional.

Example:

# Pegged to best bid with zero offset (BBO)
order = self.order_factory.limit(
    instrument_id=instrument_id,
    order_side=OrderSide.BUY,
    quantity=qty,
    price=price,  # Required for LIMIT order, but overridden by peg
)
self.submit_order(order, params={"peg_price_type": "PrimaryPeg", "peg_offset_value": "0"})

# Pegged to mid-price with a -0.5 offset
self.submit_order(order, params={"peg_price_type": "MidPricePeg", "peg_offset_value": "-0.5"})

:::note The price field is still required when constructing the LimitOrder, but BitMEX ignores it for pegged orders and instead continuously tracks the reference price plus offset. :::

Time in force

:::note DAY orders expire at 12:00am UTC, which marks the BitMEX trading day boundary (end of trading hours for that day). See the BitMEX Exchange Rules and API documentation for complete details. :::

Advanced order features

Batch operations

Position management

Order querying

Liquidation and ADL handling

BitMEX surfaces forced-close fills through the execType field on the execution channel:

The adapter routes Liquidation and Bankruptcy through the standard FillReport path and logs a warning on bankruptcy executions. BitMEX's public API does not distinguish auto-deleveraging from counterparty liquidation in execType; both appear as Liquidation. An ADL-closed position can usually be identified by zero commission and the absence of a matching order in the local cache (the engine creates an external order for it).

Upstream references:

• /execution field definitions
• Auto-Deleveraging overview
• Liquidation overview

Market data

• Order book deltas: L2_MBP only; depth 0 (full book) or 25.
• Order book depth10 snapshots: fixed 10 levels via orderBook10 channel.
• Quotes, trades, and instrument updates are supported via WebSocket.
• Funding rates, mark prices, and index prices are supported where applicable.
• Historical requests via REST:
  • Trade ticks with optional start, end, and limit filters (up to 1,000 results per call).
  • Time bars (1m, 5m, 1h, 1d) for externally aggregated LAST prices, including optional partial bins.

:::note BitMEX caps each REST response at 1,000 rows and requires manual pagination via start/startTime. The current adapter returns only the first page; wider pagination support is scheduled for a future update. :::

Trade ID derivation

Trade ticks and fills use the venue-provided trdMatchID (UUID) as the TradeId. When the venue omits trdMatchID (bucketed trades or certain execution types), the execution path falls back to the venue's execID; market data parsers fall back to a deterministic FNV-1a hash of the symbol, ts_event, price, size, and side. The same venue event yields the same trade ID across replays, keeping downstream dedup intact.

Connection management

HTTP Keep-Alive

The BitMEX adapter uses HTTP keep-alive for optimal performance:

• Connection pooling: Connections are automatically pooled and reused.
• Keep-alive timeout: 90 seconds (matches BitMEX server-side timeout).
• Automatic reconnection: Failed connections are automatically re-established.
• SSL session caching: Reduces handshake overhead for subsequent requests.

This configuration ensures low-latency communication with BitMEX servers by maintaining persistent connections and avoiding the overhead of establishing new connections for each request.

Request authentication and expiration

BitMEX uses an api-expires header for request authentication to prevent replay attacks:

• Signed requests include an api-expires Unix timestamp set recv_window_ms / 1000 seconds ahead (10 seconds by default).
• BitMEX rejects any request once that timestamp has passed, so keep latency within your configured window.

Funding rates

The adapter receives funding rate data from the Funding WebSocket stream. BitMEX returns a fundingInterval datetime field in each message, and the adapter reads the hours and minutes to compute the interval field on FundingRateUpdate.

Rate limiting

BitMEX implements a dual-layer rate limiting system:

REST limits

• Burst limit: 10 requests per second for authenticated users (applies to order placement, modification, and cancel endpoints).
• Rolling minute limit: 120 requests per minute for authenticated users (30 requests per minute for unauthenticated users).
• Order caps: 200 open orders and 10 stop orders per symbol; exceeding these caps triggers exchange-side rejections.

The adapter enforces these quotas locally using the configured max_requests_per_second and max_requests_per_minute values.

WebSocket limits

• Connection requests: follow the exchange guidance (currently 3 connections per second per IP).
• Private streams require authentication; the adapter reconnects automatically if a limit is exceeded.

:::warning Exceeding BitMEX rate limits returns HTTP 429 and may trigger temporary IP bans; persistent 4xx/5xx errors can extend the lockout period. :::

Configurable rate limits

The rate limits can be configured if your account has different limits than the defaults:

:::info For more details on rate limiting, see the BitMEX API documentation on rate limits. :::

:::warning Cancel Broadcaster Rate Limit Considerations

The cancel broadcaster (when canceller_pool_size > 1) fans out each cancel request to multiple independent HTTP clients in parallel. Each client maintains its own rate limiter, which means the effective request rate is multiplied by the pool size.

Example: With canceller_pool_size=3 and max_requests_per_second=10, a single cancel operation consumes 3 requests (one per client), potentially reaching 30 requests/second if canceling rapidly.

Since BitMEX enforces rate limits at the account level (not per connection), the broadcaster can push you over the exchange's default limits of 10 req/s burst and 120 req/min rolling window.

Mitigations: Reduce max_requests_per_second and max_requests_per_minute proportionally (divide by canceller_pool_size), or adjust the pool size itself (see Cancel broadcaster configuration). Future versions may support shared rate limiters across the pool. :::

Rate-limit headers

BitMEX exposes the current allowance via response headers:

• x-ratelimit-limit: total requests permitted in the current window.
• x-ratelimit-remaining: remaining requests before throttling occurs.
• x-ratelimit-reset: UNIX timestamp when the allowance resets.
• retry-after: seconds to wait after a 429 response.

Submit broadcaster

The BitMEX execution client includes a submit broadcaster that provides higher assurance of market and limit orders being accepted at target prices through parallel request fanout, trading lower minimum latency for the risk of duplicate submissions.

Concepts

Order submissions are time-critical operations - when a strategy decides to enter a position, any delay can result in missed opportunities or adverse pricing. The submit broadcaster addresses this by:

• Parallel fanout: Submit requests are simultaneously broadcast to multiple independent HTTP client instances.
• First-success short-circuiting: The first successful response wins, minimizing latency to acceptance.
• Shared client_order_id: All transports use the same client_order_id. BitMEX rejects duplicate submissions with "duplicate clOrdID" (tracked as expected rejections).
• Latency vs. duplicates tradeoff: Accepts the risk of potential duplicate fills (if multiple transports succeed before rejection) in exchange for lower minimum latency and higher assurance of acceptance.

This architecture reduces the minimum latency to order acceptance by parallelizing across multiple network paths.

Usage

The submit broadcaster is opt-in and controlled via the submit_tries parameter when submitting orders. By default, orders are submitted through a single HTTP client. To enable broadcasting:

# Single submission (default behavior)
self.submit_order(order)

# Broadcast to 2 parallel HTTP clients for redundancy
self.submit_order(order, params={"submit_tries": 2})

# Broadcast to 3 parallel HTTP clients (maximum recommended)
self.submit_order(order, params={"submit_tries": 3})

Key points:

• submit_tries must be a positive integer.
• Broadcasting only occurs when submit_tries > 1. Default submits go through a single HTTP client.
• If submit_tries exceeds submitter_pool_size, it will be capped at the pool size with a warning.
• All transports use the same client_order_id; BitMEX rejects duplicates as expected rejections.

Health monitoring

Each HTTP client in the broadcaster pool maintains health metrics:

• Successful submissions mark a client as healthy.
• Failed requests increment error counters.
• Background health checks periodically verify client connectivity.
• Degraded clients are tracked but remain in the pool to maintain fault tolerance.

The broadcaster exposes metrics including total submits, successful submits, failed submits, and expected rejects for operational monitoring and debugging.

Tracked metrics

These metrics can be accessed programmatically via the get_metrics() method on the SubmitBroadcaster instance.

Configuration

The submit broadcaster is configured via the execution client configuration:

Example configuration:

from nautilus_trader.adapters.bitmex.config import BitmexExecClientConfig

exec_config = BitmexExecClientConfig(
    api_key="YOUR_API_KEY",
    api_secret="YOUR_API_SECRET",
    submitter_pool_size=3,  # Recommended pool size for redundancy
)

:::tip For HFT strategies without higher rate limits, consider the advantages of using the submit broadcaster against potentially hitting rate limits, as each client has an independent rate limit budget. The default submitter_pool_size=None disables the broadcaster. The recommended setting of submitter_pool_size=3 broadcasts each submit request to 3 parallel HTTP clients for fault tolerance, which consumes 3× the rate limit quota per submit operation but provides higher assurance against network or exchange issues. :::

The broadcaster is automatically started when the execution client connects and stopped when it disconnects. Submit operations are routed through the broadcaster only when submit_tries > 1; default submits use a single HTTP client directly.

Cancel broadcaster

The BitMEX execution client includes a cancel broadcaster that provides fault-tolerant order cancellation through parallel request fanout.

Concepts

Order cancellations are time-critical operations - when a strategy decides to cancel an order, any delay or failure can result in unintended fills, slippage, or unwanted position exposure. The cancel broadcaster addresses this by:

• Parallel fanout: Cancel requests are simultaneously broadcast to multiple independent HTTP client instances.
• First-success short-circuiting: The first successful response wins, and remaining in-flight requests are immediately aborted.
• Fault tolerance: If one HTTP client experiences network issues, DNS failures, or connection timeouts, other clients in the pool continue processing.
• Idempotent success handling: Responses indicating the order was already canceled (such as "orderID not found" or similar idempotent states) are treated as success rather than failure, preventing unnecessary error propagation.

This architecture ensures that a single network path failure or slow connection doesn't block cancel operations, improving the reliability of risk management and position control in live trading.

Health monitoring

Each HTTP client in the broadcaster pool maintains health metrics:

• Successful cancellations mark a client as healthy.
• Failed requests increment error counters.
• Background health checks periodically verify client connectivity.
• Degraded clients are tracked but remain in the pool to maintain fault tolerance.

The broadcaster exposes metrics including total cancels, successful cancels, failed cancels, expected rejects (already canceled orders), and idempotent successes for operational monitoring and debugging.

Tracked metrics

These metrics can be accessed programmatically via the get_metrics() method on the CancelBroadcaster instance.

Configuration

The cancel broadcaster is configured via the execution client configuration:

Example configuration:

from nautilus_trader.adapters.bitmex.config import BitmexExecClientConfig

exec_config = BitmexExecClientConfig(
    api_key="YOUR_API_KEY",
    api_secret="YOUR_API_SECRET",
    canceller_pool_size=3,  # Recommended pool size for redundancy
)

:::tip For HFT strategies without higher rate limits, consider the advantages of using the cancel broadcaster against potentially hitting rate limits, as each client has an independent rate limit budget. The default canceller_pool_size=None disables the broadcaster. The recommended setting of canceller_pool_size=3 broadcasts each cancel request to 3 parallel HTTP clients for fault tolerance, which consumes 3× the rate limit quota per cancel operation but provides higher assurance against network or exchange issues. :::

The broadcaster is automatically started when the execution client connects and stopped when it disconnects. All cancel operations (cancel_order, cancel_all_orders, batch_cancel_orders) are automatically routed through the broadcaster without requiring any changes to strategy code.

Dead man's switch

The adapter supports BitMEX's dead man's switch (cancelAllAfter), which provides automatic order cancellation as a safety net against connectivity failures.

How it works

When enabled, a server-side timer is set on BitMEX. If the timer expires without being refreshed, BitMEX cancels all open orders on the account. The adapter keeps the timer alive by sending periodic heartbeat requests. If the adapter loses connectivity (network failure, process crash, etc.), the heartbeats stop and BitMEX cancels the orders after the configured timeout.

The flow:

1. On connect, the adapter calls POST /api/v1/order/cancelAllAfter with the configured timeout (in milliseconds) to arm the server-side timer.
2. A background task sends the same request at a refresh interval of timeout / 4 (minimum 1 second) to keep resetting the timer before it expires.
3. On disconnect, the adapter waits for the background heartbeat task to fully shut down, then calls cancelAllAfter with timeout=0 to disarm the server-side timer.

For example, with a 60-second timeout the adapter sends a heartbeat every 15 seconds. If four consecutive heartbeats fail (60 seconds of lost connectivity), BitMEX cancels all open orders.

Disconnect ordering

Disarming the dead man's switch during disconnect requires careful ordering. The disarm request (timeout=0) should be the last cancelAllAfter call to reach BitMEX. If an in-flight heartbeat were processed after the disarm, it would re-arm the server-side timer and orders could be unexpectedly cancelled after the timeout expires, even though the adapter disconnected gracefully.

The adapter mitigates this in both implementations:

• Rust: The heartbeat task is immediately stopped (abort + await) so disconnect does not stall waiting for a sleep or HTTP timeout to elapse. The disarm request is then sent after the task has exited.
• Python: The heartbeat task is cancelled and awaited, ensuring the coroutine fully unwinds before the disarm request is sent.

In a force-stop scenario (e.g., process shutdown via stop()), the heartbeat task is aborted without disarming. This is intentional, as the server-side timer provides the desired safety behavior when the process exits unexpectedly.

:::note Each heartbeat consumes one REST rate limit token. A 60-second timeout uses approximately 4 requests per minute from the 120/min budget. :::

Configuration

Enable the dead man's switch by setting deadmans_switch_timeout_secs on the execution client config:

from nautilus_trader.adapters.bitmex.config import BitmexExecClientConfig

exec_config = BitmexExecClientConfig(
    api_key="YOUR_API_KEY",
    api_secret="YOUR_API_SECRET",
    deadmans_switch_timeout_secs=60,  # Cancel all orders after 60s of lost connectivity
)

When enabled, the adapter logs:

Starting dead man's switch: timeout=60s, refresh_interval=15s

on connect, and:

Disarming dead man's switch

on disconnect.

:::tip A timeout of 60 seconds is the recommended starting point. Shorter timeouts provide faster protection but are more sensitive to transient network blips. Longer timeouts are more tolerant of brief outages but leave orders exposed longer during a real failure. :::

:::warning The dead man's switch applies to all open orders on the account, not just orders placed by the adapter. If other systems place orders on the same account, enabling the dead man's switch will affect those orders too. :::

Configuration

API credentials

BitMEX API credentials can be provided either directly in the configuration or via environment variables:

• BITMEX_API_KEY: Your BitMEX API key for production.
• BITMEX_API_SECRET: Your BitMEX API secret for production.
• BITMEX_TESTNET_API_KEY: Your BitMEX API key for testnet (when testnet=True).
• BITMEX_TESTNET_API_SECRET: Your BitMEX API secret for testnet (when testnet=True).

To generate API keys:

1. Log in to your BitMEX account.
2. Navigate to Account & Security → API Keys.
3. Create a new API key with appropriate permissions.
4. For testnet, use testnet.bitmex.com.

:::note Testnet API endpoints:

• REST API: https://testnet.bitmex.com/api/v1
• WebSocket: wss://ws.testnet.bitmex.com/realtime

The adapter automatically routes requests to the correct endpoints when testnet=True is configured. :::

Data client configuration options

The BitMEX data client provides the following configuration options:

Execution client configuration options

The BitMEX execution client provides the following configuration options:

Configuration examples

A typical BitMEX configuration for live trading includes both testnet and mainnet options:

from nautilus_trader.adapters.bitmex.config import BitmexDataClientConfig
from nautilus_trader.adapters.bitmex.config import BitmexExecClientConfig

# Using environment variables (recommended)
testnet_data_config = BitmexDataClientConfig(
    testnet=True,  # API credentials loaded from BITMEX_TESTNET_API_KEY and BITMEX_TESTNET_API_SECRET
)

# Using explicit credentials
mainnet_data_config = BitmexDataClientConfig(
    api_key="YOUR_API_KEY",  # Or use os.getenv("BITMEX_API_KEY")
    api_secret="YOUR_API_SECRET",  # Or use os.getenv("BITMEX_API_SECRET")
    testnet=False,
)

mainnet_exec_config = BitmexExecClientConfig(
    api_key="YOUR_API_KEY",
    api_secret="YOUR_API_SECRET",
    testnet=False,
)

Trading considerations

Contingent orders

The BitMEX execution adapter now maps Nautilus contingent order lists to the exchange's native clOrdLinkID/contingencyType mechanics. When the engine submits ContingencyType::Oco or ContingencyType::Oto orders the adapter will:

• Create/maintain the linked order group on BitMEX so child stops and targets inherit the parent order status.
• Propagate order list updates and cancellations so that contingent peers stay aligned with the current position state.
• Surface execution reports with the appropriate contingency metadata, enabling strategy-level tracking without additional manual wiring.

This means common bracket flows (entry + stop + take-profit) and multi-leg stop structures can now be managed directly by BitMEX instead of being emulated client-side. When defining strategies, continue to use Nautilus OrderList/ContingencyType abstractions. The adapter handles the required BitMEX wiring automatically.

Contract specifications

• Inverse contracts: Settled in cryptocurrency (e.g., XBTUSD settled in XBT).
• Linear contracts: Settled in stablecoin (e.g., ETHUSDT settled in USDT).
• Contract size: Varies by instrument, check specifications carefully.
• Tick size: Minimum price increment varies by contract.

Margin requirements

• Initial margin requirements vary by contract and market conditions.
• Maintenance margin is typically lower than initial margin.
• Liquidation occurs when maintenance margin requirement is not satisfied.
• BitMEX supports both isolated margin and cross margin modes.
• Risk limits can be adjusted based on position size per the Exchange Rules.

Fees

• Maker fees: Typically negative (rebate) for providing liquidity.
• Taker fees: Positive fee for taking liquidity.
• Funding rates: Apply to perpetual contracts every 8 hours.
• Prediction market fees: Maker 0.00%, Taker 0.25% (no leverage allowed).

Contributing

:::info For additional features or to contribute to the BitMEX adapter, please see our contributing guide. :::