nautechsystems/nautilus_trader · error

Wrap authorization does not match the transaction call

Error message

Wrap authorization does not match the transaction call

What it means

The client verifies that an authorized Wrap operation (WETH deposit) exactly matches the transaction actually being signed: recipient must be the authorized WETH contract, value nonzero, and calldata exactly WETH's deposit() selector. Any mismatch means the signed call would exceed or differ from what was authorized, so signing is refused.

Source

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

        VerificationOutcome::Retryable(_) => {
            anyhow::bail!("{context} verification is retryable")
        }
        VerificationOutcome::LocallyInvalid(_) => {
            anyhow::bail!("{context} verification is locally invalid")
        }
    }
}

fn validate_transaction_authorization(
    authorization: Option<&TransactionAuthorization>,
    to: Address,
    value: U256,
    input: &[u8],
) -> anyhow::Result<()> {
    match authorization {
        None => Ok(()),
        Some(TransactionAuthorization::Wrap { weth }) => {
            anyhow::ensure!(
                to == *weth && !value.is_zero() && input == WETH9::depositCall::SELECTOR,
                "Wrap authorization does not match the transaction call"
            );
            Ok(())
        }
        Some(TransactionAuthorization::Approve {
            token,
            router,
            amount,
        }) => {
            let expected = ERC20::approveCall {
                spender: *router,
                amount: *amount,
            }
            .abi_encode();
            anyhow::ensure!(
                to == *token && value.is_zero() && input == expected,
                "Approve authorization does not match the transaction call"

View on GitHub (pinned to 18893faf8b)

Solutions

1. Ensure the transaction's `to` equals the authorized WETH address and `input` equals WETH9::depositCall::SELECTOR with nonzero value.
2. Check the transaction builder so the wrap authorization and emitted call are built from the same parameters.
3. Verify the weth address in configuration matches the canonical WETH9 deployment on the target chain.
4. Re-derive the authorization from the same code path that builds the call to keep them in sync.

Example fix

// before: wrap auth but call built incorrectly
let input = WETH9::transferCall { .. }.abi_encode(); // wrong selector
verify_wrap(Some(Wrap { weth }), weth, value, &input)?;
// after
let input = WETH9::depositCall::SELECTOR.to_vec();
verify_wrap(Some(Wrap { weth }), weth, value, &input)?;

fn wrap_call_matches(weth: Address, value: U256, input: &[u8]) -> bool {
    value != U256::zero() && input == WETH9::depositCall::SELECTOR
}

fn is_wrap_auth(auth: &TransactionAuthorization) -> Option<Address> {
    if let TransactionAuthorization::Wrap { weth } = auth { Some(*weth) } else { None }
}

match result { Err(e) if e.to_string().contains("Wrap authorization does not match") => { rebuild_tx_from_authorization(); retry(); } Ok(v) => v }

When it happens

Trigger: prepare/sign path invoked with a TransactionAuthorization::Wrap but the transaction's `to` is not the authorized weth address, `value` is zero, or `input` is not the deposit selector — i.e. the call payload diverged from the authorization.

Common situations: Bug in transaction construction that swaps `to`/calldata; WETH address misconfigured to a different token; authorization created for wrap but the builder emitted a different call (e.g. forgot to set value or used transfer instead of deposit).

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

• Wrap amount must be positive
• Verified call trace contains a forbidden state-changing oper
• Approve authorization does not match the transaction call
• Unsupported `OrderSide` for Binance: {value:?}
• invalid OrderSide: must be Buy or Sell, was {side}

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