What causes "Order amount {base_amount} exceeds the configured `max_order_amount` {}" in nautechsystems/nautilus_trader?

Raise `max_order_amount` in the transaction_limits configuration if the size is intended.

Order amount {base_amount} exceeds the configured `max_order

Error message

Order amount {base_amount} exceeds the configured `max_order_amount` {}

What it means

The raw base-token amount of the order is converted with quantity_to_raw_amount and compared against transaction_limits.max_order_amount; orders whose base amount exceeds this configured cap are rejected as a risk guard. The comparison is done in raw integer units (U256) at the token's native precision.

Source

Thrown at crates/adapters/blockchain/src/execution/client.rs:1601

            &quote_token.name,
            CurrencyType::Crypto,
        )?;
        let (token_in, token_out) =
            swap_token_pair(order.order_side(), base_token.address, quote_token.address)?;

        if !self
            .transaction_limits
            .allowed_token_pairs
            .contains(&(token_in, token_out))
        {
            anyhow::bail!(
                "Token pair {token_in} -> {token_out} is not in the `allowed_token_pairs` allowlist"
            );
        }

        let base_amount = quantity_to_raw_amount(order.quantity(), base_token.decimals)?;
        if base_amount > U256::from(self.transaction_limits.max_order_amount) {
            anyhow::bail!(
                "Order amount {base_amount} exceeds the configured `max_order_amount` {}",
                self.transaction_limits.max_order_amount
            );
        }

        let slippage_bps = match cmd
            .params
            .as_ref()
            .and_then(|params| params.get_u64("slippage_bps"))
        {
            Some(value) => u32::try_from(value).map_err(|_| {
                anyhow::anyhow!("slippage_bps parameter {value} exceeds the u32 range")
            })?,
            None => self.transaction_limits.slippage_bps,
        };

        if slippage_bps > self.transaction_limits.max_slippage_bps {
            anyhow::bail!(

View on GitHub (pinned to 18893faf8b)

Solutions

Raise `max_order_amount` in the transaction_limits configuration if the size is intended.
Reduce the strategy's order/position size below the configured cap.
Verify token decimals are configured correctly so the raw-amount comparison is not inflated.

Example fix

// before
transaction_limits.max_order_amount = 10_000; // raw units, too small
// after
transaction_limits.max_order_amount = 10_000_000_000; // sized for token decimals

Defensive patterns

Strategy: validation

Validate before calling

// Rust
let base_amount = quantity_to_raw_amount(order.quantity(), base_token.decimals)?;
if base_amount > U256::from(transaction_limits.max_order_amount) {
    return Err(anyhow::anyhow!("order exceeds max_order_amount"));
}

Prevention

Set max_order_amount consistent with strategy position sizes and token decimals.
Recheck limits after resizing strategies or changing instruments.
Log the configured limits at startup for operators.

When it happens

Trigger: submit_order where quantity_to_raw_amount(order.quantity(), base_token.decimals) > U256::from(transaction_limits.max_order_amount) — i.e. the order size in base token units exceeds the configured maximum.

Common situations: Strategy sized for a CEX (large position sizes) running against a DEX adapter with conservative defaults; max_order_amount left at a low default; decimal mismatch making the raw amount appear larger than intended.

Understand the failure class

Background: "value must be between 0 and 1" / "out of range" / "must not be negative" errors: fixing range-validation failures across open-source libraries — this error's family across 42 libraries.

Related errors

AI-assisted analysis of nautechsystems/nautilus_trader@18893faf8b (2026-09-08). Data as JSON: /api/errors/fbd8c0e34acd4b76. Report an issue: GitHub.