nautechsystems/nautilus_trader · error · anyhow::Error

`slippage_bps` {slippage_bps} exceeds `max_slippage_bps` {ma

Error message

`slippage_bps` {slippage_bps} exceeds `max_slippage_bps` {max_slippage_bps}

What it means

Config validation enforces slippage ordering: the default `slippage_bps` applied to derive a swap's minimum output must not exceed `max_slippage_bps`, the ceiling accepted for per-order overrides. Values are in basis points, and the very next check requires max_slippage_bps to stay below 10_000 (BPS_DENOMINATOR, i.e. 100%).

Source

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

            config.max_quote_age_blocks,
            config.receipt_timeout_secs,
        )
        else {
            anyhow::bail!(
                "Blockchain execution transaction limits are required: allowed_token_pairs, slippage_bps, max_slippage_bps, max_order_amount, deadline_seconds, max_quote_age_blocks, receipt_timeout_secs"
            );
        };

        let mut parsed_pairs = HashSet::with_capacity(allowed_token_pairs.len());
        for (token_in, token_out) in allowed_token_pairs {
            parsed_pairs.insert((
                validate_address(token_in.as_str())?,
                validate_address(token_out.as_str())?,
            ));
        }

        if slippage_bps > max_slippage_bps {
            anyhow::bail!(
                "`slippage_bps` {slippage_bps} exceeds `max_slippage_bps` {max_slippage_bps}"
            );
        }

        if max_slippage_bps >= BPS_DENOMINATOR {
            anyhow::bail!("`max_slippage_bps` {max_slippage_bps} must be below {BPS_DENOMINATOR}");
        }

        Ok(TransactionLimits {
            allowed_token_pairs: parsed_pairs,
            slippage_bps,
            max_slippage_bps,
            max_order_amount,
            deadline_seconds,
            max_quote_age_blocks,
            receipt_timeout_secs,
        })
    }

View on GitHub (pinned to 2114cf6f76)

Solutions

1. Reorder the values so slippage_bps <= max_slippage_bps.
2. Keep both below 10_000 basis points (100%).
3. Treat max_slippage_bps as a risk ceiling set by policy, with slippage_bps a tunable default under it.
4. Add a config round-trip test that constructs the client in CI to catch bad values before deploy.

Example fix

// before
slippage_bps: Some(200),
max_slippage_bps: Some(100), // bails: 200 exceeds 100

// after
slippage_bps: Some(50),      // default applied to swaps
max_slippage_bps: Some(300), // ceiling for per-order overrides (< 10_000)

fn slippage_ok(slippage_bps: u32, max_slippage_bps: u32) -> bool {
    slippage_bps <= max_slippage_bps && max_slippage_bps < 10_000
}
// assert at config load

Fail deployment with the two values from the message compared side by side; retrying is pointless until the config file changes.

When it happens

Trigger: Constructing the client with slippage_bps greater than max_slippage_bps — e.g. slippage_bps=200 with max_slippage_bps=100 — typically from swapped values or independent edits that drift apart.

Common situations: Copying slippage numbers between the two fields in the wrong order; raising the default slippage without updating the ceiling; config templates where the ceiling was filled with a placeholder smaller than the default.

Understand the failure class

Background: Config validation failed: what "invalid value for {key}" and settings-rejection errors mean across 19 open-source libraries — this error's family across 19 libraries.

Related errors

• height must be positive, was {self.height}
• Blockchain execution transaction limits are required: allowe
• pandas is required for report generation; install it with `p
• pandas is required for visualization; install it with `pip i
• {name} must not be None

AI-assisted analysis of nautechsystems/nautilus_trader@2114cf6f76 (2026-08-21). Data as JSON: /api/errors/91ba972e2a0c1bd9. Report an issue: GitHub.