Honest limits

WARDEN is built on real, verifiable ideas. It is also alpha software. This page states the limits precisely so you can make an accurate threat model before depending on any particular capability. Frame these as design constraints, not defects: knowing where a tool cannot be trusted is what makes it trustworthy where it can.

​

Oracle quality is bounded by corpus coverage

The Emscripten Oracle is only as good as the flag-matrix corpus you give it. The design calls for a CI farm that sweeps every tagged emsdk release across the full build matrix: -O0 through -Oz, -pthread on/off, LTO on/off, exception modes. In practice, the corpus you supply with warden oracle build is whatever labeled .wasm modules you have on hand. Gaps in that matrix produce gaps in identification. Concretely:

• A function compiled with -O3 -flto that does not appear in your corpus at those flags may fail to match even if the same function compiled at -O2 is present, because LTO inlining and cross-module constant folding can materially change the structural skeleton and MinHash signature.
• An Emscripten version you have not built corpus modules for falls back to fuzzy matching against the nearest version, which degrades precision on functions whose codegen changed between those releases.
• Custom toolchains (forks of Emscripten, emscripten-fastcomp artifacts, or modules compiled with a non-Emscripten WASM backend) are outside the Oracle’s scope entirely. Fuzzy fingerprinting (minhash_jaccard + histogram cosine) still runs, so partial matches are surfaced rather than nothing, but confidence scores will be low and version inference will be unreliable.

​

Obfuscation, custom allocators, and whole-program LTO inlining

WARDEN’s function identity (stable_id) is keyed to structural skeleton, call-neighborhood, type signature, and instruction count. All are derived from function boundaries that the WebAssembly binary exposes explicitly. Techniques that blur those boundaries weaken matching proportionally. Whole-program LTO inlining. An upstream library function aggressively inlined into its callers no longer appears as a discrete function in the binary. The Oracle cannot match what is not there; the diff engine cannot carry over an annotation for a function that was absorbed into several others. Custom allocators. A module that replaces dlmalloc/emmalloc with a bespoke heap implementation may look nothing like the Oracle’s memory-management signatures. Manual annotation with warden set-name is the fallback. Deliberate obfuscation. Opaque predicates, control-flow flattening, and instruction substitution degrade the structural hash and MinHash toward random on maximally scrambled code. The exact hash (SHA-256 of the raw body) remains accurate for “unchanged” detection even under obfuscation, but semantic identification fails.

​

”Behavioral equivalence” is corpus-bounded evidence, not formal proof

WARDEN uses the phrase “100% behavioral equivalence” to mean: differential execution against the original .wasm produced matching outputs and side effects on the inputs tested. This is strong evidence, not a mathematical guarantee.

• warden verify currently provides determinism checking (does re-parsing the binary produce the same KB?) and a readiness report for the wasm2c differential harness. The harness itself activates only when wasm2c or w2c2 and a C toolchain are present at runtime.
• Input coverage is finite. A differential test corpus that does not exercise a code path cannot confirm or deny equivalence on that path.
• Formal verification via symbolic execution or deductive proof is not implemented. SeeWasm integration is listed in the vision as a future capability for specific path conditions, not a shipped feature.

​

Heavy refactors legitimately produce large review queues

WARDEN’s diff engine (warden diff) classifies each function as identical, moved, modified, new, or deleted using a composite similarity scorer (exact hash, structural hash, fuzzy MinHash Jaccard, histogram cosine, call-neighborhood overlap). It carries annotations forward automatically for unchanged and moved functions, and flags modified functions for review. On a release where the vendor did a large refactor (split a module, merged hot paths, changed the calling convention of a widely-used helper), the diff engine will correctly surface a large fraction of functions for review, because they genuinely changed. WARDEN reduces that queue by filtering out toolchain churn (Emscripten version bumps auto-attributed by the Oracle) and by carrying forward the large unchanged majority.

​

The offline agent backend is a heuristic placeholder

Without pip install -e '.[agents]' and either OPENAI_API_KEY or ANTHROPIC_API_KEY, the agent crew runs the OfflineHeuristicBackend. Its logic is deliberate and documented: These numbers are honest low-confidence signals, not semantic understanding. The offline backend exists to guarantee 100% symbol coverage: every function has some binding, without requiring a network connection. It does not guarantee meaningful names.

​

SIMD immediate decoding covers documented ranges; unknown opcodes degrade gracefully

The opcode decoder handles the WASM MVP plus the extensions an Emscripten module is expected to emit: sign-extension, non-trapping float-to-int (0xFC prefix), bulk memory, reference types, tail calls, threads/atomics (0xFE prefix), and SIMD (0xFD prefix). SIMD sub-opcode immediates are decoded by documented ranges; not all 256 possible sub-opcodes in the 0xFD space have fully characterized immediate layouts in the current implementation. When an unknown or undocumented sub-opcode is encountered, an UnsupportedOpcode exception is raised and caught at the function level. The function is marked with a disasm_error note in its fingerprint and the error surfaces in warden show. The function is still byte-fingerprintable via its exact SHA-256 hash and structural skeleton up to the unknown opcode so it participates in “unchanged” detection in the diff engine, but instruction-level analysis (opcode histogram, MinHash, call extraction) is incomplete for that function. Oracle and diff matching degrade to exact-hash and partial structural comparison for affected functions.

​

Summary