Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

An Introduction to Azoth

Azoth is the most advanced open-source deterministic EVM bytecode obfuscator. It's the engine that makes Mirage's undetectability possible.

Why Bytecode Obfuscation?

Remember the undetectability challenge? Traditional privacy tools fail because their contracts are obvious. Everyone knows what Tornado Cash's contracts look like. Blockchain analysis firms maintain databases of known privacy contract signatures and patterns. The moment you interact with one, you're flagged.

Mirage solves this by deploying fresh, unique escrow contracts for every transaction. But here's the problem: if every contract was compiled from the same source code, they'd all look identical. Blockchain analysts could still identify them by their bytecode pattern.

This is where Azoth comes in. It takes the escrow contract and transforms it into countless different versions that all behave identically but look completely different at the bytecode level. Each deployment appears to be a unique, unrelated contract.

How Azoth Works

When you compile a Solidity contract, the compiler produces EVM bytecode: a sequence of low-level instructions the Ethereum Virtual Machine executes. Think of it like assembly code for Ethereum. Azoth operates at this level, restructuring the bytecode while preserving its exact behavior.

The process works in three stages:

Stage 1: Analysis

Azoth first decodes the raw bytecode into individual instructions, then builds a Control Flow Graph (CFG). This graph maps out every possible execution path through the contract: which instructions can jump to which, where functions begin and end, and how the contract's logic flows.

This is like creating a detailed map of a building before renovating it. You need to understand every room, hallway, and staircase before you start moving walls around.

Stage 2: Transformation

With the CFG in hand, Azoth applies a series of transforms—modifications that change how the code looks without changing what it does. Each transform targets a different aspect of the bytecode, for example:

  • Function Dispatcher Obfuscation: Solidity contracts use a standard pattern to route function calls. This pattern is a dead giveaway for identifying contracts. Azoth replaces the obvious selector-based routing with an obscured token-based system that behaves identically but looks completely different.

  • Control Flow Shuffling: The order of code blocks in bytecode typically reflects the order in the source code. Azoth randomizes this layout, scattering the logic across the contract while maintaining correct jump targets.

Stage 3: Reassembly and Validation

After transformation, Azoth reassembles the modified CFG back into executable bytecode. But here's the critical part: it validates that the new bytecode is semantically equivalent to the original. The obfuscated contract must behave exactly the same as the original in every possible scenario.

This validation happens at multiple levels, from basic structural checks to formal verification using SMT solvers. If anything doesn't match, Azoth rejects the output. This guarantee is what makes it safe to use in production.

Why Determinism Matters

Azoth is deterministic: given the same input bytecode and the same seed value, it always produces exactly the same output. This might seem like a minor technical detail, but it's actually fundamental to Mirage's security model.

Here's why: when you use Mirage, you're depositing funds into what appears to be a random contract. How do you know that contract is safe? How do you know it's actually a Mirage escrow and not something malicious?

Because Azoth is deterministic, anyone can verify a deployed contract:

  1. Take the original escrow contract source code (which is public)
  2. Compile it to bytecode
  3. Run it through Azoth with the same seed
  4. Compare the result to what's deployed on-chain

If they match, the contract is legitimate. This is exactly what Mirage executors do before committing their bond. They independently verify that the contract they're about to interact with is a valid, unmodified Mirage escrow.

What Makes Azoth Different

There are other bytecode manipulation tools out there, but Azoth is built specifically for this use case:

Open Source and Auditable: The entire codebase is public. You don't have to trust claims about what it does—you can read the code yourself or have it audited.

Semantic Preservation: Azoth doesn't just scramble bytes and hope for the best. It maintains a formal understanding of the code's behavior and validates equivalence after every transformation.

Production-Grade Reliability: Azoth is designed for real contracts handling real money. The validation pipeline catches any transformation that could alter behavior, no matter how subtle.

Extensible Architecture: New transforms can be added as needed. As blockchain analysis techniques evolve, Azoth can evolve with them.

The Result

After Azoth processes the escrow contract, the output is bytecode that:

  • Executes identically to the original
  • Looks completely different at the byte level
  • Doesn't match any known contract signatures
  • Can be independently verified by anyone
  • Provides no useful patterns for blockchain analysts to identify

To an observer examining the blockchain, a Mirage escrow contract looks like just another of the thousands of unverified contracts deployed every day. There's no signature, no pattern, nothing to flag. The contract does its job and disappears into the noise.

This is how Mirage achieves what no other privacy solution has: actual undetectability. Not just breaking the sender-recipient link, but making it impossible to prove a privacy protocol was ever used.