nautechsystems/nautilus_trader · error · anyhow::Error

Impact must be greater than zero

Error message

Impact must be greater than zero

What it means

`binary_search_for_size` validates its `impact_bps` input before searching: a value of zero is rejected because the binary search needs a strictly positive target impact to bracket and converge on. Zero impact is mathematically meaningless here (it would correspond to a zero-size trade), so the library fails fast with this message.

Source

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

    let mut quote = profiler.swap_exact_in(size, zero_for_one, None)?;
    quote.calculate_trade_info(&profiler.pool.token0, &profiler.pool.token1)?;
    let trade_info = quote
        .trade_info
        .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

View on GitHub (pinned to 18893faf8b)

Solutions

1. Pass a positive `impact_bps` value (e.g. 5 bps for 0.05%) when requesting size estimation.
2. Add caller-side validation rejecting impact_bps == 0 before invoking the estimator.
3. Use a sensible default minimum impact in config rather than 0.
4. Interpret zero-impact requests as 'not applicable' and skip the estimation instead of calling it.

Example fix

// before
let size = size_for_impact_bps(&profiler, 0, true, &config)?;
// after
let impact_bps = 10; // 0.10%
let size = size_for_impact_bps(&profiler, impact_bps, true, &config)?;

fn valid_impact(impact_bps: u32) -> bool {
    (1..=10000).contains(&impact_bps)
}
// call only if valid_impact(impact_bps)

let size = match size_for_impact_bps(&profiler, impact_bps, zero_for_one, &config) {
    Ok(s) => s,
    Err(e) if e.to_string().contains("Impact must be greater than zero") => {
        // reject config or substitute a minimum impact floor
    },
    Err(e) => return Err(e),
};

When it happens

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

Common situations: Configuring an estimator with a default-initialized/placeholder impact value of 0; user input not yet validated; a downstream computation that collapsed the target impact to zero (e.g. rounding or a min-impact floor of 0).

Understand the failure class

Background: "Must be a positive integer", "Invalid value", "Unsupported": the invalid-argument-value error family, when a library rejects the value you pass — this error's family across 35 libraries.

Related errors

• Impact cannot exceed 100% (10000 bps)
• 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/d950c84d317b5f94. Report an issue: GitHub.