AVM

Read the layers before anything else

Four separate things are called “the AVM”. They have four different statuses. Treating any of them as production mainnet support would be wrong.

Four separate AVM status layers. The word AVM covers four different things with four different statuses. The whitepaper describes an architecture and is proposed. The beta interpreter is working code with its own test suite and is experimental. Universe runtime integration is experimental: Inscribe AVM Studio, the /avm/ API, and the indexer AVM RPCs are validated on Bitcoin Testnet4 only, and mainnet AVM writes are not enabled in production. Universe runtime attestation is a readiness report only: no conformance statement has been published. Collapsing these four into one is how a design document ends up described as a live feature.

Four separate AVM status layers

The word AVM covers four different things with four different statuses. The whitepaper describes an architecture and is proposed. The beta interpreter is working code with its own test suite and is experimental. Universe runtime integration is experimental: Inscribe AVM Studio, the /avm/ API, and the indexer AVM RPCs are validated on Bitcoin Testnet4 only, and mainnet AVM writes are not enabled in production. Universe runtime attestation is a readiness report only: no conformance statement has been published. Collapsing these four into one is how a design document ends up described as a live feature.

The four layers

Layer	Status	What exists
Architectural whitepaper concepts	Proposed	A design document describing a system
Official beta interpreter	Experimental or beta	Working code with its own test suite
Universe runtime integration	Testnet4 only	AVM Studio at /avm-studio, the /avm/* API, and the blockchain.atomicals.avm.* RPCs. No mainnet writes
Universe runtime attestation	Readiness only	An indexer readiness report. No published conformance statement

What the interpreter is

A modified Bitcoin script interpreter, distributed as a library and a command line tool. The upstream project describes it as a sandbox invoked per contract that simulates execution of a Bitcoin script program. The caller provides state inputs, scripts, and block variables, and updated state is returned as CBOR encoded structures.

Key differences from Bitcoin script, as described upstream:

• most originally disabled opcodes are re-enabled, including concatenation, multiplication, division, and shifts;
• arbitrarily large numbers are supported;
• new opcodes handle deposit and withdrawal of non-fungible objects and ARC-20 tokens;
• new opcodes read and write private state storage;
• a hashing opcode provides additional digest algorithms;
• signature checking is replaced by a custom authorisation opcode.

Read next

Topic	Page
The generated opcode inventory	Opcodes
State, execution inputs, and outputs	State and execution
Threat model, resource limits, and what is unverified	Status and limitations

What this documentation will not do

It will not describe AVM behavior as available, supported, or production ready. It will not describe Testnet4 validation as mainnet support. It will not present whitepaper concepts as implemented behavior.

The Universe AVM surfaces exist for validation on Bitcoin Testnet4, from activation height 27000. Signet cannot carry AVM with the pinned indexer. Mainnet AVM writes are not enabled in production. A network becomes supported only when a pinned revision, activation conditions, and executed conformance vectors exist for it. See AVM status and limitations and status and known limitations.