lfglabs-dev · Th0rgal · Aug 6, 2026 · Aug 6, 2026 · Aug 6, 2026 · Aug 6, 2026
diff --git a/EIPS/eip-1.md b/EIPS/eip-1.md
@@ -218,6 +218,24 @@ Permitted Execution Client Specifications URLs must anchor to a specific commit,
 
 The Ethereum Execution Client Specifications repository also contains the Ethereum Execution Specification Tests, under its `tests/` directory. Links to specific commits of those test files are permitted under the same rule.
 
+### Ethereum System Contract Implementations
+
+Links to the Ethereum System Contract Implementations repository may be included using normal markdown syntax, such as:
+
+```markdown
+[Ethereum System Contract Implementations](https://github.com/ethereum/sys-asm/blob/83f9801245ff56878a450b5625801101b9a225a1/README.md)
+```
+
+Which renders to:
+
+[Ethereum System Contract Implementations](https://github.com/ethereum/sys-asm/blob/83f9801245ff56878a450b5625801101b9a225a1/README.md)
+
+Permitted URLs must anchor to a specific commit, and so must match this regular expression:
+
+```regex
+^(https://github.com/ethereum/sys-asm/(blob|commit)/[0-9a-f]{40}/.*|https://github.com/ethereum/sys-asm/tree/[0-9a-f]{40}/.*)$
+```
+
 ### Consensus Layer Specifications
 
 Links to specific commits of files within the Ethereum Consensus Layer Specifications may be included using normal markdown syntax, such as:

diff --git a/EIPS/eip-7666.md b/EIPS/eip-7666.md
@@ -2,12 +2,13 @@
 eip: 7666
 title: EVM-ify the identity precompile
 description: Remove the identity precompile, and put into place a piece of EVM code that has equivalent functionality
-author: Vitalik Buterin (@vbuterin)
+author: Vitalik Buterin (@vbuterin), Kevaundray Wedderburn (@kevaundray)
 discussions-to: https://ethereum-magicians.org/t/eip-7561-evm-ify-the-identity-precompile/19445
-status: Stagnant
+status: Draft
 type: Standards Track
 category: Core
 created: 2024-03-31
+requires: 3855
 ---
 
 ## Abstract

diff --git a/EIPS/eip-7709.md b/EIPS/eip-7709.md
@@ -1,10 +1,10 @@
 ---
 eip: 7709
-title: Read BLOCKHASH from storage and update cost
+title: Read BLOCKHASH from Storage and Update Cost
 description: Read the `BLOCKHASH (0x40)` opcode from the EIP-2935 system contract storage and adjust its gas cost to reflect storage access.
 author: Vitalik Buterin (@vbuterin), Tomasz Stanczak (@tkstanczak), Guillaume Ballet (@gballet), Gajinder Singh (@g11tech), Tanishq Jasoria (@tanishqjasoria), Ignacio Hagopian (@jsign), Jochem Brouwer (@jochem-brouwer), Gabriel Rocheleau (@gabrocheleau)
 discussions-to: https://ethereum-magicians.org/t/eip-7709-read-blockhash-opcode-from-storage-and-adjust-gas-cost/20052
-status: Stagnant
+status: Draft
 type: Standards Track
 category: Core
 created: 2024-05-18
@@ -17,80 +17,89 @@ Update the `BLOCKHASH (0x40)` opcode to read and serve from the system contract
 
 ## Motivation
 
-The `BLOCKHASH (0x40)` opcode currently assumes that the client has knowledge of the previous blocks, which in Verkle [EIP-6800](./eip-6800.md) would prevent stateless execution. However with [EIP-2935](./eip-2935.md) blockhashes can be retrieved and served from its system contract storage which allows Verkle blocks to include a storage access witness for stateless execution.
+The `BLOCKHASH (0x40)` opcode currently assumes that the client has access to recent block history. This makes it a protocol special case: it depends on historical chain data, but it is not modeled like other state-backed reads.
+
+With [EIP-2935](./eip-2935.md), recent block hashes are stored in the system contract storage. This allows in-window `BLOCKHASH` lookups to be modeled as storage-backed accesses while preserving the existing `BLOCKHASH` return-value semantics.
 
 ## Specification
 
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) and [RFC 8174](https://www.rfc-editor.org/rfc/rfc8174).
+
 | Parameter                 | Value  |
 | ------------------------- | ------ |
 | `FORK_TIMESTAMP`          | TBD    |
 | `HISTORY_STORAGE_ADDRESS` | `0x0000F90827F1C53a10cb7A02335B175320002935` |
 | `BLOCKHASH_SERVE_WINDOW`  | `256`  |
+| `HISTORY_SERVE_WINDOW`    | `8191` |
 
 The `BLOCKHASH` opcode semantics remains the same as before. From the `fork_block` (defined as `fork_block.timestamp >= FORK_TIMESTAMP and fork_block.parent.timestamp < FORK_TIMESTAMP`), the `BLOCKHASH` instruction should be updated to resolve block hash in the following manner:
 
 ```python
 def resolve_blockhash(block: Block, state: State, arg: uint64):
   # note that outside the BLOCKHASH_SERVE_WINDOW we continue to return 0
   # despite the 2935 history contract being able to serve more hashes
-  if arg >= block.number or (arg + BLOCKHASH_SERVE_WINDOW) < block.number
+  if arg >= block.number or (arg + BLOCKHASH_SERVE_WINDOW) < block.number:
     return 0
 
   # performs an sload on arg % HISTORY_SERVE_WINDOW including gas charges,
-  # warming effects as well as execution accesses
+  # warming effects as well as state-access recording
   #
   # note that the `BLOCKHASH_SERVE_WINDOW` and the 2935 ring buffer window
   # `HISTORY_SERVE_WINDOW` for slot calculation are different
   return state.load_slot(HISTORY_STORAGE_ADDRESS, arg % HISTORY_SERVE_WINDOW)
 ```
 
-ONLY if the `arg` is within the correct `BLOCKHASH` window, clients can choose to either
+If the `arg` is within the correct `BLOCKHASH` window, clients MAY choose to either
 
 * do a direct `SLOAD` from state, or
 * do a system call to [EIP-2935](./eip-2935.md) contract via its `get` mechanism (caller other than `SYSTEM_ADDRESS`) or
 * serve from memory or as per current designs if maintaining requisite history (full clients for e.g.)
 
-However the entire semantics and after effects of the `SLOAD` operation needs to be applied as per the current fork if the `arg` is within the correct `BLOCKHASH` window:
+Regardless of the chosen resolution method, clients MUST apply the entire semantics and effects of the `SLOAD` operation as defined by the active fork if the `arg` is within the correct `BLOCKHASH` window:
 
 * `SLOAD` gas costs (cold or warm) for the `arg % HISTORY_SERVE_WINDOW` slot.
 * `SLOAD` after effects on the slot (warming the slot)
-* `SLOAD` accesses added to execution witnesses if Verkle ([EIP-6800](./eip-6800.md) and [EIP-4762](./eip-4762.md)) is activated
+* Any state-access recording required by the active fork for the corresponding `SLOAD`.
 
 ### Activation
 
 This EIP specifies the transition to the new logic assuming that [EIP-2935](./eip-2935.md) has been activated:
 
 * sufficiently ahead of this EIP's activation (>= `BLOCKHASH_SERVE_WINDOW`) or
-* at genesis for testnets/devnets where this EIP could also be activated at genesis
-
-The current proposal is to activate this EIP with Verkle to allow for stateless execution of the block.
+* at genesis for testnets/devnets where this EIP could also be activated at genesis.
 
 ### Gas costs
 
 As described above, if the `arg` to be resolved is within the correct window, the corresponding `SLOAD` charges and accesses are to be applied for the slot `arg % HISTORY_SERVE_WINDOW`. Note that the `HISTORY_SERVE_WINDOW` and `BLOCKHASH_SERVE_WINDOW` are different.
 
 ### Reading from the System contract
 
-Even if the clients choose to resolve `BLOCKHASH` through system call to [EIP-2935](./eip-2935.md) contract, the gas cost for the system code execution (and also the code witnesses if Verkle activated) is not applied. Only the effect of `SLOAD` is applied as described above.
+Even if the clients choose to resolve `BLOCKHASH` through system call to [EIP-2935](./eip-2935.md) contract, the gas cost for the system code execution is not applied. Only the effect of `SLOAD` is applied as described above.
 
 ## Rationale
 
-* The reason behind the updated gas cost is to match the real operation, which is equivalent to an `SLOAD`.
-* The [EIP-2935](./eip-2935.md) system contract execution charges (and accesses) are not applied to keep the gas low and to keep things simple for clients which choose to resolve `BLOCKHASH` in other ways (directly or though memory/maintained history)
+* The updated gas cost matches the accessed resource, which is equivalent to reading from storage.
+* Charging normal `SLOAD`-like cold and warm costs keeps `BLOCKHASH` aligned with existing state-access pricing instead of adding a separate gas rule for recent block hashes.
+* A client can alternatively prove recent block hashes through a chain of parent headers, but that keeps `BLOCKHASH` as a special case in witness construction rather than using the state access machinery provided by [EIP-2935](./eip-2935.md).
+* Always charging the warm `SLOAD` cost, or introducing a custom `BLOCKHASH` price, could reduce compatibility risk but would introduce a new special-case gas rule.
+* The [EIP-2935](./eip-2935.md) system contract execution charges and accesses are not applied to keep the gas low and to keep things simple for clients which choose to resolve `BLOCKHASH` in other ways (directly or through memory/maintained history).
 
-Note that `BLOCKHASH` opcode only serves a limited `BLOCKHASH_SERVE_WINDOW` to be backward compatible (and to not extend the above exemptions). For deeper accesses one will need to directly call [EIP-2935](./eip-2935.md) system contract which will lead to a normal contract execution (as well as charges and accesses)
+Note that `BLOCKHASH` opcode only serves a limited `BLOCKHASH_SERVE_WINDOW` to be backward compatible (and to not extend the above exemptions). For deeper accesses one will need to directly call [EIP-2935](./eip-2935.md) system contract which will lead to a normal contract execution (as well as charges and accesses).
 
 ## Backwards Compatibility
 
-This EIP introduces a significant increase in the cost of `BLOCKHASH`, which could break use-cases that rely on the previous gas cost. Also, this EIP introduces a breaking change in the case where less than `BLOCKHASH_SERVE_WINDOW` elapse between the [EIP-2935](./eip-2935.md) fork and this EIP's fork (unless [EIP-2935](./eip-2935.md)  is activated in genesis for e.g. in testnets/devnets) as the [EIP-2935](./eip-2935.md) system contract would not have saved the required history.
+This EIP does not change the return-value semantics of `BLOCKHASH`.
+
+This EIP introduces a significant increase in the cost of in-window `BLOCKHASH` queries, which could break use-cases that rely on the previous gas cost. Also, this EIP introduces a breaking change in the case where less than `BLOCKHASH_SERVE_WINDOW` elapse between the [EIP-2935](./eip-2935.md) fork and this EIP's fork (unless [EIP-2935](./eip-2935.md) is activated in genesis for e.g. in testnets/devnets) as the [EIP-2935](./eip-2935.md) system contract would not have saved the required history.
 
 ## Test Cases
 
-* If `BLOCKHASH` is not called or there is no [EIP-2935](./eip-2935.md) contract call by any transaction, only the [EIP-2935](./eip-2935.md) system update of the parent hash shows up in witnesses if Verkle is activated.
-* If `BLOCKHASH` is called, there MUST be a storage access gas charge (and corresponding access witness if Verkle is activated) for the storage slot but ONLY if the `BLOCKHASH` query is for the last `BLOCKHASH_SERVE_WINDOW` ancestors. This is irrespective of how the client chooses to resolve the `BLOCKHASH` (directly, via system contract or via memory)
-* The gas cost for each `BLOCKHASH` operation should still be charged, in addition to the `SLOAD` cost of each lookup (if performed)
-* If the [EIP-2935](./eip-2935.md) contract is called directly (i.e. not through `BLOCKHASH`), then the witness and gas costs (including those related to contract code) are applied as per normal contract execution of the current fork.
-* `BLOCKHASH` should be consistently resolved if this EIP is activated correctly `>= BLOCKHASH_SERVE_WINDOW` after [EIP-2935](./eip-2935.md)
+* If `BLOCKHASH` is called with an argument outside the last `BLOCKHASH_SERVE_WINDOW` ancestors, or with an argument greater than or equal to the current block number, it returns `0` without applying additional storage access effects.
+* If `BLOCKHASH` is called for an in-window ancestor and the corresponding storage slot is cold, the opcode charges the base `BLOCKHASH` cost plus the cold `SLOAD` cost.
+* If `BLOCKHASH` is called more than once in the same transaction for a block number that maps to the same storage slot, the later lookup charges the warm `SLOAD` cost.
+* The gas cost for each `BLOCKHASH` operation should still be charged, in addition to the `SLOAD` cost of each lookup (if performed).
+* If the [EIP-2935](./eip-2935.md) contract is called directly (i.e. not through `BLOCKHASH`), then the gas costs, state-access recording, and any other effects are applied as per normal contract execution of the current fork.
+* `BLOCKHASH` should be consistently resolved if this EIP is activated correctly `>= BLOCKHASH_SERVE_WINDOW` after [EIP-2935](./eip-2935.md).
 
 ## Security Considerations
 

diff --git a/EIPS/eip-7773.md b/EIPS/eip-7773.md
@@ -20,6 +20,9 @@ Definitions for `Scheduled for Inclusion`, `Considered for Inclusion`, `Declined
 
 ### EIPs Scheduled for Inclusion
 
+* [EIP-2780](./eip-2780.md): Reduce intrinsic transaction gas
+* [EIP-7610](./eip-7610.md): Revert creation in case of non-empty storage
+* [EIP-7688](./eip-7688.md): Forward compatible consensus data structures
 * [EIP-7708](./eip-7708.md): ETH transfers emit a log
 * [EIP-7732](./eip-7732.md): Enshrined Proposer-Builder Separation
 * [EIP-7778](./eip-7778.md): Block Gas Accounting without Refunds
@@ -28,12 +31,9 @@ Definitions for `Scheduled for Inclusion`, `Considered for Inclusion`, `Declined
 * [EIP-7954](./eip-7954.md): Increase Maximum Contract Size
 * [EIP-7976](./eip-7976.md): Increase Calldata Floor Cost
 * [EIP-7981](./eip-7981.md): Increase Access List Cost
+* [EIP-7997](./eip-7997.md): Deterministic Factory Predeploy
 * [EIP-8024](./eip-8024.md): Backward compatible SWAPN, DUPN, EXCHANGE
 * [EIP-8037](./eip-8037.md): State Creation Gas Cost Increase
-* [EIP-2780](./eip-2780.md): Reduce intrinsic transaction gas
-* [EIP-7610](./eip-7610.md): Revert creation in case of non-empty storage
-* [EIP-7688](./eip-7688.md): Forward compatible consensus data structures
-* [EIP-7997](./eip-7997.md): Deterministic Factory Predeploy
 * [EIP-8038](./eip-8038.md): State-access gas cost increase
 * [EIP-8045](./eip-8045.md): Exclude slashed validators from proposing
 * [EIP-8061](./eip-8061.md): Increase exit and consolidation churn
@@ -53,10 +53,11 @@ Definitions for `Scheduled for Inclusion`, `Considered for Inclusion`, `Declined
 #### Informational EIP
 
 * [EIP-7904](./eip-7904.md): Compute Gas Cost Analysis
+* [EIP-8261](./eip-8261.md): Gas Limit Schedule
 
 ### Declined for Inclusion
 
-* [EIP-2926](./eip-2926.md): Chunk-based code merkelization
+* [EIP-2926](./eip-2926.md): Chunk-Based Code Merkleization
 * [EIP-5920](./eip-5920.md): PAY opcode
 * [EIP-6404](./eip-6404.md): SSZ transactions
 * [EIP-6466](./eip-6466.md): SSZ receipts
@@ -98,6 +99,10 @@ Definitions for `Scheduled for Inclusion`, `Considered for Inclusion`, `Declined
 * [EIP-8080](./eip-8080.md): Let exits use the consolidation queue
 * [EIP-8254](./eip-8254.md): Cap Deposit Requests Per Block
 
+### Mascot
+
+Polar bear 🐻‍❄️ is the mascot for the Glamsterdam network upgrade, as per the [EIP-8066](./eip-8066.md) process.
+
 ### Activation
 
 | Network Name | Activation Epoch | Activation Timestamp |

diff --git a/EIPS/eip-7906.md b/EIPS/eip-7906.md
@@ -2,7 +2,7 @@
 eip: 7906
 title: Transaction Assertions via State Diff Opcode
 description: An opcode that provides a mechanism to restrict the outcomes of transaction execution
-author: Alex Forshtat (@forshtat), Shahaf Nacson (@shahafn), Dror Tirosh (@drortirosh), Yoav Weiss (@yoavw), Fredrik Svantes (@fredrik0x)
+author: Alex Forshtat (@forshtat), Shahaf Nacson (@shahafn), Dror Tirosh (@drortirosh), Yoav Weiss (@yoavw), Fredrik Svantes (@0xfredrik)
 discussions-to: https://ethereum-magicians.org/t/eip-restricted-behavior-transaction-type/23130
 status: Draft
 type: Standards Track
@@ -77,9 +77,9 @@ The available parameters are listed in the table below.
 | 0x0D    | index in `events_count`       | `events_address` - the address of the contract that emitted the event         |
 | 0x0E    | index in `events_count`       | `event_topic_count` - the number of topics of the event (0–4)                 |
 | 0x0F    | index in `events_count`       | `event_topic0` - the first topic of the event; exceptional halt if no topic   |
-| 0x10    | index in `events_count`       | `event_topic1` - the second topic of the event                                |
-| 0x11    | index in `events_count`       | `event_topic2` - the third topic of the event                                 |
-| 0x12    | index in `events_count`       | `event_topic3` - the fourth topic of the event                                |
+| 0x10    | index in `events_count`       | `event_topic1` - the second topic of the event; exceptional halt if no such topic |
+| 0x11    | index in `events_count`       | `event_topic2` - the third topic of the event; exceptional halt if no such topic  |
+| 0x12    | index in `events_count`       | `event_topic3` - the fourth topic of the event; exceptional halt if no such topic |
 | 0x13    | index in `events_count`       | `event_data_len` - the byte length of the event's non-indexed data            |
 | 0x14    | must be 0                     | `gas_pre_charge` - the total amount deducted from the gas payer               |
 | 0x15    | must be 0                     | `gas_payer_address` - the address charged the gas pre-charge                  |
@@ -97,6 +97,8 @@ The `before` values reflect the transaction prestate values recorded before the
 
 An address will appear in `balances_changed` when its balance at the time of the `TXTRACE` call differs from its balance at transaction start. This includes the gas fee pre-charge applied to the gas payer address. Callers computing the net ETH transferred to or from an address can look up the gas payer via `gas_payer_address` (param `0x15`) and subtract `gas_pre_charge` (param `0x14`) from that address's balance delta.
 
+An address appears in `contracts_deployed` when its code hash changed during the transaction from the empty-code hash to a non-empty code hash that is not an [EIP-7702](./eip-7702.md) delegation designator. An account that a `CREATE`/`CREATE2` leaves with empty code is not enumerated, as it has no code change.
+
 ### Transaction Diff Lookup Opcode
 
 While `TXTRACE` enumerates the full state diff, it has no mechanism to directly query the diff for one specific account's balance, codehash, or storage slot.
@@ -159,10 +161,14 @@ The actual nonce value is not observable through `TXTRACE` or `TXDIFF`.
 - Balance and codehash params (`0x02`–`0x05`): `COLD_ACCOUNT_ACCESS_COST` (2600) if the address is not in the accessed addresses set; `WARM_STORAGE_READ_COST` (100) otherwise.
 - Per-address view and flags params (`0x06`–`0x0A`): a flat cost of `TXTRACE_GAS_COST`. These params are answered entirely from the transaction-local state diff and never read the live state.
 
-For params `0x00`–`0x05`, the accessed slot or address is added to the respective access list after the call. Params `0x06`–`0x0A` do not interact with the [EIP-2929](./eip-2929.md) access lists.
+For params `0x00`–`0x05`, the accessed slot or address is added to the [EIP-2929](./eip-2929.md) access list after the call, and — where [EIP-7928](./eip-7928.md) is active — recorded in the block-level access list, like any other state-reading opcode. `TXTRACE` and `EVENTDATACOPY` read only already-recorded diff and log data and therefore add no new accesses. Params `0x06`–`0x0A` do not interact with the [EIP-2929](./eip-2929.md) access lists.
 
 `codehash_before` is equal to the empty-code hash for undeployed contracts.
 
+### Reserved Inputs
+
+Any `in2`/`in3` operand marked *must be 0* in the parameter tables above MUST be zero; supplying a non-zero value causes an exceptional halt.
+
 ### Results Ordering
 
 Balance and storage slot changes returned by the `TXTRACE` opcode are enumerated in ascending order sorted by the affected address as a numerical `uint160` value.