AX Exchange

AX Exchange is a centralized and regulated derivatives exchange for traditional underlying asset classes. Operated by Architect Bermuda Ltd. and licensed by the Bermuda Monetary Authority (BMA), AX lists perpetual contracts in production and also exposes dated futures in its sandbox catalog.

This integration supports live market data ingest and order execution with AX Exchange.

Overview

This adapter is implemented in Rust and exposed to Python through PyO3 bindings. It does not require external AX client libraries.

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

• AxHttpClient: Low-level HTTP API connectivity.
• AxMdWebSocketClient: Market data WebSocket connectivity.
• AxOrdersWebSocketClient: Orders WebSocket connectivity.
• AxDataClient: A market data feed manager.
• AxExecutionClient: An account management and trade execution gateway.
• AxDataClientFactory: Factory for AX data clients.
• AxExecutionClientFactory: Factory for AX execution clients.

Examples

• Python examples
• Rust examples

AX Exchange documentation

AX Exchange provides documentation for users at the Architect documentation site. Refer to the AX Exchange documentation in conjunction with this NautilusTrader integration guide.

Products

The production catalog contains perpetual contracts across these venue categories:

The sandbox also lists dated gold contracts such as XAU-2026-SEP and XAU-2026-DEC.

The adapter maps a crypto venue category to the CRYPTOCURRENCY asset class, and any category it does not recognize to ALTERNATIVE.

Perpetual contracts

A perpetual contract (perpetual swap) is a derivative that tracks the price of an underlying asset without expiring. Unlike standard futures, there is no settlement date, which eliminates rollover costs and simplifies position management. A funding rate mechanism keeps the contract price aligned with the underlying index price through periodic payments between long and short holders. See the Architect documentation for details on funding rate mechanics and contract specifications.

Characteristics of AX perpetual contracts:

• Cash-settled in USD: No physical delivery. All profit and loss is settled in USD.
• Funding rates: Periodic payments keep the contract price aligned with the underlying.
• Multiplier of 1: Each contract represents one unit of exposure to the underlying.
• Whole contracts only: Fractional quantities are not supported.
• Margin: Initial margin is required to open a position; maintenance margin to keep it open.

The adapter represents an AX instrument without an expiration as PerpetualContract and an instrument with an expiration as FuturesContract. The venue category determines the Nautilus asset class. The adapter uses MARGIN account type and NETTING order management.

Symbology

The adapter preserves each AX symbol and appends the Nautilus venue identifier .AX. Perpetual symbols use the -PERP suffix. Dated symbols include their year and contract month.

The venue identifier is AX. To construct a Nautilus InstrumentId:

from nautilus_trader.model import InstrumentId

instrument_id = InstrumentId.from_str("EURUSD-PERP.AX")

Environments

AX Exchange provides two trading environments. Configure the appropriate environment using the environment parameter in your client configuration.

Sandbox

The default environment for development and testing with simulated funds. All sandbox endpoints are resolved automatically when environment=AxEnvironment.SANDBOX.

export AX_API_KEY="your-sandbox-api-key"
export AX_API_SECRET="your-sandbox-api-secret"

Production

For live trading with real funds. Requires a verified AX Exchange account.

config = AxExecClientConfig(
    environment=AxEnvironment.PRODUCTION,
)

Market data

The adapter provides real-time market data via WebSocket subscriptions, with HTTP endpoints for historical data backfill.

Data types

AX instrument states map to MarketStatusAction as follows:

WebSocket subscription behavior

AX market data WebSocket subscriptions use one active stream per symbol. The adapter selects the smallest stream that covers the active Nautilus subscriptions:

• A trades-only subscription uses AX level: "TRADES", which delivers trade prints only.
• Book-only and quote-only subscriptions set AX trades: false and ticker: false to suppress unrequested trade and ticker events.
• Mark price and instrument status subscriptions require AX ticker events, so the adapter enables ticker delivery on the active book stream, opening an L1 stream when no book subscription exists.
• Book deltas subscribe at the AX level matching the Nautilus book type. L1_MBP has no delta-capable AX equivalent, so the adapter logs a warning and subscribes at L2 instead.
• If multiple Nautilus data types are active for a symbol, the adapter resubscribes only when the required AX level or delivery flags change.

AX documents estimated funding rates on ticker events and an estimated-funding request on the orders WebSocket. Nautilus exposes settled funding-rate updates through HTTP polling; the adapter does not parse or emit the venue's estimated funding fields as a separate Nautilus data type.

HTTP API behavior

• GET /tickers returns limit/offset page metadata and supports limit, offset, and sort query parameters.
• GET /ticker returns the ticker under a top-level ticker response field.
• GET /open-orders uses limit/offset pagination. Open-order reconciliation traverses all pages and validates totals, offsets, duplicates, and completeness so detected response drift fails the request.
• GET /fills and GET /funding-rates use cursor pagination. The adapter traverses each cursor chain as a best-effort historical read; AX corrections during traversal are not an atomic snapshot.
• GET /orders exposes cursor metadata and supports order_id, order_ids, account_id, and optional timestamp filters. Startup mass-status reconciliation traverses its cursor chain, accepts partial pages, and rejects repeated cursors or duplicate order IDs.
• Open-order, historical-order, fill, and position report requests resolve an uncached symbol through GET /instrument and cache the result. An instrument request or parse failure fails that entire report request instead of dropping venue state.
• GET /transactions requires start_timestamp_ns and end_timestamp_ns with a range no wider than 7 days. The low-level client exposes its cursor and account selectors.
• GET /order-status can include reject_reason and reject_message for rejected orders.
• When an account selector is omitted, AX uses the primary account. The high-level execution client owns one primary account; low-level request models expose documented account selectors.

Bar intervals

Orders capability

The AX order-entry API has no order-type selector. Its single native order shape requires a price, which the adapter maps to a Nautilus LIMIT order. The adapter simulates a Nautilus MARKET order by previewing an aggressive price and submitting that priced shape with IOC.

The official REST place-order and orders WebSocket request schemas contain no order_type or trigger_price field, and sandbox stop-limit submissions with unbreached triggers executed immediately at the active limit price. With conditional execution unconfirmed, the adapter rejects venue-native stop-limit orders before sending them.

Nautilus can still emulate a stop-limit order locally. The common order emulator waits for the configured trigger, then sends a plain limit order to this adapter.

Order types

Execution instructions

The reduce-only boundary matters because AX has no reduce-only field. In sandbox, an order whose reduce-only instruction was dropped from the wire payload was accepted and filled as an ordinary order, which can open or increase exposure instead of closing it; production behavior was not verified. The adapter therefore denies reduce-only orders before submission rather than sending an instruction the venue cannot honor.

The adapter also rejects quote-quantity and display-quantity instructions because its AX wire path cannot encode those semantics. This is an adapter boundary, not a claim that AX Exchange rejects equivalent venue-native features.

Time in force

The venue deprecates DAY and recommends GTC instead.

Advanced order features

Position management

Order querying

Authentication

AX Exchange uses bearer token authentication:

1. API key and secret obtain a session token via /authenticate.
2. The session token is used as a bearer token for subsequent REST and WebSocket requests.
3. The adapter requests one-hour session tokens and refreshes them every 30 minutes.
4. A refresh updates REST authentication and the token used by the next WebSocket reconnect without interrupting the active connection.

Configuration

Environments and endpoints

Data client configuration options

Execution client configuration options

When transport_backend=None, the compiled Rust default selects Sockudo when the transport-sockudo Cargo feature is enabled and Tungstenite otherwise.

Use AxDataClientConfig with AxDataClientFactory and AxExecClientConfig with AxExecutionClientFactory. The Python examples show the complete LiveNode.builder(...) configuration for data and execution clients.

API credentials

There are two options for supplying your credentials to the AX Exchange clients. Either pass the corresponding api_key and api_secret values to the configuration objects, or set the following environment variables:

• AX_API_KEY
• AX_API_SECRET

When starting the trading node, you'll receive immediate confirmation of whether your credentials are valid and have trading permissions.

Implementation notes

• Whole contracts only: AX uses integer contract quantities. The adapter models a one-contract size increment and lot size, while enforcing each instrument's separate minimum_order_size. Fractional quantities generate OrderDenied locally.
• Dated futures activation: AX publishes expiration but not activation timestamps. The adapter uses zero for the unknown activation time and preserves that limitation in instrument metadata.
• Rate limiting: The adapter applies a conservative rate limit of 10 requests/second with automatic exponential backoff on rate limit responses.
• Market orders: AX does not support native market orders. The adapter uses a preview endpoint to determine the take-through price and submits an aggressive IOC limit order. Because the book can move between the preview and the submission, a simulated market order may fill partially.
• Stop-limit orders: The adapter rejects venue-native stop-limit submissions because sandbox testing did not confirm conditional semantics. Use local order emulation when a strategy requires a stop-limit order.
• Order modification: AX supports atomic order replacement via POST /replace-order. The execution client maps modify_order to this endpoint and records the new venue order ID it returns. A modification is rejected locally when it carries a trigger price, which AX has no field for, or when the order has no venue order ID yet.
• Funding rate polling: The data client polls GET /funding-rates per subscribed instrument on funding_rate_poll_interval_mins, requesting a seven-day lookback so a rate is still found across weekends and holidays, and emits the latest rate only when it differs from the last one emitted.
• Cancel on disconnect: Set cancel_on_disconnect=True in the execution client config to have the exchange cancel all open orders if the orders WebSocket disconnects.
• Instrument fee rates: AX reports maker and taker rates per account on GET /whoami, so the adapter resolves them after authenticating and applies them to every instrument. A client with credentials fails to connect if that lookup fails, rather than reporting zero fees for the process lifetime. A data client configured without credentials cannot read the rates and reports zero fees.
• Fill commissions: Real-time fill events from the WebSocket do not include fee data. Commission is reported as zero for streaming fills. During reconciliation, the REST /fills endpoint provides accurate fee information.
• Fill reconciliation window: The /fills endpoint requires a bounded time range and caps the span at seven days. Reconciliation requests the most recent seven days of fills; fills older than that are not reconciled.
• Fill order identity: AX can omit order_id for block trades and final settlement fills. The adapter derives a deterministic reconciliation order ID from trade_id for those classified records. Classification fields are optional for regular fills with a valid order_id. The adapter rejects rows with neither an order ID nor explicit special-fill classification, and rejects inconsistent classification.
• Unfilled IOC/FOK: AX reports an unfilled immediate order as an expiry; the adapter maps it to OrderCanceled to match NautilusTrader semantics.

Contributing