installed WASM executable differs from its authority receipt

Error message

installed WASM executable differs from its authority receipt (approved {}, found {})

What it means

The receipt pins (or, post-migration, is expected to pin) the BLAKE3 hash of the installed WASM executable. If the approved hash differs from the hash of the executable actually on disk, the binary was changed after approval and verification fails. The message shows both the approved and found hashes, using "<non-WASM>" when either side is absent.

Source

Thrown at crates/astrid-capsule-install/src/authority.rs:592

            .collect::<Vec<_>>()
            .join("; ");
        bail!(
            "manifest exceeds its installed capability approval: {details}; reinstall and approve the expansion"
        );
    }
    if authority.manifest_digest != current_manifest_digest {
        bail!(
            "installed Capsule.toml differs from the exact manifest approved at install; reinstall the capsule"
        );
    }
    if !authority.wasm_hash_pinned {
        authority.wasm_hash_pinned = true;
        authority.approved_wasm_hash = executable_hash;
        AuthorityReceiptTransaction::stage(home, target_dir, &authority)?
            .commit()
            .context("failed to migrate installed authority executable pin")?;
    } else if authority.approved_wasm_hash != executable_hash {
        bail!(
            "installed WASM executable differs from its authority receipt (approved {}, found {})",
            authority
                .approved_wasm_hash
                .as_deref()
                .unwrap_or("<non-WASM>"),
            executable_hash.as_deref().unwrap_or("<non-WASM>"),
        );
    }
    Ok(())
}

/// Read and hash the exact executable the WASM engine would load.
///
/// `meta.json` is treated as a pointer, never as proof: the pointed-to bytes
/// are re-hashed before an authority receipt is compared or migrated.
fn verified_installed_wasm_hash(
    home: &AstridHome,
    target_dir: &Path,

View on GitHub (pinned to affd8760f4)

Solutions

Reinstall the capsule from the approved artifact so the wasm matches the receipt hash
Restore the original wasm binary that was approved at install
If the new binary is intentional, re-run the authorized install to approve and pin its new hash

Example fix

// before
// replaced installed module.wasm with a rebuilt one
verify_installed_authority(&home, &target_dir, &manifest, None)?;
// after
cp approved-build/module.wasm ~/.astrid/capsules/my-capsule/module.wasm
verify_installed_authority(&home, &target_dir, &manifest, None)?;

Defensive patterns

Strategy: validation

Validate before calling

let h = blake3::hash(std::fs::read(target_dir.join("module.wasm"))?.as_slice()).to_hex();
if Some(h.as_str()) != approved_receipt.approved_wasm_hash.as_deref() {
    return Err(anyhow!("wasm {} != approved {} — reinstall", h, approved_receipt.approved_wasm_hash.as_deref().unwrap_or("<non-WASM>")));
}

Prevention

Never swap installed wasm binaries outside the install flow
Verify artifact hashes before and after deployment
Keep approved build artifacts archived so the pinned binary can be restored

When it happens

Trigger: verify_installed_authority detects authority.approved_wasm_hash != executable_hash — the installed .wasm file was replaced, rebuilt, or corrupted after the receipt pinned its hash.

Common situations: Overwriting the installed wasm with a locally rebuilt binary; a partial/failed update leaving a truncated wasm; mixing artifacts from different builds in the capsule directory.

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 astrid-runtime/astrid@affd8760f4 (2026-09-09). Data as JSON: /api/errors/aab2dd5d735504dc. Report an issue: GitHub.