nautechsystems/nautilus_trader · error

{context} verification is retryable

Error message

{context} verification is retryable

What it means

Raised when the verification outcome is Retryable: verification could not complete but the failure is transient, so the caller may retry. The helper surfaces this as an error so callers can distinguish transient verification failures from hard disagreements.

Source

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

fn verified_value<T>(outcome: VerificationOutcome<T>, context: &str) -> anyhow::Result<T> {
    required_verification(outcome, context).map(|verified| verified.value)
}

fn required_verification<T>(
    outcome: VerificationOutcome<T>,
    context: &str,
) -> anyhow::Result<Verified<T>> {
    match outcome {
        VerificationOutcome::Verified(verified) => Ok(verified),
        VerificationOutcome::Disagreement(_) => {
            anyhow::bail!("{context} verification disagreed")
        }
        VerificationOutcome::Unavailable(_) => {
            anyhow::bail!("{context} verification is unavailable")
        }
        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,

View on GitHub (pinned to 18893faf8b)

Solutions

1. Retry the verification (and transaction flow) with exponential backoff
2. Reduce submission rate or add client-side throttling to avoid provider limits
3. Configure a more reliable verification provider or multiple endpoints
4. Check network connectivity between the client and the RPC endpoint

Example fix

// before
match client.submit_order(order).await {
    Err(e) if e.to_string().contains("verification is retryable") => (), // gave up
    r => r?,
}
// after
for attempt in 0..3 {
    match client.submit_order(order).await {
        Err(e) if e.to_string().contains("verification is retryable") => {
            tokio::time::sleep(Duration::from_millis(200 * 2u64.pow(attempt))).await;
            continue;
        }
        r => { r?; break; }
    }
}

for attempt in 0..max_retries {
    match client.submit_order(order).await {
        Err(e) if e.to_string().contains("verification is retryable") => {
            backoff(attempt).await;
            continue;
        }
        r => { r?; break; }
    }
}

When it happens

Trigger: VerificationOutcome::Retryable returned by a verification check — e.g. temporary network error, node timeout, or provider throttling while fetching the verification data.

Common situations: Transient RPC timeouts under load; provider rate limits during bursts of submissions; brief node restarts mid-verification.

Understand the failure class

Background: Request timed out: what client-side request timeouts mean across libraries (Request timed out, TIMED_OUT, APITimeoutError) — this error's family across 39 libraries.

Related errors

• {context} verification disagreed
• {context} verification is unavailable
• {context} verification is locally invalid
• Receipt verification is locally invalid for transaction {tx_
• Finalized header verification disagreed

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