Anchor IDL Mismatch

Overview

The Anchor IDL mismatch detector identifies inconsistencies between the Anchor Interface Definition Language (IDL) and the actual program implementation. Mismatches in instruction discriminators, account ordering, missing or extra accounts, and incorrect account type indicators can cause client-side vulnerabilities and unexpected behavior.

For remediation guidance, see Anchor IDL Mismatch Remediation.

Why This Is an Issue

The Anchor IDL describes the program’s public interface. Client libraries, SDKs, and frontends use the IDL to construct transactions. If the IDL does not match the actual program, clients may send malformed transactions, fail silently, or create security vulnerabilities. Discriminator mismatches cause instruction confusion, where the wrong handler processes a transaction.

How to Resolve

Before (Vulnerable)

// Program uses custom discriminator that doesn't match Anchor convention
pub fn process_instruction(data: &[u8]) -> ProgramResult {
    let discriminator = &data[..4];  // Non-standard 4-byte discriminator
    match discriminator {
        [0, 0, 0, 1] => handle_deposit(data),
        _ => Err(ProgramError::InvalidInstructionData),
    }
}

After (Fixed)

// Fixed: use standard Anchor 8-byte discriminators
#[program]
pub mod my_program {
    pub fn deposit(ctx: Context<Deposit>, amount: u64) -> Result<()> {
        // Anchor generates standard 8-byte discriminator from sha256("global:deposit")
        handle_deposit(ctx, amount)
    }
}

Example JSON Finding

{
  "detector": "anchor-idl-mismatch",
  "severity": "high",
  "confidence": 0.65,
  "message": "Instruction discriminator does not match expected Anchor 8-byte pattern",
  "location": { "function": "process_instruction", "block": 0, "statement": 2 }
}

Detection Methodology

1. Discriminator pattern detection: Checks whether instruction discriminators follow Anchor’s SHA256-based 8-byte pattern.
2. Account ordering analysis: Verifies that account accesses follow the order expected by Anchor conventions.
3. Account count validation: Flags instructions that access more or fewer accounts than expected.
4. Type indicator checking: Verifies account type markers match Anchor patterns.

Limitations

False positives: Non-Anchor programs with custom discriminator schemes will be flagged. False negatives: Programs that appear to use Anchor patterns but have subtle implementation differences may pass.

Related Detectors

• Anchor Discriminator Validation — missing discriminator checks
• Non-Anchor Discriminator — non-Anchor instruction routing

References

• Anchor — IDL Specification
• CWE-436: Interpretation Conflict