nautechsystems/nautilus_trader · error · anyhow::Error

Finalized transaction gas commission overflow

Error message

Finalized transaction gas commission overflow

What it means

Gas commission arithmetic guard in emit_finalized_swap_fill: effective_gas_price * gas_used (both U256 from the receipt) is computed with checked_mul and this error fires on overflow. Well-formed receipts can never overflow U256, so in practice this signals malformed or hostile RPC data.

Source

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

        plan.instrument_id,
        plan.pool.pool_identifier,
        UnixNanos::from(timestamp_ns),
    );
    swap.calculate_trade_info(&plan.pool.token0, &plan.pool.token1, None)?;
    let trade = swap
        .trade_info
        .as_ref()
        .ok_or_else(|| anyhow::anyhow!("Finalized Swap has no calculated trade information"))?;
    anyhow::ensure!(
        trade.order_side == OrderSide::Sell,
        "Finalized Swap side {} does not match Sell order",
        trade.order_side
    );
    let gas_cost = included
        .receipt
        .effective_gas_price
        .checked_mul(U256::from(included.receipt.gas_used))
        .ok_or_else(|| anyhow::anyhow!("Finalized transaction gas commission overflow"))?;
    let commission = Money::from_u256(gas_cost, plan.pool.chain.native_currency())?;
    let trade_digest = keccak256(format!("{}:{}", included.tx_hash, swap.log_index));
    let trade_digest = trade_digest.to_string();
    let trade_id = TradeId::new_checked(&trade_digest[2..38])?;

    if plan
        .order
        .trade_ids()
        .iter()
        .any(|existing| **existing == trade_id)
    {
        return Ok(());
    }

    emitter.emit_order_filled(
        &plan.order,
        VenueOrderId::new_checked(included.tx_hash.to_string())?,
        None,

View on GitHub (pinned to 2114cf6f76)

Solutions

  1. Fetch the receipt directly and inspect gasUsed and effectiveGasPrice: gasUsed should be within the block gas limit and the price near current network fees.
  2. Use a trusted, canonical RPC endpoint for execution.
  3. If a stub produced the receipt, generate realistic bounded values.
  4. Report persistently malformed receipts to the provider.
Defensive patterns

Strategy: validation

Validate before calling

fn receipt_gas_is_plausible(gas_used: u128, price: U256) -> bool {
    gas_used < 50_000_000 && price < U256::from(10u128).pow(U256::from(15)) // 1e15 wei ~= absurd ceiling
}

Type guard

fn receipt_gas_fields_plausible(receipt: &RpcTransactionReceipt) -> bool {
    receipt_gas_is_plausible(receipt.gas_used, receipt.effective_gas_price)
}

Try / catch

Catch the overflow, dump the raw receipt JSON for diagnosis, and quarantine the endpoint that produced it; a compliant node cannot trigger this path.

Prevention

When it happens

Trigger: A receipt whose effective_gas_price or gas_used is an absurd value (near U256::MAX) returned by a broken proxy, a malicious endpoint, or a deserialization bug mapping the wrong JSON field.

Common situations: Custom RPC middleware or test stubs fabricating receipts without realistic bounds; endpoints that return null-ish defaults coerced to huge integers.

Related errors


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