diem/diem · error · ErrorKind::VerificationError

VerificationError({0:?})

Error message

VerificationError({0:?})

What it means

ErrorKind::VerificationError wraps a VMStatus (stand-in for VMError, per the TODO) when Move bytecode verification of a published module or script fails. Its display is 'VerificationError(<VMStatus>)'.

Source

Thrown at language/testing-infra/functional-tests/src/errors.rs:22

pub use anyhow::{anyhow, bail, format_err, Error, Result};
use diem_types::{transaction::TransactionOutput, vm_status::VMStatus};
use thiserror::Error;

/// Defines all errors in this crate.
#[derive(Clone, Debug, Error)]
pub enum ErrorKind {
    #[error(
        "an error occurred when executing the transaction, vm status {:?}, txn status {:?}",
        .0,
        .1.status(),
    )]
    VMExecutionFailure(VMStatus, TransactionOutput),
    #[error("the transaction was discarded: {0:?}")]
    DiscardedTransaction(TransactionOutput),
    #[error("the checker has failed to match the directives against the output")]
    CheckerFailure,
    // TODO replace VMStatus with VMError
    #[error("VerificationError({0:?})")]
    VerificationError(VMStatus),
    #[error("other error: {0}")]
    #[allow(dead_code)]
    Other(String),
}

View on GitHub (pinned to fc4714a8ea)

Solutions

1. Read the wrapped VMStatus for the specific verification failure kind and fix the bytecode/source
2. Recompile the module from valid Move source with the current compiler
3. Ensure dependency modules on-chain match the versions compiled against

// Compile from Move source and let the compiler catch verifier-level issues first
let compiled = move_compiler::compile(source)?;

fn is_verification_error(e: &ErrorKind) -> Option<&VMStatus> {
    if let ErrorKind::VerificationError(s) = e { Some(s) } else { None }
}

if let ErrorKind::VerificationError(status) = err {
    eprintln!("bytecode failed verification: {:?}", status);
}

When it happens

Trigger: Publishing or running bytecode that fails Move verifier checks: type safety violations, illegal references, bad bytecode from hand-crafted modules, or linking failures against dependencies.

Common situations: Hand-writing bytecode in tests, publishing a module whose dependencies were updated, scripting raw module bytes instead of source compilation.

Related errors

• main() cannot currently be bytecode
• Target locals out contains new local
• Invalid number of children for basic block {:?}
• Specified output file path is a directory
• Unable to serialize keys

AI-assisted analysis of diem/diem@fc4714a8ea (2026-09-04). Data as JSON: /api/errors/bb159ec4d52d24f1. Report an issue: GitHub.