@ethereumjs/vm v10.1.2

Release round overview

Welcome to 10.1.2 — a coordinated release across all active @ethereumjs/* libraries on the 10.1.x line. If you have been following the upcoming Amsterdam hardfork, this is our first experimental preview ready to try out: a largely complete nine-EIP Hardfork.Amsterdam bundle, currently aligned with tests-bal@v7.1.0 and BAL devnet-7.

Amsterdam is still in flux — please do not use this in production yet — and we expect further 10.1.x releases as the spec and official tests evolve. The sections below cover this package only; for the full fork picture (EIP list, examples, release ↔ spec tracking), see the @ethereumjs/vm Amsterdam overview. On Osaka or earlier hardforks? Nothing changes unless you explicitly select Hardfork.Amsterdam.

@ethereumjs/vm

@ethereumjs/vm is the block-and-transaction execution orchestrator: it wires state, the EVM, consensus checks, and receipts into the high-level APIs most integrators call (runBlock(), runTx(), createVM()). Within the 10.1.2 round, this package carries the bulk of Amsterdam execution logic — BAL builder/validator flows, two-dimensional block gas, and receipt-level fork behaviour — along with spec-alignment fixes and an internal runTx() refactor since 10.1.1.

At a glance

• End-to-end Amsterdam block execution on Hardfork.Amsterdam: nine EIPs active together, matching how execution-spec-tests and devnets exercise the fork.
• EIP-7928 Block Level Access Lists (BAL): generate during runBlock({ generate: true }), validate with RunBlockOpts.blockAccessList, read back via RunBlockResult.blockLevelAccessList.
• EIP-8037 / EIP-7778 two-dimensional block gas and refund-aware header accounting — surfaced on RunTxResult without extra VM flags.
• Passes the v700 mixed EST slice for tests-bal@v7.1.0.

Amsterdam (experimental)

Do not use in production. Spec alignment and public APIs may change in subsequent 10.1.x patch releases.

Spec snapshot	tests-bal@v7.1.0
Testnet	BAL devnet-7
Full overview	Amsterdam hardfork (experimental)

When EIP-7928 is active the VM accumulates state accesses automatically during execution — no separate opt-in flag. For block building, run the block with generate: true and read the BAL from the result; the afterBlock event delivers a block whose header already carries the matching blockAccessListHash. For validation, pass a known BAL (JSON, RLP, or BlockLevelAccessList) via blockAccessList; the VM checks structure and hash before execution and compares against the list produced afterward.

Full walkthrough: packages/vm/examples/runBlockBalGenerate.ts and runBlockBalValidate.ts. The validator example below shows the round-trip pattern:

import { createBlock } from '@ethereumjs/block'
import { Common, Hardfork, Mainnet } from '@ethereumjs/common'
import { createLegacyTx } from '@ethereumjs/tx'
import { Account, createAddressFromPrivateKey, createZeroAddress, hexToBytes } from '@ethereumjs/util'
import { createVM, runBlock } from '@ethereumjs/vm'

const common = new Common({ chain: Mainnet, hardfork: Hardfork.Amsterdam })
const vm = await createVM({ common })
// … fund sender, build block …

const generated = await runBlock(vm, { block, generate: true, skipBlockValidation: true })
const balJson = generated.blockLevelAccessList!.toJSON()

// Validator node: replay with the provided BAL
await runBlock(vm2, { block: sealedBlock, blockAccessList: balJson, skipBlockValidation: true })

Under EIP-8037, each transaction contributes to separate regular and state gas dimensions (RunTxResult.txRegularGas, txStateGas); block header gas used becomes max(block_regular_gas, block_state_gas). Under EIP-7778, RunTxResult.blockGasSpent is what counts toward the header (refunds excluded), while totalGasSpent is what the sender pays. EIP-7708 transfer/burn logs appear in receipts like ordinary logs.

Offline BAL parsing and hash checks live in @ethereumjs/util; opcode-level details in @ethereumjs/evm.

Changes

• EIP-7928 BAL generate/validate integration in runBlock(), see PR #4233, #4264, #4303, #4304, #4306
• EIP-8037 two-dimensional block gas and state-gas reservoir, see PR #4285, #4293, #4301, #4307
• EIP-7976 calldata floor enforcement during block execution, see PR #4280
• EIP-7778 block gas accounting, see PR #4248, #4307
• EIP-7708 / EIP-7843 execution-layer behaviour, see PR #4239, #4263, #4301
• Structural refactor and cleanup of runTx(), see PR #4240
• Execution-spec-tests runner and fixture updates through v7.1.0, see PR #4207, #4298
• Amsterdam documentation and release ↔ spec tracking table, see PR #4308

@ethereumjs/util v10.1.2

Release round overview

Welcome to 10.1.2 — a coordinated release across all active @ethereumjs/* libraries on the 10.1.x line. If you have been following the upcoming Amsterdam hardfork, this is our first experimental preview ready to try out: a largely complete nine-EIP Hardfork.Amsterdam bundle, currently aligned with tests-bal@v7.1.0 and BAL devnet-7.

Amsterdam is still in flux — please do not use this in production yet — and we expect further 10.1.x releases as the spec and official tests evolve. The sections below cover this package only; for the full fork picture (EIP list, examples, release ↔ spec tracking), see the @ethereumjs/vm Amsterdam overview. On Osaka or earlier hardforks? Nothing changes unless you explicitly select Hardfork.Amsterdam.

@ethereumjs/util

@ethereumjs/util is the shared toolbox the whole monorepo builds on — bytes, accounts, addresses, and fork-specific helpers that higher layers import rather than reimplement. Within the 10.1.2 round, the headline addition is a dedicated bal module for working with EIP-7928 Block Level Access Lists outside of live execution: parsing fixtures, validating structure, computing the header hash, and writing test tooling. The VM performs accumulation during runBlock(); Util gives you the portable data model and canonical encoding.

This package also picks up two cross-environment fixes: Account.isEmpty() for partial accounts, and a new isDebugEnabled() helper used across the monorepo for safe DEBUG checks in browsers and Web Workers.

At a glance

• New bal module: BlockLevelAccessList, JSON/RLP factories, validation helpers, and hash() for offline BAL work.
• Fix Account.isEmpty() when called on partial accounts (e.g. state trie reads), see PR #4268.
• Add isDebugEnabled(namespace) — avoids ReferenceError in workers where process is undeclared, see PR #4265.

Amsterdam (experimental)

Behaviour may change in subsequent 10.1.x patch releases.
Spec snapshot: tests-bal@v7.1.0 · Testnet: BAL devnet-7
Fork overview: Amsterdam hardfork (experimental)

Typical Util workflow: ingest a BAL JSON fixture (from a test vector or RPC payload), validate structure and gas-limit footprint, and verify the hash against an expected blockAccessListHash. Example from packages/util/examples/bal.ts:

import {
  bytesToHex,
  createBlockLevelAccessListFromJSON,
  validateBlockAccessListHashFromJSON,
  validateBlockAccessListStructure,
} from '@ethereumjs/util'

const balJson = [
  {
    address: '0x0000000000000000000000000000000000000001',
    storageChanges: [],
    storageReads: [],
    balanceChanges: [{ blockAccessIndex: '0x01', postBalance: '0x03e8' }],
    nonceChanges: [],
    codeChanges: [],
  },
]

const bal = createBlockLevelAccessListFromJSON(balJson)
validateBlockAccessListStructure(bal)
validateBlockAccessListHashFromJSON(balJson, bal.hash())

console.log(`BAL hash: ${bytesToHex(bal.hash())}`)

Key exports include createBlockLevelAccessListFromJSON / FromRLP, validateBlockAccessListStructure, validateBlockAccessListGasLimit, hashBlockAccessListFromJSON, and equalsBlockAccessList. See the Module: bal section in the README for the full at-a-glance map.

Changes

• EIP-7928 BAL types, BlockLevelAccessList, canonical RLP/JSON encoding, and validation utilities, see PR #4233, #4246, #4303, #4306
• README entry section with highlights, at-a-glance table, and grouped module guide, see PR #4308

@ethereumjs/tx v10.1.2

Release round overview

Welcome to 10.1.2 — a coordinated release across all active @ethereumjs/* libraries on the 10.1.x line. If you have been following the upcoming Amsterdam hardfork, this is our first experimental preview ready to try out: a largely complete nine-EIP Hardfork.Amsterdam bundle, currently aligned with tests-bal@v7.1.0 and BAL devnet-7.

Amsterdam is still in flux — please do not use this in production yet — and we expect further 10.1.x releases as the spec and official tests evolve. The sections below cover this package only; for the full fork picture (EIP list, examples, release ↔ spec tracking), see the @ethereumjs/vm Amsterdam overview. On Osaka or earlier hardforks? Nothing changes unless you explicitly select Hardfork.Amsterdam.

@ethereumjs/tx

@ethereumjs/tx defines typed transactions, intrinsic gas calculation, and pre-execution validation — the layer that decides whether a transaction is well-formed and what minimum gas it must carry before the VM ever runs it. Within the 10.1.2 round, Amsterdam adds two floor-pricing EIPs that tighten those minimums and feed directly into EIP-8037 regular-gas accounting downstream.

If you construct or validate transactions for Amsterdam testnets or EST fixtures, these floors are usually why a seemingly small tx suddenly needs a higher gasLimit or a non-zero baseFeePerGas on the containing block.

At a glance

• EIP-7976 — uniform calldata floor: 4 tokens per calldata byte (replacing the zero/non-zero split for floor purposes).
• EIP-7981 — access-list byte floor for typed txs (types 1–4): (20 × addresses + 32 × keys) × 4 tokens per byte.
• Both enforced in getValidationErrors() and intrinsic gas helpers when Hardfork.Amsterdam is active.

Amsterdam (experimental)

Behaviour may change in subsequent 10.1.x patch releases.
Spec snapshot: tests-bal@v7.1.0 · Testnet: BAL devnet-7
Fork overview: Amsterdam hardfork (experimental)

The calldata floor means txRegularGas in the VM becomes (conceptually) max(raw_regular_gas, calldata_floor) under EIP-8037. When writing tests, set baseFeePerGas: 1n on the block header and ensure gasPrice / maxFeePerGas on the tx is high enough to satisfy EIP-1559 checks alongside the new floors:

import { Common, Hardfork, Mainnet } from '@ethereumjs/common'
import { createLegacyTx } from '@ethereumjs/tx'

const common = new Common({ chain: Mainnet, hardfork: Hardfork.Amsterdam })

const tx = createLegacyTx(
  {
    gasLimit: 100_000n,
    gasPrice: 10n,
    data: new Uint8Array(100), // calldata floor scales with byte count
  },
  { common },
)

const errors = tx.getValidationErrors()
// [] when gasLimit covers max(intrinsic, floor)

See the Amsterdam transaction validation section for the full token arithmetic and interaction with EIP-8037.

Changes

• EIP-7976 calldata floor cost, see PR #4280
• EIP-7981 access-list floor cost, see PR #4282

@ethereumjs/statemanager v10.1.2

Release round overview

Welcome to 10.1.2 — a coordinated release across all active @ethereumjs/* libraries on the 10.1.x line. If you have been following the upcoming Amsterdam hardfork, this is our first experimental preview ready to try out: a largely complete nine-EIP Hardfork.Amsterdam bundle, currently aligned with tests-bal@v7.1.0 and BAL devnet-7.

Amsterdam is still in flux — please do not use this in production yet — and we expect further 10.1.x releases as the spec and official tests evolve. The sections below cover this package only; for the full fork picture (EIP list, examples, release ↔ spec tracking), see the @ethereumjs/vm Amsterdam overview. On Osaka or earlier hardforks? Nothing changes unless you explicitly select Hardfork.Amsterdam.

@ethereumjs/statemanager

@ethereumjs/statemanager is the state persistence abstraction the VM uses for account/storage reads and writes — whether backed by an in-memory trie (MerkleStateManager), a cached RPC view, or other implementations. Amsterdam increases how much state metadata is tracked during execution (BAL footprints, state-gas touches), but that tracking happens inside the EVM/VM; the state manager interface itself is unchanged in the 10.1.2 round. Debug logging across packages now uses @ethereumjs/util's isDebugEnabled() internally, see PR #4265.

@ethereumjs/rlp v10.1.2

Release round overview

Welcome to 10.1.2 — a coordinated release across all active @ethereumjs/* libraries on the 10.1.x line. If you have been following the upcoming Amsterdam hardfork, this is our first experimental preview ready to try out: a largely complete nine-EIP Hardfork.Amsterdam bundle, currently aligned with tests-bal@v7.1.0 and BAL devnet-7.

Amsterdam is still in flux — please do not use this in production yet — and we expect further 10.1.x releases as the spec and official tests evolve. The sections below cover this package only; for the full fork picture (EIP list, examples, release ↔ spec tracking), see the @ethereumjs/vm Amsterdam overview. On Osaka or earlier hardforks? Nothing changes unless you explicitly select Hardfork.Amsterdam.

@ethereumjs/rlp

@ethereumjs/rlp is the monorepo's canonical RLP encoder/decoder — a dependency of nearly every other package and often used directly when serializing trie nodes, block bodies, or devp2p payloads. Within the 10.1.2 round this package fixes a decoding edge case in hexToBytes and bumps in version with the rest of the monorepo. There are no Amsterdam-specific API changes here; BAL and block RLP extensions are handled in @ethereumjs/util and @ethereumjs/block.

At a glance

• Fix hexToBytes edge case in RLP decoding paths, see PR #4276.
• Monorepo version sync for @ethereumjs/* 10.1.2.

Amsterdam (experimental)

Amsterdam fork work lives in @ethereumjs/vm and related packages. RLP continues to provide generic encode/decode primitives unchanged.

@ethereumjs/mpt v10.1.2

Release round overview

Welcome to 10.1.2 — a coordinated release across all active @ethereumjs/* libraries on the 10.1.x line. If you have been following the upcoming Amsterdam hardfork, this is our first experimental preview ready to try out: a largely complete nine-EIP Hardfork.Amsterdam bundle, currently aligned with tests-bal@v7.1.0 and BAL devnet-7.

Amsterdam is still in flux — please do not use this in production yet — and we expect further 10.1.x releases as the spec and official tests evolve. The sections below cover this package only; for the full fork picture (EIP list, examples, release ↔ spec tracking), see the @ethereumjs/vm Amsterdam overview. On Osaka or earlier hardforks? Nothing changes unless you explicitly select Hardfork.Amsterdam.

@ethereumjs/mpt

@ethereumjs/mpt implements the Merkle Patricia Trie used by @ethereumjs/statemanager and @ethereumjs/vm for account and storage state. Amsterdam execution touches many more state paths (BAL recording, state-gas accounting), but those semantics live in the EVM/VM layers — within the 10.1.2 round this package is primarily a version sync so consumers can depend on a consistent @ethereumjs/* set when experimenting with Amsterdam.

At a glance

• Monorepo version sync for @ethereumjs/* 10.1.2 — no public API changes.
• Internal MPT class refactor and simplification, see PR #4241.

Amsterdam (experimental)

State reads and writes during Amsterdam block execution flow through the same MPT interface as before. For BAL and state-gas behaviour see @ethereumjs/vm.

@ethereumjs/genesis v10.1.2

Release round overview

Welcome to 10.1.2 — a coordinated release across all active @ethereumjs/* libraries on the 10.1.x line. If you have been following the upcoming Amsterdam hardfork, this is our first experimental preview ready to try out: a largely complete nine-EIP Hardfork.Amsterdam bundle, currently aligned with tests-bal@v7.1.0 and BAL devnet-7.

Amsterdam is still in flux — please do not use this in production yet — and we expect further 10.1.x releases as the spec and official tests evolve. The sections below cover this package only; for the full fork picture (EIP list, examples, release ↔ spec tracking), see the @ethereumjs/vm Amsterdam overview. On Osaka or earlier hardforks? Nothing changes unless you explicitly select Hardfork.Amsterdam.

@ethereumjs/genesis

@ethereumjs/genesis provides genesis-state helpers and JSON genesis parsing used when bootstrapping chains and test environments. Amsterdam does not introduce new genesis formats in the 10.1.2 round; this package bumps in version only to stay aligned with the monorepo. If you spin up an Amsterdam test environment, you will typically set hardfork: Hardfork.Amsterdam on your Common at runtime rather than changing genesis handling here.

@ethereumjs/evm v10.1.2

Release round overview

Welcome to 10.1.2 — a coordinated release across all active @ethereumjs/* libraries on the 10.1.x line. If you have been following the upcoming Amsterdam hardfork, this is our first experimental preview ready to try out: a largely complete nine-EIP Hardfork.Amsterdam bundle, currently aligned with tests-bal@v7.1.0 and BAL devnet-7.

Amsterdam is still in flux — please do not use this in production yet — and we expect further 10.1.x releases as the spec and official tests evolve. The sections below cover this package only; for the full fork picture (EIP list, examples, release ↔ spec tracking), see the @ethereumjs/vm Amsterdam overview. On Osaka or earlier hardforks? Nothing changes unless you explicitly select Hardfork.Amsterdam.

@ethereumjs/evm

@ethereumjs/evm is the low-level EVM interpreter: opcodes, precompiles, gas metering, and message-call semantics. Within the 10.1.2 round, Amsterdam changes land here first — new instructions, revised size limits, state-gas accounting inside the interpreter, and BAL footprint recording on evm.blockLevelAccessList. The VM wraps these details into runBlock() / runTx(); use the EVM directly when building tracers, custom runners, or runCall()-style tools.

At a glance

• EIP-8024 stack opcodes DUPN, SWAPN, EXCHANGE with immediate validation at decode time.
• EIP-7954 raised max contract code and initcode size (via common.param('maxCodeSize')).
• EIP-8037 state-gas reservoir on the EVM instance — state-touching ops draw from evm.stateGasReservoir before spilling into regular gas.
• EIP-7708 synthetic Transfer / Burn logs on value-moving paths; EIP-7843 SLOTNUM opcode.
• EIP-7928 automatic state-access recording on evm.blockLevelAccessList when active.
• Custom precompile API improvements (PrefixedHexString, getPrecompile, exported types), see PR #4261.

Amsterdam (experimental)

Behaviour may change in subsequent 10.1.x patch releases.
Spec snapshot: tests-bal@v7.1.0 · Testnet: BAL devnet-7
Fork overview: Amsterdam hardfork (experimental)

EIP-8024 adds three stack-manipulation opcodes, each with a single-byte immediate (validated at decode — invalid immediates trap):

import { EVM } from '@ethereumjs/evm'
import { Common, Hardfork, Mainnet } from '@ethereumjs/common'

const common = new Common({ chain: Mainnet, hardfork: Hardfork.Amsterdam })
const evm = await EVM.create({ common })

// DUPN/SWAPN/EXCHANGE behave like extended DUP/SWAP variants;
// gas: dupnGas / swapnGas / exchangeGas (default 3 each)

When EIP-7928 is active, every state-touching operation appends to evm.blockLevelAccessList during runCall() / internal message execution. The VM reads this object after each transaction to build the block-level list. For BAL builder/validator flows see @ethereumjs/vm.

Further Amsterdam notes: EIP-8024, EIP-7954, EIP-8037 / EIP-7708.

Changes

• EIP-8024 stack opcodes, see PR #4248, #4302
• EIP-7954 max contract and initcode size, see PR #4299
• EIP-8037 state-gas accounting and reservoir logic, see PR #4285, #4293, #4301, #4304
• EIP-7708 / EIP-7843 execution changes, see PR #4239, #4251, #4263, #4301
• EIP-7928 BAL accumulation during message execution, see PR #4233, #4304

@ethereumjs/common v10.1.2

Release round overview

Welcome to 10.1.2 — a coordinated release across all active @ethereumjs/* libraries on the 10.1.x line. If you have been following the upcoming Amsterdam hardfork, this is our first experimental preview ready to try out: a largely complete nine-EIP Hardfork.Amsterdam bundle, currently aligned with tests-bal@v7.1.0 and BAL devnet-7.

Amsterdam is still in flux — please do not use this in production yet — and we expect further 10.1.x releases as the spec and official tests evolve. The sections below cover this package only; for the full fork picture (EIP list, examples, release ↔ spec tracking), see the @ethereumjs/vm Amsterdam overview. On Osaka or earlier hardforks? Nothing changes unless you explicitly select Hardfork.Amsterdam.

@ethereumjs/common

@ethereumjs/common is the fork and parameter engine: it answers “which EIPs are active?”, “what is maxCodeSize?”, and “what gas schedule applies?” for every other library. Within the 10.1.2 round, Amsterdam lands here as a new Hardfork.Amsterdam entry that activates the full nine-EIP bundle together — the same bundling execution-spec-tests and devnets use, so you should not cherry-pick individual Amsterdam EIPs in isolation when reproducing fixtures.

For integrators, the practical effect is a single switch: construct your Common with hardfork: Hardfork.Amsterdam and all downstream packages (@ethereumjs/evm, @ethereumjs/vm, @ethereumjs/tx, …) inherit consistent activation and parameter values.

At a glance

• Add experimental Hardfork.Amsterdam with EIPs 7708, 7843, 7778, 7928, 7954, 7976, 7981, 8024, and 8037.
• Updated gasPrices, gasConfig, and vm parameters for Amsterdam (7954 size limits, 7976/7981 floor pricing constants, 8037 state-gas dimensions, …).

Amsterdam (experimental)

Behaviour may change in subsequent 10.1.x patch releases.
Spec snapshot: tests-bal@v7.1.0 · Testnet: BAL devnet-7
Execution details: Amsterdam hardfork (experimental)

import { Common, Hardfork, Mainnet } from '@ethereumjs/common'

const common = new Common({ chain: Mainnet, hardfork: Hardfork.Amsterdam })

// Amsterdam raises max code / initcode size (EIP-7954)
common.param('maxCodeSize') // 51200 (vs 24576 pre-Amsterdam)

// EIP active checks drive behaviour in EVM, VM, Tx, Block
common.isActivatedEIP(7928) // true — BAL accumulation in VM/EVM
common.isActivatedEIP(8037) // true — two-dimensional block gas

The Supported EIPs section lists every Amsterdam EIP with links to the package that implements execution semantics.

Changes

• Amsterdam hardfork definition and EIP activations, see PR #4239, #4248, #4280, #4282, #4285, #4299
• Supported EIP list and Amsterdam documentation cross-links, see PR #4308

@ethereumjs/blockchain v10.1.2

Release round overview

Welcome to 10.1.2 — a coordinated release across all active @ethereumjs/* libraries on the 10.1.x line. If you have been following the upcoming Amsterdam hardfork, this is our first experimental preview ready to try out: a largely complete nine-EIP Hardfork.Amsterdam bundle, currently aligned with tests-bal@v7.1.0 and BAL devnet-7.

Amsterdam is still in flux — please do not use this in production yet — and we expect further 10.1.x releases as the spec and official tests evolve. The sections below cover this package only; for the full fork picture (EIP list, examples, release ↔ spec tracking), see the @ethereumjs/vm Amsterdam overview. On Osaka or earlier hardforks? Nothing changes unless you explicitly select Hardfork.Amsterdam.

@ethereumjs/blockchain

@ethereumjs/blockchain implements a minimal chain backend (block insertion, validation hooks, reorg handling) on top of @ethereumjs/block and @ethereumjs/mpt. It is not on the hot path for Amsterdam EST testing — most integrators exercise Amsterdam via @ethereumjs/vm directly — but within the 10.1.2 round this package stays aligned with the dependency set so full-stack setups do not hit version skew. No package-specific API or consensus changes.