nautechsystems/nautilus_trader · error · anyhow::Error

Impact cannot exceed 100% (10000 bps)

Error message

Impact cannot exceed 100% (10000 bps)

What it means

`binary_search_for_size` caps the requested price impact at 10000 basis points (100%). An impact above 100% is rejected because it is unrepresentable for the search (impact cannot exceed the full range in this model), so the library fails fast with this message.

Source

Thrown at crates/model/src/defi/pool_analysis/size_estimator.rs:214

        .as_ref()
        .ok_or_else(|| anyhow::anyhow!("Trade info not initialized"))?;

    trade_info.get_slippage_bps()
}

fn binary_search_for_size(
    profiler: &PoolProfiler,
    impact_bps: u32,
    zero_for_one: bool,
    config: &EstimationConfig,
) -> anyhow::Result<BinarySearchState> {
    // Validate inputs
    if impact_bps == 0 {
        anyhow::bail!("Impact must be greater than zero");
    }

    if impact_bps > 10000 {
        anyhow::bail!("Impact cannot exceed 100% (10000 bps)");
    }
    profiler.check_if_initialized(PoolEventKind::Swap)?;

    // Estimate initial bounds
    let mut low = U256::ZERO;
    let mut high = estimate_max_size_for_impact(profiler, impact_bps, zero_for_one);
    let initial_high = high;

    let mut iterations = 0;
    let mut expansions = 0;
    let mut converged = false;
    let mut final_slippage_bps = None;

    // Binary search with optional adaptive expansion
    while iterations < config.max_iterations {
        iterations += 1;

        // Calculate midpoint

View on GitHub (pinned to 18893faf8b)

Solutions

1. Clamp or validate `impact_bps` to at most 10000 before calling the estimator.
2. Convert user-facing percentages correctly: percent * 100 = bps, and reject >100% at input.
3. Normalize the impact scale at the config boundary so all callers pass bps.
4. Return a graceful 'impact too large' signal to users instead of letting the API error propagate.

Example fix

// before
let impact_bps = 150; // meant 150%
let size = size_for_impact_bps(&profiler, impact_bps, true, &config)?;
// after
let impact_bps = 15000.min(10_000); // cap at 100% (10000 bps)
let size = size_for_impact_bps(&profiler, impact_bps, true, &config)?;

fn valid_impact(impact_bps: u32) -> bool {
    (1..=10000).contains(&impact_bps)
}
let impact_bps = impact_bps.min(10_000);

let size = match size_for_impact_bps(&profiler, impact_bps, zero_for_one, &config) {
    Ok(s) => s,
    Err(e) if e.to_string().contains("cannot exceed 100%") => {
        // clamp to 10000 bps and retry, or surface a user-facing input error
    },
    Err(e) => return Err(e),
};

When it happens

Trigger: Calling `size_for_impact_bps` or `size_for_impact_bps_detailed` with `impact_bps > 10000`, which forwards to `binary_search_for_size` and hits the `if impact_bps > 10000` guard.

Common situations: Unit confusion between percent and basis points (e.g. passing 150 meaning 150% or 1.5x); unbounded user input; multiplying impact by a leverage factor without clamping; mixing decimal impact (1.5) with bps-scale APIs.

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

• Impact must be greater than zero
• All --checkpoint-blocks exceed --to-block {to_block}
• Invalid tick range: {tick_lower} >= {tick_upper}
• Ticks {tick_lower} and {tick_upper} must be multiples of the
• Invalid tick bounds for {tick_lower} and {tick_upper}

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