nautechsystems/nautilus_trader · error

Slippage {slippage_bps} bps exceeds the configured `max_slip

Error message

Slippage {slippage_bps} bps exceeds the configured `max_slippage_bps` {}

What it means

The effective slippage for the swap (from the command's slippage_bps parameter, or the configured default) is compared against transaction_limits.max_slippage_bps; exceeding it aborts the swap as a risk guard. slippage_bps may come from cmd parameters or fall back to transaction_limits.slippage_bps.

Source

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

            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!(
                "Slippage {slippage_bps} bps exceeds the configured `max_slippage_bps` {}",
                self.transaction_limits.max_slippage_bps
            );
        }

        let quote_spend_ceiling = if order.order_side() == OrderSide::Buy {
            let ceiling = self
                .transaction_limits
                .quote_spend_limits
                .get(&(token_in, token_out))
                .ok_or_else(|| {
                    anyhow::anyhow!(
                        "No `quote_spend_limits` entry for BUY token pair {token_in} -> {token_out}"
                    )
                })?;
            anyhow::ensure!(
                ceiling.spend_token == quote_token.address,
                "Quote spend limit for {token_in} -> {token_out} is denominated in {}, expected quote token {}",

View on GitHub (pinned to 18893faf8b)

Solutions

  1. Lower the order's slippage_bps parameter to at or below transaction_limits.max_slippage_bps.
  2. Raise `max_slippage_bps` in transaction_limits if the requested tolerance is acceptable.
  3. Reduce the configured default transaction_limits.slippage_bps below the cap.

Example fix

// before
cmd.slippage_bps = Some(500); // 5%, cap is 100 bps
client.submit_order(cmd, &order)?;
// after
cmd.slippage_bps = Some(100); // within max_slippage_bps
client.submit_order(cmd, &order)?;
Defensive patterns

Strategy: validation

Validate before calling

// Rust
let eff_bps = cmd.slippage_bps.unwrap_or(transaction_limits.slippage_bps);
if eff_bps > transaction_limits.max_slippage_bps {
    return Err(anyhow::anyhow!("slippage {} bps exceeds cap", eff_bps));
}

Prevention

When it happens

Trigger: submit_order where the per-order slippage_bps parameter (or the configured default slippage_bps) is greater than transaction_limits.max_slippage_bps — e.g. passing slippage_bps=500 with a 100 bps cap.

Common situations: Strategy requests wide slippage tolerance for volatile pools while the risk config caps it; copying example configs with a higher default than the cap; volatile market periods prompting the operator to widen slippage ad hoc past the cap.

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/20802885bc70acde. Report an issue: GitHub.