AIP-12: The Virtual Machine: Extend the EVM, not a New VM

Preamble

Field	Value
AIP	12
Title	The Virtual Machine: Extend the EVM, not a New VM
Author	Aere Network Foundation
Type	Informational
Category	(none)
Status	Final
Created	2026-07-19
Requires	None
Supersedes	None
Superseded-By	None
Ratification	Foundation-ratified (pre-decentralization)

Abstract

This AIP records the decision to keep the EVM unchanged and to add Aere's differentiating capability as precompiles and client-fork rules at reserved addresses, rather than designing a new virtual machine. It backfills a decision already live on chain 2800.

Motivation

Aere differentiates on post-quantum verification, parallel execution, and extended block-hash lookback. It must add these without taxing the developer surface it depends on for adoption.

Specification

Solidity, EVM bytecode, JSON-RPC, and the developer tooling are unchanged. Differentiation is added as:

precompiles at otherwise-empty reserved addresses (the 0x0AE1..0x0AE5 band, live from block 9,189,161, AIP-7), and
client-fork rules activated in the same manner Ethereum activates its own hard forks.

No new instruction set, no new language, no nonstandard account model, and no nonstandard RPC.

Rationale

A mature VM has years of implementation hardening, a known cost model, and an operational history; a new VM starts that clock at zero, maximizing both technical and adoption risk. The EVM is the single largest smart-contract developer surface in existence, and every deviation (a nonstandard opcode, account model, or RPC) is a tax on every developer and every tool. Aere's thesis is settlement, not a novel programming model, so the design keeps the tested execution environment intact and adds differentiation only at the EVM's standard extension points. Nothing about Aere's account, passkey, or post-quantum surface depends on a nonstandard EVM.

Alternatives rejected. Designing a new, purpose-built VM (a new bytecode, language, or non-EVM environment) optimized around Aere's differentiators.

Backwards Compatibility

Full EVM compatibility is the point of the decision. Precompiles at previously empty addresses are additive: before activation those addresses were empty accounts, so a call to one returned empty rather than reverting. AIP-7 covers the activation-boundary consequences.

Security Considerations

Some ambitions (base-layer parallel execution, an EVM-in-a-zkVM) must be reached inside the existing model rather than designed in from scratch. Those remain roadmap and are labeled as such wherever they appear. Adding capability at reserved addresses means the address band must be treated as consensus-critical: activating a precompile at an address that historical transactions already called would change their re-execution result, which is why AIP-16 forward-dates its milestone rather than folding into a crossed one.

Reference Implementation and On-Chain Deployment

Chain ID 2800. Live precompiles and their activation block are specified in AIP-7.

Errata

None.

3.2 KiB Raw Permalink Blame History