Invalid event signature for '{event_name}': expected {expect

Error message

Invalid event signature for '{event_name}': expected {expected_hash}, was {actual_hex}

What it means

validate_event_signature checks that the first topic (topic0) of an RPC log matches the expected keccak256 event signature hash for a named event. When the hex-encoded topic0 differs from the expected hash, anyhow::ensure! aborts with this error naming the event, expected hash, and actual hex. It guards against decoding a log emitted by a different event or contract version.

Source

Thrown at crates/adapters/blockchain/src/rpc/log.rs:180

}

/// Validate event signature from topic0.
///
/// The first topic (topic0) of an Ethereum event log contains the keccak256 hash
/// of the event signature. This function validates that the actual signature
/// matches the expected one.
///
/// # Errors
///
/// Returns an error if the signature doesn't match or topic0 is missing.
pub fn validate_event_signature(
    log: &RpcLog,
    expected_hash: &str,
    event_name: &str,
) -> anyhow::Result<()> {
    let sig_bytes = extract_topic_bytes(log, 0)?;
    let actual_hex = hex::encode(&sig_bytes);
    anyhow::ensure!(
        actual_hex == expected_hash,
        "Invalid event signature for '{event_name}': expected {expected_hash}, was {actual_hex}",
    );
    Ok(())
}

#[cfg(test)]
mod tests {
    use rstest::{fixture, rstest};

    use super::*;

    /// Real RPC log from Arbitrum PoolCreated event at block 185
    /// Pool: 0xB9Fc136980D98C034a529AadbD5651c087365D5f
    /// token0: 0x2E5353426C89F4eCD52D1036DA822D47E73376C4
    /// token1: 0x838930cFE7502dd36B0b1ebbef8001fbF94f3bFb
    /// fee: 3000, tickSpacing: 60
    #[fixture]

View on GitHub (pinned to 18893faf8b)

Solutions

Recompute the expected hash with keccak256 over the exact canonical signature string (correct event name, parameter types, order, no spaces) and compare that.
Verify the expected_hash matches hex::encode output format: 64 lowercase hex chars with no 0x prefix; normalize both sides before comparing if needed.
Confirm the RpcLog actually came from the event/contract you expect (check address and topic count) before validating.
If event definitions changed in a new contract version, update the stored signature hashes rather than forcing the old hash.

Example fix

// before
let expected = "0xDDF252AD1BE2C89B69C2B068FC378DAA952BA7F163C4A11628F55A4DF523B3EF";
validate_event_signature(&log, expected, "Transfer")?;
// after
let expected = "ddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef"; // lowercase, no 0x, canonical signature
validate_event_signature(&log, expected, "Transfer")?;

Defensive patterns

Strategy: validation

Validate before calling

fn is_valid_event_signature(log_topic0: &str, expected: &str) -> bool {
    let norm = |s: &str| s.trim_start_matches("0x").to_ascii_lowercase();
    log_topic0.len() == 64 && expected.len() == 64 && norm(log_topic0) == norm(expected)
}

Try / catch

match validate_event_signature(&log, expected_hash, event_name) {
    Ok(()) => { /* proceed with decoding */ }
    Err(e) => { warn!("event signature mismatch: {e}"); /* skip or route log */ }
}

Prevention

Generate signature hashes programmatically with keccak256 over the canonical ABI signature, never by hand.
Store expected hashes as lowercase hex without the 0x prefix to match hex::encode output.
Re-verify hashes after any contract upgrade or ABI change.
Check the emitting contract address alongside the signature.

When it happens

Trigger: Calling validate_event_signature with an RpcLog whose topic0 does not equal the provided expected_hash string. This happens when the log is from a different event than claimed, the expected_hash is computed with the wrong signature text (wrong param types/order), the hash is not lowercase hex of the correct 32 bytes, or the log genuinely has no/misaligned topic0.

Common situations: ABI signature drift after a contract upgrade or event parameter change; hand-writing the signature string (e.g. 'Transfer(...)') with wrong parameter types so the keccak hash differs; comparing against a checksummed or 0x-prefixed hash while hex::encode produces plain lowercase hex; subscribing to logs where anonymous or overloaded events share topics.

Understand the failure class

Background: Checksum mismatch errors: "checksum verification failed", "digest mismatch", "expected vs actual checksum" — what they mean and how to fix them — this error's family across 41 libraries.

Related errors

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