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 Mirage's open-source tool for creating verifiable variants of EVM escrow bytecode. It helps Mirage avoid reusing one identical escrow signature for every payment while preserving a verification path for the user and the parties they choose to involve.

Why Contract Variation?

Mirage uses a fresh escrow for each payment. If every escrow had identical bytecode, the pattern would be easy to recognize. That would weaken Mirage's goal of making private stablecoin payments look closer to normal public-chain activity.

Azoth addresses that by transforming the escrow bytecode into different variants that preserve the same behavior.

This is not meant to hide what the escrow is allowed to do. The escrow contract is open source. Azoth's role is to make repeated escrow deployments less mechanically identical while keeping them checkable by the user and any party the user shares verification data with.

How Azoth Works

When you compile a Solidity contract, the compiler produces EVM bytecode: the low-level instructions the Ethereum Virtual Machine executes. Azoth operates at this level, restructuring bytecode while preserving 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 gives Azoth a structured view of the contract before it applies any transformations.

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 Variation: Solidity contracts use common patterns to route function calls. Azoth can change this routing structure while preserving behavior.

  • 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. The important requirement is semantic equivalence: the transformed contract must behave like the original contract.

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 is central to Mirage's security model.

Here's why: when a user creates a Mirage escrow, their client also generates the seed used for Azoth's transformation. That seed is not public by default.

Because Azoth is deterministic, the user and anyone they share the seed with 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 verifier knows the deployed contract is a valid Mirage escrow variant.

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 maintains a structured understanding of the code's behavior and validates equivalence after transformations.

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
  • Has a different bytecode shape
  • Avoids one repeated escrow signature
  • Can be independently verified by anyone with the seed
  • Preserves the same escrow behavior

To an observer examining the blockchain, Mirage avoids making every escrow deployment mechanically identical. To the user and the parties they authorize, the same escrow remains verifiable.

That balance is the point: variation for public-chain privacy, determinism for verification.