The Ethereum Yellow Paper — formally titled Ethereum: A Secure Decentralised Generalised Transaction Ledger and written by Gavin Wood in 2014 — is the mathematical specification document that precisely defines Ethereum’s execution semantics, providing the formal definitions of the Ethereum Virtual Machine’s instruction set, gas cost schedule, account structure, state transition function, and transaction validity rules that all conforming Ethereum node implementations must satisfy, serving as the technical ground truth that the more accessible Ethereum whitepaper deliberately deferred to.
Overview
Vitalik Buterin’s Ethereum whitepaper (2013) was a concept paper aimed at developers and the broader crypto community. It deliberately avoided formal notation in favor of accessibility. Gavin Wood, who joined the Ethereum project as CTO, wrote the Yellow Paper to fill the gap — providing the unambiguous mathematical specification required to implement an Ethereum node correctly.
The name “Yellow Paper” follows a convention in computer science where conceptual overview documents are “white papers” and their formal technical encoding are variously colored papers. Wood chose yellow (the Ethereum documentation color scheme) for the formal spec.
The Yellow Paper remains the authoritative technical reference for:
- EVM bytecode semantics
- Cryptographic operations (Keccak-256, ECDSA signature verification)
- State trie structure (Merkle Patricia Trie)
- Block, uncle, and transaction validation rules
- Gas pricing for computation and memory
Key Contributions
1. Formal EVM Specification
The Yellow Paper defines the EVM as a deterministic computation machine using:
- Stack architecture — 256-bit word stack with up to 1024 elements.
- Memory — Byte-array memory that expands as needed (with gas costs).
- Storage — Per-account 256-bit key/value store, persistent across transactions.
- Program counter — Index into the bytecode sequence.
- Available gas — Decremented for each operation; transaction reverts if exhausted.
Every EVM opcode is formally defined: its stack inputs, outputs, gas cost, and exceptional conditions. This enables independent implementations (Geth in Go, Erigon in Go, Besu in Java, Nethermind in C#, Reth in Rust) to achieve identical results from identical inputs.
2. Gas Cost Schedule
Wood formally defines gas costs for every EVM operation. The costs were set to reflect:
- Computational cost — CPU operations required.
- Memory cost — Growing memory incurs escalating gas costs (quadratic above a threshold).
- Storage cost — Modifying persistent storage (SSTORE) is significantly more expensive than in-memory operations, reflecting the permanent cost imposed on all future nodes.
The gas schedule has been updated through subsequent EIPs (Ethereum Improvement Proposals), but Wood’s original schedule in the Yellow Paper established the conceptual framework.
3. State Transition Function
The Yellow Paper defines the global state transition function ψ: given a valid world state σ and a transaction T, produce a new world state σ’. This is the core operation of Ethereum — every block applies a sequence of transactions through this function, each modifying account balances, storage, and nonces.
4. Merkle Patricia Trie
The Yellow Paper specifies the Merkle Patricia Trie — the data structure Ethereum uses to encode its world state, transaction list, transaction receipts, and storage. This structure allows:
- Efficient proofs — A Merkle root (32 bytes) commits to all state. Proofs that a specific account has a specific balance are logarithmic in size.
- SPV compatibility — Light clients can verify specific state without downloading the whole tree.
5. Mining Algorithm (Ethash)
The original Yellow Paper included specification of Ethereum’s PoW algorithm (Ethash, later Dagger-Hashimoto), designed to be ASIC-resistant by requiring large amounts of memory for mining. This was rendered historical by The Merge (September 2022), which transitioned Ethereum to Proof of Stake.
Authors
Gavin Wood joined Ethereum as CTO in early 2014 after seeing the Ethereum whitepaper. He wrote the Yellow Paper, implemented the first working version of Ethereum in C++ (cpp-ethereum), designed the Solidity programming language concept, and co-founded Ethereum before departing in 2016 to found Parity Technologies (now Parity) and thereafter the Web3 Foundation and Polkadot.
Historical Context
- January 2014 — Ethereum publicly announced; Wood joins as CTO.
- April 2014 — Yellow Paper first published.
- July 30, 2015 — Ethereum Frontier mainnet launches, implementing the Yellow Paper specification.
- 2016–2022 — Yellow Paper updated periodically through hard fork EIPs (Constantinople, Istanbul, London/EIP-1559, etc.).
- September 15, 2022 — The Merge; Ethereum transitions to PoS. The Yellow Paper’s PoW sections become historical.
Relation to Other Ethereum Documentation
| Document | Author | Purpose |
|---|---|---|
| Ethereum Whitepaper | Vitalik Buterin | Conceptual overview and motivation |
| Ethereum Yellow Paper | Gavin Wood | Formal mathematical specification |
| Execution Specs (EELS) | Ethereum Foundation | Python executable specification (modern complement) |
| EIPs (Ethereum Improvement Proposals) | Various | Protocol upgrade proposals and specifications |
Common Misconceptions
- “The Yellow Paper and Whitepaper say the same things.” — The whitepaper is conceptual and accessible. The Yellow Paper is a dense formal document using mathematical notation, intended for node implementers rather than general readers. They are complementary, not redundant.
- “The Yellow Paper was written by Vitalik Buterin.” — It was written entirely by Gavin Wood. Buterin’s whitepaper and Wood’s Yellow Paper are separate documents by separate authors.
- “The Yellow Paper is deprecated.” — It remains the primary formal specification for the Ethereum execution layer. The Ethereum Foundation’s EELS (Ethereum Execution Layer Spec) Python repo is a modern executable complement, but the Yellow Paper has not been formally retired.
Last updated: 2026-04