Ethereum Improvement Proposals - Meta

Hardfork Meta - BPO1

2026-01-24T00:00:00+00:00

Abstract</h2>
This Meta EIP documents the activation details, parameter changes, and specification references for the first Blob-Parameter-Only (BPO) network upgrades, BPO1. It provides a canonical registry of blob targets, blob maximum limits, and associated configuration values to improve transparency, traceability, and ecosystem coordination for early-stage data availability scaling under Ethereum’s Surge roadmap.</p>

Motivation</h2>
Blob-Parameter-Only (BPO) upgrades enable Ethereum to scale data availability through incremental parameter adjustments rather than large multi-feature network upgrades. While this approach improves safety and iteration speed, there is currently no canonical reference documenting what changed in each BPO upgrade, when it was activated, and which parameter values were applied.</p>
EIP-7892</a> specifies the mechanism and constraints for BPO upgrades but does not track individual BPO instances. In practice, activation timing and parameter values for BPO1 are distributed across client repositories, coordination notes, and operational artifacts, making consistent interpretation and historical analysis difficult for ecosystem participants.</p>
This EIP addresses this gap by recording authoritative data for BPO1 in a canonical reference to improve transparency, traceability, and ecosystem coordination.</p>

Specification</h2>
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</a> and RFC 8174</a>.</p>
This section documents the Blob-Parameter-Only upgrade identified as BPO1</strong>.</p>
The upgrade modifies blob-related protocol parameters as defined in EIP-7892</a>. No other protocol behavior is affected. All timestamps are expressed as Unix epoch seconds (UTC).</p>

BPO-1 Parameters</h3>
Field</th> Value</th></tr></thead>

BPO Identifier</td> BPO1</td></tr>
Activation Time (UTC)</td> 1765290071</td></tr>
Blob Target</td> 10</td></tr>
Blob Max</td> 15</td></tr>
Base Fee Update Fraction</td> 8,346,193</td></tr> </tbody></table>
BPO-1 represents the first mainnet deployment of a Blob-Parameter-Only upgrade and establishes the initial incremental increase in blob capacity following the Fusaka upgrade.</p>
Historical Context</h3>
For reference, the blob schedule before BPO upgrades was established in earlier network upgrades:</p>
Upgrade</th> Blob Target</th> Blob Max</th> Base Fee Update Fraction</th></tr></thead>

Cancun</strong></td> 3</td> 6</td> 3,338,477</td></tr>
Prague</strong></td> 6</td> 9</td> 5,007,716</td></tr> </tbody></table>
Data Source</h3>
The parameter values and activation times in this EIP are derived from eth_client genesis configuration, including:</p>
"</span>bpo1Time</span>"</span>: </span>1765290071</span>,</span></span> "</span>blobSchedule</span>"</span>: </span>{</span></span> "</span>cancun</span>"</span>:</span> {</span></span> "</span>target</span>"</span>:</span> 3</span>,</span></span> "</span>max</span>"</span>:</span> 6</span>,</span></span> "</span>baseFeeUpdateFraction</span>"</span>:</span> 3338477</span></span> }</span>,</span></span> "</span>prague</span>"</span>:</span> {</span></span> "</span>target</span>"</span>:</span> 6</span>,</span></span> "</span>max</span>"</span>:</span> 9</span>,</span></span> "</span>baseFeeUpdateFraction</span>"</span>:</span> 5007716</span></span> }</span>,</span></span> "</span>bpo1</span>"</span>:</span> {</span></span> "</span>target</span>"</span>:</span> 10</span>,</span></span> "</span>max</span>"</span>:</span> 15</span>,</span></span> "</span>baseFeeUpdateFraction</span>"</span>:</span> 8346193</span></span> }</span>,</span></span> }</span></span></code></pre> Client implementations may expose these values in different formats; this EIP reflects the canonical mainnet configuration values.</p> Rationale</h2> BPO-1 formalizes the first post-Fusaka adjustment to blob parameters, providing a controlled expansion of blob capacity to support empirical evaluation under mainnet conditions. This change enables the network to collect real-world performance data across clients, validators, and proposers, supporting evidence-based assessment of slot stability and system behavior before any further scaling decisions. Documenting BPO-1 as a standalone parameter update improves transparency and process clarity by establishing an authoritative record of blob parameter changes.</p> Security Considerations</h2> BPO upgrades may impact network load characteristics. Careful monitoring, staged rollout, and ecosystem coordination are required to ensure stability.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Hardfork Meta - Hegotá 2025-11-11T00:00:00+00:00 Abstract</h2> This Meta EIP lists the EIPs formally Proposed, Considered, Declined for & Scheduled for Inclusion in the Hegotá network upgrade.</p> Specification</h2> Definitions for Scheduled for Inclusion</code>, Considered for Inclusion</code>, Declined for Inclusion</code> and Proposed for Inclusion</code> can be found in EIP-7723</a>.</p> EIPs Scheduled for Inclusion</h3> Considered for Inclusion</h3> EIP-7805</a>: Fork-choice enforced Inclusion Lists (FOCIL)</li> </ul> Declined for Inclusion</h3> Proposed for Inclusion</h3> Activation</h3> Network Name</th> Activation Epoch</th> Activation Timestamp</th></tr></thead> Sepolia</td> </td> </td></tr> Hoodi</td> </td> </td></tr> Mainnet</td> </td> </td></tr> </tbody></table> Note</strong>: rows in the table above will be filled as activation times are decided by client teams.</p> Rationale</h2> This Meta EIP provides a global view of all changes included in the network upgrade, as well as links to full specification.</p> Security Considerations</h2> None.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Glamsterdam Gas Repricings 2025-08-21T00:00:00+00:00 Abstract</h2> This Meta EIP documents all the proposals for Glamsterdam related to the gas repricing effort. The goal of this effort is to harmonize gas costs across the EVM, thereby reducing the impact of specific bottlenecks on scaling. Proposals include changes to the cost of single EVM operations, as well as bigger changes to the gas model. This Meta EIP is purely informational and does not aim to have an active role in the governance process for the Glamsterdam fork. Instead, it serves as a directory for all repricing-related proposals, helping to organize the work and keeping the community informed about the status of each EIP.</p> Motivation</h2> The main objective of the Glamsterdam fork is to improve L1 scalability. A crucial aspect of this initiative is to create a better alignment between gas costs and actual resource usage. Currently, the gas model often misprices operations, resulting in inefficiencies and unintended incentives. For instance, within the pure compute operations, there is a high variance in execution time per gas unit, which indicates that a single unit of computation is not priced equally across the various opcodes.</p> By standardizing gas costs across EVM operations and other resources, we can reduce bottlenecks and enhance the utilization of EVM resources, which will subsequently enable further scalability. The EIPs listed below constitute a significant first step in that direction. We expect that further iteration will be necessary in future hardforks.</p> Specification</h2> The following table lists all EIPs related to repricings that are being discussed in the scope of the Glamsterdam fork. There are three types of EIPs in this list:</p> Broad harmonization</strong>. These EIPs reprice a class of operations with the goal of harmonizing them and removing single bottlenecks.</li> Pricing extension</strong>. These EIPs make targeted changes to a specific opcode or component of the gas model, usually coupled with a new mechanism.</li> Supporting</strong>. These EIPs are not directly doing a repricing, but instead introduce a change that support other repricing EIPs or enhance the scalability potential of repricings.</li> </ol> Considered for Inclusion</h3> EIP</th> Description</th> Type</th> Resource class</th> Gas change overview</th></tr></thead> EIP-2780</a></td> Reduce intrinsic transaction gas and charge 25k when a value transfer creates a new account.</td> Broad harmonization</td> Multi-resource</td> Decrease TX_BASE_COST</code> (21k→4.5k); increase new-account surcharge (0→25k)</td></tr> EIP-7778</a></td> Prevent Block Gas Limit Circumvention by Excluding Refunds from Block Gas Accounting.</td> Pricing extension</td> General Accounting</td> No opcode repricing; excludes gas refunds (e.g. SSTORE</code> clearing) from block gas accounting</td></tr> EIP-7904</a></td> Gas Cost Increase to reflect computational complexity and transaction throughput increase</td> Broad harmonization</td> Compute</td> All increase: DIV</code>, SDIV</code>, MOD</code>, MULMOD</code>, KECCAK256</code>, precompiles (BLAKE2F</code>, BLS12_G1ADD</code>, BLS12_G2ADD</code>, ECADD</code>, ECPAIRING</code>, POINT_EVALUATION</code>)</td></tr> EIP-7976</a></td> Further increase calldata cost to 15/60 gas per byte to reduce maximum block size.</td> Pricing extension</td> Data</td> Increase calldata floor cost (10/40 → 15/60 per byte)</td></tr> EIP-7981</a></td> Introduce floor pricing for access lists to reduce maximum block size.</td> Pricing extension</td> Data</td> Increase: new floor charge on access list data (addresses + storage keys)</td></tr> EIP-8037</a></td> Harmonization, increase and separate metering of state creation gas costs to mitigate state growth and unblock scaling.</td> Broad harmonization</td> State</td> All increase (dynamic with gas limit): GAS_CREATE</code>, GAS_CODE_DEPOSIT</code>, GAS_NEW_ACCOUNT</code>, GAS_STORAGE_SET</code>, PER_AUTH_BASE_COST</code></td></tr> EIP-8038</a></td> Increases the gas cost of state-access operations to reflect Ethereum's larger state.</td> Broad harmonization</td> State</td> All increase: cold storage write/access, cold account access, warm access, EXTCODESIZE</code>/EXTCODECOPY</code> extra read, access list costs</td></tr> </tbody></table> Declined for Inclusion</h3> EIP</th> Description</th> Type</th> Resource class</th></tr></thead> EIP-2926</a></td> Introduce code-chunking in an MPT context.</td> Pricing extension</td> State</td></tr> EIP-7686</a></td> Adjust memory limits and gas limits of sub-calls to create a clear linear bound on how much total memory an EVM execution can consume.</td> Pricing extension</td> Memory</td></tr> EIP-7923</a></td> Linearize Memory Costing and replace the current quadratic formula with a page-based cost model.</td> Pricing extension</td> Memory</td></tr> EIP-7971</a></td> Decrease costs for TLOAD</code> and TSTORE</code> with a transaction-global limit.</td> Pricing extension</td> Memory</td></tr> EIP-7973</a></td> Introduce warm account writes, decreasing the cost of writing to an account after the first write.</td> Pricing extension</td> State</td></tr> EIP-8011</a></td> Gas accounting by EVM resource, increasing throughput and improving resource usage controls, with minimal changes to the protocol and UX.</td> Supporting</td> NA</td></tr> EIP-8032</a></td> Makes SSTORE</code> gas cost scale with a contract's storage size to discourage state bloat.</td> Pricing extension</td> State</td></tr> EIP-8053</a></td> Adds milli-gas</code> as the EVM's internal gas accounting unit, reducing rounding errors without impacting UX.</td> Supporting</td> NA</td></tr> EIP-8057</a></td> Multi‑block temporal locality discounts for state and account access.</td> Pricing extension</td> State</td></tr> EIP-8058</a></td> Reduces gas costs for deploying duplicate contract bytecode via access-list based mechanism.</td> Pricing extension</td> State</td></tr> EIP-8059</a></td> Gas parameters and variables are increased to a factor of REBASE_FACTOR</code> to reduce rounding errors without major changes to the EVM.</td> Supporting</td> NA</td></tr> </tbody></table> Rationale</h2> Gas cost changes by operation</h3> The following tables summarize the preliminary gas cost changes. Numbers are not yet finalized and will be subject to change.</p> Compute Opcodes — EIP-7904</a> (all increase)</h4> Opcode</th> Name</th> Current</th> New</th> Direction</th></tr></thead> 0x04</td> DIV</code></td> 5</td> 15</td> increase</td></tr> 0x05</td> SDIV</code></td> 5</td> 20</td> increase</td></tr> 0x06</td> MOD</code></td> 5</td> 12</td> increase</td></tr> 0x09</td> MULMOD</code></td> 8</td> 11</td> increase</td></tr> 0x20</td> KECCAK256</code> (base)</td> 30</td> 45</td> increase</td></tr> </tbody></table> KECCAK256</code> per-word cost stays at 6. ADDMOD</code>, SMOD</code>, and ECRECOVER</code> are unchanged.</p> Precompiles — EIP-7904</a> (all increase)</h4> Precompile</th> Current</th> New</th> Direction</th></tr></thead> BLAKE2F</code> (base)</td> 0</td> 170</td> increase</td></tr> BLAKE2F</code> (per round)</td> 1</td> 2</td> increase</td></tr> BLS12_G1ADD</code></td> 375</td> 643</td> increase</td></tr> BLS12_G2ADD</code></td> 600</td> 765</td> increase</td></tr> ECADD</code></td> 150</td> 314</td> increase</td></tr> ECPAIRING</code> (per pair)</td> 34,000</td> 34,103</td> increase (slight)</td></tr> POINT_EVALUATION</code></td> 50,000</td> 89,363</td> increase</td></tr> </tbody></table> State Access — EIP-8038</a> (all increase, values TBD)</h4> Opcode(s)</th> Component</th> Current</th> New</th> Direction</th></tr></thead> SSTORE</code></td> GAS_COLD_STORAGE_WRITE</code></td> 5,000</td> TBD</td> increase</td></tr> SSTORE</code>, SLOAD</code></td> GAS_COLD_STORAGE_ACCESS</code></td> 2,100</td> TBD</td> increase</td></tr> CALL</code>, STATICCALL</code>, DELEGATECALL</code>, BALANCE</code>, EXT*</code>, SELFDESTRUCT</code></td> GAS_COLD_ACCOUNT_ACCESS</code></td> 2,600</td> TBD</td> increase</td></tr> All state ops (warm)</td> GAS_WARM_ACCESS</code></td> 100</td> TBD</td> increase</td></tr> EXTCODESIZE</code></td> Extra warm read for 2nd DB lookup</td> 0</td> +GAS_WARM_ACCESS</code></td> increase (new)</td></tr> EXTCODECOPY</code></td> Extra warm read for 2nd DB lookup</td> 0</td> +GAS_WARM_ACCESS</code></td> increase (new)</td></tr> SSTORE</code>, SLOAD</code> (access list)</td> ACCESS_LIST_STORAGE_KEY_COST</code></td> 1,900</td> TBD</td> increase</td></tr> CALL</code> etc. (access list)</td> ACCESS_LIST_ADDRESS_COST</code></td> 2,400</td> TBD</td> increase</td></tr> </tbody></table> State Creation — EIP-8037</a> (all increase, dynamic with gas limit)</h4> At 60M gas limit, cost_per_state_byte</code> (cpsb) = 662. Costs scale up with higher gas limits.</p> Operation</th> Opcodes Affected</th> Current</th> New (at 60M)</th> Direction</th></tr></thead> GAS_CREATE</code></td> CREATE</code>, CREATE2</code>, create txs</td> 32,000</td> 112 x cpsb + 9,000 (~83k)</td> increase</td></tr> GAS_CODE_DEPOSIT</code></td> CREATE</code>, CREATE2</code>, create txs</td> 200/byte</td> cpsb/byte + hash (~662/byte)</td> increase</td></tr> GAS_NEW_ACCOUNT</code></td> CALL*</code> to new accounts</td> 25,000</td> 112 x cpsb (~74k)</td> increase</td></tr> GAS_STORAGE_SET</code></td> SSTORE</code> (0 -> non-zero)</td> 20,000</td> 32 x cpsb + 2,900 (~24k)</td> increase</td></tr> PER_AUTH_BASE_COST</code></td> EIP-7702 auth</td> 12,500</td> 23 x cpsb + 7,500 (~22.7k)</td> increase</td></tr> PER_EMPTY_ACCOUNT_COST</code></td> EIP-7702 auth</td> 25,000</td> 112 x cpsb (~74k)</td> increase</td></tr> </tbody></table> Transaction-Level Costs</h4> Parameter</th> Current</th> New</th> Direction</th> EIP</th></tr></thead> TX_BASE_COST</code></td> 21,000</td> 4,500</td> decrease</td> 2780</a></td></tr> New account surcharge (top-level value tx)</td> 0</td> 25,000</td> increase</td> 2780</a></td></tr> Calldata floor cost</td> 10/40 per byte</td> 15/60 per byte</td> increase</td> 7976</a></td></tr> Access list data cost</td> 0</td> floor_token_cost</code> per token</td> increase (new)</td> 7981</a></td></tr> </tbody></table> Security Considerations</h2> Discussed in the individual EIPs.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> History Expiry Meta 2025-03-28T00:00:00+00:00 Abstract</h2> This Meta-EIP documents the activation process and plan for history expiry as well as providing links to other EIPs that are related.</p> Motivation</h2> EIP-4444</a> documents the motivation for history expiry itself.</p> This EIP exists to document the process through which history expiry will be activated on mainnet, the testnet activation on Sepolia, devnet testing and other information surrounding history expiry that doesn't fit cleanly in any of the supporting EIPs.</p> Specification</h2> 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 and RFC 8174.</p> Execution layer client MUST implement EIP-7642</a> to support the eth/69</code> over DevP2P.</p> Execution layer clients MAY drop pre-merge history according to EIP-7639</a>.</p> Consensus layer clients SHOULD NOT depend on Execution Layer clients having the deposit logs from pre-merge blocks and SHOULD implement EIP-6110</a>.</p> Mainnet Activation</h3> Mainnet activation of history expiry will occur shortly (a few days or weeks) after the activation of the Pectra</a> hard fork. The short delay is to ensure that all deposit logs from before the fork have been processed before clients begin dropping history.</p> Testnet Activation</h3> Testing of history expiry will occur on the Sepolia testnet. Execution clients may begin dropping pre-merge Sepolia history on 2025-05-01.</p> Devnet Activation</h3> Execution clients may test dropping of history on devnets.</p> Rationale</h2> Why wait for Pectra</h3> Consensus Layer clients have a dependency on pre-merge deposit logs. EIP-6110</a> will remove this dependency when the Pectra fork is activated.</p> Why drop Sepolia history</h3> The Sepolia history drop is intended as a testing ground for the mainnet activation.</p> Why drop Devnet history</h3> The Devnet history drop is intended to test prior to Sepolia to avoid any breakage on the Sepolia network.</p> Won't this break JSON-RPC</h3> History Expiry doesn't require clients to remove this data. It only allows them to. Clients that wish to preserve this history in their client for JSON-RPC use cases are free to do so.</p> Where will Pre-Merge history be stored</h3> Pre-merge data is available in the e2store archival format. A public list of these archives can be found in the eth-clients</code> historical data endpoints list which can be found on the eth-clients</code> website.</p> The Portal network also implements a decentralized peer-to-peer solution for storage and retrieval of all of Ethereum's pre-merge block data.</p> The EIP-7801</a> DevP2P protocol also provides a peer-to-peer solution for retrieval of this data.</p> Backwards Compatibility</h2> DevP2P eth</code> protocol</h3> Clients of the DevP2P eth</code> protocol will need to upgrade to the new eth/69</code> version specified in EIP-7642</a></p> Pre-Merge Deposit Logs</h3> Consensus Layer clients have had a historical dependency on the deposit logs from pre-merge blocks. Dropping history would make these logs inaccessible to the Consensus Layer client. This issue is mitigated by EIP-6110</a></p> Serving Pre-Merge JSON-RPC</h3> Execution clients that choose to drop history will no longer be capable of serving JSON-RPC requests for pre-merge requests for the following endpoints without sourcing the data from an alternate data source.</p> eth_getBlockTransactionCountByHash</code></li> eth_getBlockTransactionCountByNumber</code></li> eth_getUncleCountByBlockHash</code></li> eth_getUncleCountByBlockNumber</code></li> eth_getBlockByHash</code></li> eth_getBlockByNumber</code></li> eth_getTransactionByHash</code></li> eth_getTransactionByBlockHashAndIndex</code></li> eth_getTransactionByBlockNumberAndIndex</code></li> eth_getTransactionReceipt</code></li> eth_getUncleByBlockHashAndIndex</code></li> eth_getUncleByBlockNumberAndIndex</code></li> </ul> Security Considerations</h2> Full History Sync</h3> Execution layer clients will no longer be able to implement a full historical sync of history from the DevP2P eth</code> protocol. Clients that wish to retain this functionality will need to source the pre-merge blocks from an alternate source. Clients SHOULD ensure that they continue to correctly validate block data sourced from alternate locations.</p> Partial History Sync</h3> Execution layer clients that do a partial sync will need to adjust their syncing algorithms to only go back to the merge block as opposed to the previous behavior of tracing all the way back to genesis. Clients SHOULD ensure that their sync algorithms and other functionality are able to handle this data no longer being locally available.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Pureth Meta 2025-03-26T00:00:00+00:00 Abstract</h2> This Meta EIP bundles a set of improvements to make Ethereum data easier to access and verify without relying on trusted RPC providers or third-party indexers. The improvements achieve this by changing data structures for blocks, transactions, and receipts, so that efficient correctness (i.e., validity) and completion (i.e., nothing omitted) proofs can be added to the RPC responses.</p> Motivation</h2> Security</strong>: Today, most wallets and dApps consume data from very few large RPC providers, which exposes users to the risk of incorrect and incomplete data in case the RPC provider gets hacked, becomes malicious, or uses a faulty software version.</p> </li> Privacy</strong>: Centralized infrastructure is subject to external data collection and privacy policies; users may be profiled across distinct wallets even when there is no on-chain link between them.</p> </li> Cost</strong>: External indexers can be quite costly, however, are required for even basic wallet use cases. Reducing reliance on them helps lower-funded developers.</p> </li> </ul> Specification</h2> 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 and RFC 8174.</p> Improve UX: ETH transfer logs</h3> ETH transfers currently don't emit logs, and in many situations don't leave any on-chain record in neither transaction nor receipt that they took place. For example, SENDALL can send an arbitrary ETH balance to an arbitrary account as part of a smart contract based wallet. Or a new contract deployment may send ETH to a new account of which not even the address is known yet. This makes basic flows, such as detecting a user deposit onto an exchange, very tricky. Wallets, dApps etc. either have to use tracing debug APIs on every single transaction of every single block, or integrate an external trusted indexing service which can be costly.</p> EIP-7708: ETH transfers emit a log</a></li> EIP-7799: System logs</a></li> </ul> Scale L1 / Improve UX: LOG reform</h3> The current 2048-bit Bloom filter has a high false positive rate, which grows further as more logs are packed into each block. Combined with the requirements to obtain all historical block headers to obtain a complete view of an account's history, the Bloom filter becomes practically irrelevant. A new on-chain 2D log index with bounded false positive rate and a historical accumulator is proposed that is highly efficient, further reducing the need for external indexing services for basic wallet use cases.</p> EIP-7668: Remove bloom filters</a></li> EIP-7745: Light client and DHT friendly log index</a></li> EIP-7792: Verifiable logs</a> (alternative, with log index root provided via ZK instead of block header)</li> </ul> Improve UX: Normalized transactions / receipts</h3> There are various JSON-RPC fields that are missing on-chain and inefficient to prove:</p> from</code>, contractAddress</code>, and authority</code> addresses</strong>: need to fetch transaction + use ecrecover</code></li> gasUsed</code></strong>: needs current and prior receipt, as on-chain data stores cumulative not individual gas used</li> logIndex</code></strong>: need to fetch all receipts in the block</li> txHash</code></strong>: the on-chain data is based on an MPT-prefixed hash, which is different from the RPC hash</li> </ul> Further, calldata</code> and log data</code></strong> can be very large, but can only be verified by downloading the entire receipt / transaction data. This data is needed even if just basic items such as amount and destination are queried.</p> Switching transactions and receipts to SSZ normalizes the format, changes to tree-based hash for more efficient proofs, and is also extensible for future transaction features such as multidimensional fees, CREATE2 deployment, and post-quantum signature types, without breaking verifiers that only check common fields.</p> EIP-6404: SSZ transactions</a></li> EIP-6466: SSZ receipts</a></li> </ul> Improve UX: Serialization harmonization</h3> Changing the remainder of the EL to SSZ enables a switch to a binary API as an alternative to the dated JSON-RPC API. This is especially interesting for the engine API which currently encodes all blobs as ASCII hex-strings over JSON. That binary API would follow the same approach as beacon-APIs, be based on REST, SSZ, and Snappy compression, and support similar functionality as JSON-RPC, except that all response data now comes with a correctness and exhaustiveness proof. The SSZ objects are designed to efficiently serve API requests, often allowing to answer directly from the database without having to decompress stored data on the server and without having to consult auxiliary indices.</p> EIP-6465: SSZ withdrawals root</a></li> EIP-7807: SSZ execution blocks</a></li> </ul> Simple Serialize (SSZ) requirements</h3> The EIPs require adding production-grade Simple Serialize (SSZ) libraries to all execution client implementations. Further, new SSZ data types are required to achieve forward compatibility while maintaining reasonable efficiency when using nested lists of large theoretical capacity.</p> EIP-7916: SSZ ProgressiveList</a></li> EIP-7495: SSZ ProgressiveContainer</a></li> </ul> Rationale</h2> See individual EIPs.</p> Security Considerations</h2> See individual EIPs.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Max blob flag for local builders 2025-01-30T00:00:00+00:00 Abstract</h2> This EIP adds a flag to the block builder in order to allow them to include a client configured maximum amount of blobs. This is an execution layer only change.</p> Motivation</h2> Currently a builder will include all blobs in their local mempool, up to the maximum amount that the protocol requires. If a builder has low bandwidth, they may include too many blobs and subsequently end up not being able to convince the network that the blobs are available.</p> Specification</h2> Create a parameter in block builder's configuration called USER_CONFIGURED_MAX_BLOBS_PER_BLOCK</code></li> Take the minimum out of the MAX_BLOB_GAS_PER_BLOCK</code> and the USER_CONFIGURED_MAX_BLOBS_PER_BLOCK</code></li> If the minimum is zero, set the minimum to one.</li> Use the minimum to decide how many blobs to include in the block</li> </ul> Note: By default USER_CONFIGURED_MAX_BLOBS_PER_BLOCK</code> may be set to the maximum in the current fork.</p> Rationale</h2> By adding a flag for the local block builder, they are able to specify how many blobs they can include in a block.</p> Backwards Compatibility</h2> No backward compatibility issues found.</p> Security Considerations</h2> N/A</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Reserve Tx-Type Range for RIPs 2024-11-04T00:00:00+00:00 Abstract</h2> This EIP reserves a transaction-type</a> range for use by the Rollup Improvement Proposal (RIP) process to ensure there are no conflicts.</p> Motivation</h2> For L2s to use new transactrion types, it is necessary to reserve a transaction-type range for use by the RIP process so as to ensure there are no conflicts between transaction types used by RIPs and EIPs.</p> Specification</h2> The transaction-type (as specified in EIP-2718</a>) range from 0x40</code> to 0x7f</code> (inclusive of both) is reserved for use by the RIP process.</p> Rationale</h2> By reserving a transaction-type range for RIPs, it allows the RIP process to maintain its own registry of transaction types that are not (necessarily) in use on L1 mainnet, the EIP process is then freed from having to maintain a registry of RIP tx-types while still having 64 tx-types for its own use.</p> Backwards Compatibility</h2> No backward compatibility issues found.</p> Security Considerations</h2> Nil.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Hardfork Meta - Glamsterdam 2024-09-26T00:00:00+00:00 Abstract</h2> This Meta EIP lists the EIPs formally Proposed, Considered, Declined for & Scheduled for Inclusion in the Glamsterdam network upgrade.</p> Specification</h2> Definitions for Scheduled for Inclusion</code>, Considered for Inclusion</code>, Declined for Inclusion</code> and Proposed for Inclusion</code> can be found in EIP-7723</a>.</p> EIPs Scheduled for Inclusion</h3> EIP-7732</a>: Enshrined Proposer-Builder Separation</li> EIP-7928</a>: Block-Level Access Lists</li> </ul> Considered for Inclusion</h3> EIP-2780</a>: Reduce intrinsic transaction gas</li> EIP-7688</a>: Forward compatible consensus data structures</li> EIP-7708</a>: ETH transfers emit a log</li> EIP-7778</a>: Block Gas Accounting without Refunds</li> EIP-7843</a>: SLOTNUM opcode</li> EIP-7904</a>: General Repricing</li> EIP-7954</a>: Increase Maxiumum Contract Size</li> EIP-7976</a>: Increase Calldata Floor Cost</li> EIP-7981</a>: Increase Access List Cost</li> EIP-7997</a>: Deterministic Factory Predeploy</li> EIP-8024</a>: Backward compatible SWAPN, DUPN, EXCHANGE</li> EIP-8037</a>: State Creation Gas Cost Increase</li> EIP-8038</a>: State-access gas cost increase</li> EIP-8045</a>: Exclude slashed validators from proposing</li> EIP-8061</a>: Increase exit and consolidation churn</li> EIP-8070</a>: Sparse Blobpool</li> EIP-8080</a>: Let exits use the consolidation queue</li> </ul> Declined for Inclusion</h3> EIP-2926</a>: Chunk-based code merkelization</li> EIP-5920</a>: PAY opcode</li> EIP-6404</a>: SSZ transactions</li> EIP-6466</a>: SSZ receipts</li> EIP-7619</a>: Precompile Falcon512 generic verifier</li> EIP-7668</a>: Remove bloom filters</li> EIP-7686</a>: Linear EVM memory limits</li> EIP-7692</a>: EVM Object Format (EOFv1) Meta</li> EIP-7745</a>: Trustless log index</li> EIP-7782</a>: Reduce Block Latency</li> EIP-7791</a>: GAS2ETH opcode</li> EIP-7793</a>: Conditional Transactions</li> EIP-7805</a>: Fork-choice enforced Inclusion Lists (FOCIL)</li> EIP-7819</a>: SETDELEGATE instruction</li> EIP-7886</a>: Delayed execution</li> EIP-7903</a>: Remove Initcode Size Limit</li> EIP-7907</a>: Meter Contract Code Size And Increase Limit</li> EIP-7919</a>: Pureth Meta</li> EIP-7923</a>: Linear, Page-Based Memory Costing</li> EIP-7932</a>: Secondary Signature Algorithms</li> EIP-7937</a>: EVM64 - 64-bit mode EVM opcodes</li> EIP-7942</a>: Available Attestation</li> EIP-7971</a>: Hard Limits for Transient Storage</li> EIP-7973</a>: Warm Account Write Metering</li> EIP-7979</a>: Call and Return Opcodes for the EVM</li> EIP-8011</a>: Multidimensional Gas Metering</li> EIP-8013</a>: Static relative jumps and calls for the EVM</li> EIP-8030</a>: P256 transaction support</li> EIP-8032</a>: Size-Based Storage Gas Pricing</li> EIP-8051</a>: Precompile for ML-DSA signature verification</li> EIP-8053</a>: Milli-gas for High-precision Gas Metering</li> EIP-8057</a>: Inter-Block Temporal Locality Gas Discounts</li> EIP-8058</a>: Contract Bytecode Deduplication Discount</li> EIP-8059</a>: Gas Units Rebase for High-precision Metering</li> EIP-8062</a>: Add sweep withdrawal fee for 0x01 validators</li> EIP-8068</a>: Neutral effective balance design</li> EIP-8071</a>: Prevent using consolidations as withdrawals</li> </ul> Proposed for Inclusion</h3> EIP-7610</a>: Revert creation in case of non-empty storage</li> EIP-7872</a>: Max blob flag for local builders</li> EIP-7949</a>: Schema for genesis.json</code> files</li> </ul> Activation</h3> Network Name</th> Activation Epoch</th> Activation Timestamp</th></tr></thead> Sepolia</td> </td> </td></tr> Holešky</td> </td> </td></tr> Mainnet</td> </td> </td></tr> </tbody></table> Note</strong>: rows in the table above will be filled as activation times are decided by client teams.</p> Rationale</h2> This Meta EIP provides a global view of all changes included in the Glamsterdam network upgrade, as well as links to full specification.</p> Security Considerations</h2> None.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> No-Ether transactions with free-for-all tips 2024-09-14T00:00:00+00:00 Abstract</h2> A technique is introduced where an externally-owned account having no Ether can send transactions and pay tips using a new "free-for-all" bucket and using their own origin.tx</code>. This requires no client changes and is compatible with existing ecosystem parts.</p> Motivation</h2> There is much interest in third-party-pay transactions on Ethereum and competing networks.</p> Other proposals require changes to the Ethereum client, that transactions be sent to the network (i.e. tx.origin</code>) using a separate account and/or other additional things.</p> In contrast, this proposal introduces and standardizes a solution to this problem that works only with existing client and technology, and which preserves the tx.origin</code> of the originator of a transaction.</p> Specification</h2> End user process</h3> An end user who controls an externally-owned account, say Alice, will prepare transaction(s) she would like to execute and she signs this (series of) transactions.</li> If Alice will like to provide consideration for executing these transactions, she will ensure that a well-known address on the network, "the free-for-all bucket" will control tokens (such as 20, 721, 1155 tokens) at the end of her series of transactions.</li> Alice orders her transaction nonces carefully considering that what will eventually be executed may be: None of them;</li> Only the first;</li> The first then the second;</li> The first, then the second, ... then the Nth transaction, which is not the last in her series of transactions; or</li> All her transactions, in order.</li> </ol> </li> Alice sends this series of transactions to a service that communicates with block proposers. Currently mempools in baseline clients would not propagate such transactions.</li> </ol> </li> </ol> For example, if consideration is sent to the free-for-all address, this would typically be the last in her series of transactions.</p> Block preparer process</h3> Sign a transaction (from any origin) to send Ether to Alice representing the current gas price times the current block size.</li> (Optional) Prepare and sign a transaction to the free-for-all account, to preload any necessary responses.</li> Start an execution context and include this send-Ether transaction and all of Alice's transactions.</li> In the execution context, identify tokens (e.g. 20, 721, 1155) sent to the free-for-all contract address or other valuable consideration accrued to the free-for-all account.</li> Sign a transaction to (from any origin) to take security of the consideration from the free-for-all account and include this transaction in the execution context.</li> Evaluate the total gas spent.</li> Rollback the execution context. And repeat steps 1 through 4 with these changes: Step 1: use the actual required gas amount (in Ether).</li> Step 4: abort if the consideration received in this second iteration is not the expected amount from the first iteration.</li> </ol> </li> Use some local business logic to compare the Ether spent in step 1 (second iteration) versus the consideration received in step 4 and classify the result as favorable or not.</li> If the result is favorable, commit this execution context to the mainline. Or if the result is not favorable, rollback this execution context. The result of this decision may feed into a reputation tracking system to avoid evaluating future unfruitful transaction(s).</li> </ol> </li> Continue execution, and publish the block.</li> </ol> Free-for-all bucket</h3> This approach requires that the end user must be able to send consideration the block proposer without knowing who they are, and the block proposer must be able to realize this consideration.</p> This EIP proposes to use a well-known contract account deployment for this purpose. And here is the required interface:</p> interface</span> FreeForAll</span> {</span></span> //</span> Performs a call</span></span> function</span> execute</span>(</span>address</span> recipient</span>,</span> memory</span> bytes</span>,</span> uint256</span> gasLimit</span>,</span> uint256</span> value</span>)</span>;</span></span> </span> //</span> Prepare return values for the next N times this contract is called only in this block</span></span> //</span> [</span>TODO</span>: spell this out]</span></span> function</span> preloadExecutions</span>(</span>memory</span> bytes</span>[</span>]</span>)</span>;</span></span> </span></span> //</span> Return the next return value in this block from preloadExecutions</span></span> fallback</span>(</span>)</span> {</span></span> }</span></span> }</span></span></code></pre>Rationale</h2> This approach can be useful for end users who do not want to or are not able to add Ether to their account.</p> This approach allows to use the correct origin.tx</code> which may be required for important transactions like ERC-721 setApprovalForAll</code>.</p> This approach may use more gas than other approaches where the consensus client is changed or where transactions can execute from (origin.tx</code>) a different account.</p> Alternatives considered</h3> Update EIP-1559</a> so that transactions with gasPrice = 0 are legal, but only if the commensurate amount of gas will be burnt by the block preparer in that same block.</li> Create a new transaction type that encapsulates another signed transaction.</li> Create a new opcode to get the coinbase of the next block.</li> </ul> Backwards Compatibility</h2> ... </p> Security Considerations</h2> ... </p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Network Upgrade Inclusion Stages 2024-06-12T00:00:00+00:00 Abstract</h2> Define the stages that EIPs go through in the process of planning network upgrades: Proposed for Inclusion</code>, Considered for Inclusion</code>, Scheduled for Inclusion</code>, Declined for Inclusion</code> and Included</code>.</p> Motivation</h2> This EIP proposes definitions for the various stages EIPs go through when planning network upgrades. It also provides context and guidelines around when and how EIPs should be moved from one stage to the next.</p> Specification</h2> 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 and RFC 8174.</p> All EIP statuses apply to a single network upgrade. EIPs must be Proposed</code>, Considered</code>, Declined</code> or Scheduled</code> separately for each network upgrade. While an EIP cannot be Included</code> in two network upgrades, an EIP being Declined for Inclusion</code> in a previous upgrade does not prevent it from being Proposed</code>, Considered</code>, Declined</code> or Scheduled</code> for inclusion in any future upgrade.</p> The statuses below are generally defined for Core EIPs, which must be activated synchronously by all nodes on a network. To help with prioritization and communications, non-Core EIPs may also be assigned these statuses. The differences in the process and implications for non-Core EIPs are noted in each status definition.</p> Upgrade Meta EIPs</h3> Anyone MAY</strong> draft a Meta EIP to list EIPs for a network upgrade. This Meta EIP SHOULD</strong> include four categories in its specification section: Proposed for Inclusion</code>, Declined for Inclusion</code>, Considered for Inclusion</code> and Scheduled for Inclusion</code>. Even if a category is empty, it SHOULD</strong> be included in the initial draft for clarity.</p> When the Upgrade Meta EIP is moved to Last Call</code>, the Proposed for Inclusion</code>, Declined for Inclusion</code> and Considered for Inclusion</code> lists SHOULD</strong> be removed, leaving only Scheduled for Inclusion</code>.</p> Before the Upgrade Meta EIP is moved to Final</code>, the Scheduled for Inclusion</code> stage MUST</strong> be renamed to Included</code> and contain only EIPs that were activated in the upgrade.</p> Upgrade Devnets</h3> When preparing a network upgrade, client developers typically implement EIPs first on an ephemeral test network (upgrade devnet) to verify client interoperability, before deploying to long-lived test networks. These upgrade devnets follow a naming convention of upgradeName-devnet-version</code> (e.g. pectra-devnet-0</code> for the first upgrade devnet of the Pectra network upgrade, dencun-devnet-1</code> for the second upgrade devnet of the Dencun update, etc).</p> Since client developers' ability to include EIPs in a network upgrade is constrained by what can be implemented and tested in these upgrade devnets, the Considered for Inclusion</a> and Scheduled for Inclusion</a> sections below propose aligning these statuses with EIPs' implementation status in upgrade devnets.</p> Proposed for Inclusion</h3> To propose an EIP for inclusion, someone MUST</strong> open a pull request to add it to the Proposed for Inclusion</code> section of the Upgrade Meta EIP. The proposer of an EIP SHOULD</strong> serve as the primary point of contact for that EIP for the duration of the upgrade cycle or SHOULD</strong> designate another person to serve in that role. Reasonable pull requests SHOULD</strong> be merged in a timely fashion by the Upgrade Meta EIP author.</p> At this stage, implementation teams SHOULD</strong> review the EIP. For Core EIPs, this should be in the context of including it in the next upgrade. For non-Core EIPs, this should be in the context of supporting the EIP before the network upgrade is activated.</p> Note that EIPs must be Proposed for Inclusion</code> for each network upgrade. In other words, proposals do not "carry over" to the next upgrade if an EIP is not included in the one it was first proposed for.</p> Considered for Inclusion</h3> Once client developers have reviewed an EIP which was Proposed for Inclusion</code>, they MAY</strong> move it to the Considered for Inclusion</code> stage. Once a decision is made by client teams to move an EIP to Considered for Inclusion</code>, the Upgrade Meta EIP SHOULD</strong> be updated to reflect this.</p> Considered for Inclusion</code> signals that client developers are positive towards the EIP. A Core EIP that is Considered for Inclusion</code> SHOULD</strong> be implemented in future Upgrade Devnets. Assuming it meets all the requirements for mainnet deployment it MAY</strong> be included in the network upgrade. This stage is similar to "concept ACK" in other open source projects, and is not sufficient to result in deployment to mainnet.</p> Non-Core EIPs that are Considered for Inclusion</code> SHOULD</strong> be supported prior to the network upgrade being activated.</p> An EIP MAY</strong> be moved from Considered for Inclusion</code> to Declined for Inclusion</code> if client teams are against including the EIP in the network upgrade.</p> An EIP SHOULD</strong> have a Python implementation accompanied by tests in execution-specs</a> submitted as an open PR. The EIP writer is encouraged to reach out to the maintainers of execution-specs for assistance with implementation. Client developers MAY</strong> decide to allow an EIP to be moved to Considered for Inclusion</code> without either implementation, being aware that the absence of these implementations could lead to delays in the testing cycle.</p> Any updates to an EIP that is already at this stage SHOULD</strong> be accompanied by the appropriate updates to its implementation and tests in execution-specs</a> if deemed necessary by client developers.</p> Declined for Inclusion</h3> At any time during the network upgrade planning process, client developers MAY</strong> move EIPs from any other stage to the Declined for Inclusion</code> stage if client teams are against including the EIP in the network upgrade. Once a decision is made by client teams to move an EIP to Declined for Inclusion</code>, the Upgrade Meta EIP SHOULD</strong> be updated to reflect this.</p> Declined for Inclusion</code> signals that client developers wish to exclude the EIP from the current network upgrade and stop discussing its potential inclusion or implementation status in relation to this upgrade. An EIP which was Declined for Inclusion</code> in a particular upgrade MAY</strong> still be Proposed for Inclusion</code> in a subsequent upgrade. In exceptional circumstances, client developers MAY</strong> choose to move an EIP from Declined for Inclusion</code> to Considered for Inclusion</code> or Scheduled for Inclusion</code>.</p> Scheduled for Inclusion</h3> When client teams agree to implement a Core EIP in the next</strong> Upgrade Devnet, the EIP SHOULD</strong> move to the Scheduled for Inclusion</code> stage, and the Upgrade Meta EIP SHOULD</strong> be updated to reflect this. Non-Core EIPs SHOULD</strong> move to Scheduled for Inclusion</code> when client teams agree to immediately prioritize their implementation.</p> An EIP MUST</strong> have a Python implementation accompanied by tests in execution-specs</a>, submitted as an open PR or merged to the devnets/upgradeName/version</code> branch of the repository. Client developers MAY</strong> decide to allow an EIP to be moved to Scheduled for Inclusion</code> without an execution-specs</a> implementation, but the tests are strictly mandatory.</p> Any updates to an EIP that is already at this stage MUST</strong> be accompanied by appropriate updates to its implementation and tests in execution-specs</a> if deemed necessary by client developers.</p> Scheduled for Inclusion</code> signals that implementation and testing work are underway. The EIP SHOULD</strong> be included in the network upgrade if no issues arise. The latest Upgrade Devnet must contain all Scheduled for Inclusion</code> Core EIPs.</p> An EIP MAY</strong> be moved from Scheduled for Inclusion</code> to Declined for Inclusion</code> if client teams are against including the EIP in the network upgrade. An EIP MAY</strong> also be moved from Scheduled for Inclusion</code> to Considered for Inclusion</code> if client teams are in favor of including the EIP in the network upgrade but cannot commit to including it in the next</strong> Upgrade Devnet.</p> Included</h3> After network upgrade activation, all included Core EIPs and activated non-Core EIPs MUST</strong> be moved to Included</code> in the Meta EIP. All other status lists MUST</strong> be removed from the Meta EIP.</p> Included</code> signals that the EIPs have been activated as part of the network upgrade.</p> Rationale</h2> Formalizing the Proposed for Inclusion</code>, Considered for Inclusion</code>, Scheduled for Inclusion</code>, Declined for Inclusion</code> and Included</code> stages provides better legibility to both protocol maintainers and the broader Ethereum community.</p> The specification tries to minimize steps which MUST</strong> be followed to align with Ethereum's "rough consensus" governance model.</p> Assuming it is adopted, the process outlined in this EIP should be used for at least one full network upgrade cycle before moving to Last Call</code> and at least two full network upgrades cycles before moving to Final</code>. This way, the EIP can be updated to reflect changes made to the process over time.</p> Backwards Compatibility</h2> This EIP does not directly change the Ethereum protocol. It formalizes parts of the current network upgrade planning process.</p> Security Considerations</h2> None.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> EVM Object Format (EOFv1) Meta 2024-04-17T00:00:00+00:00 Abstract</h2> This Meta EIP lists the EIPs which belong to the EVM Object Format (EOF) proposal, in its first version (EOFv1), also known as the "Mega EOF".</p> Specification</h2> EIPs Included</h3> Introduced in eof-devnet-0</p> EIP-3540</a>: EOF - EVM Object Format v1</li> EIP-3670</a>: EOF - Code Validation</li> EIP-4200</a>: EOF - Static relative jumps</li> EIP-4750</a>: EOF - Functions</li> EIP-5450</a>: EOF - Stack Validation</li> EIP-6206</a>: EOF - JUMPF and non-returning functions</li> EIP-7480</a>: EOF - Data section access instructions</li> EIP-663</a>: SWAPN, DUPN and EXCHANGE instructions</li> EIP-7069</a>: Revamped CALL instructions</li> EIP-7620</a>: EOF Contract Creation</li> EIP-7698</a>: EOF - Creation transaction</li> </ul> Introduced in eof-devnet-1</p> EIP-7873</a>: EOF - TXCREATE and InitcodeTransaction type</li> </ul> Removed from eof-devnet-1</p> EIP-7698</a>: EOF - Creation transaction</li> </ul> Introduced in eof-devnet-2</p> EIP-7834</a>: Separate Metadata Section for EOF</li> EIP-7761</a>: EXTCODETYPE instruction</li> EIP-7880</a>: EOF - EXTCODEADDRESS instruction</li> EIP-5920</a>: PAY opcode</li> </ul> Rationale</h2> Refer to the individual EIPs.</p> Security Considerations</h2> Discussed in the individual EIPs.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Retroactively Included EIPs 2024-04-04T00:00:00+00:00 Abstract</h2> This Meta EIP lists Core EIPs introducing changes to Ethereum's consensus which were activated independently of an Ethereum hard fork due to their backward compatible nature. These EIPs generally introduce constraints to underspecified protocol rules or clarify how certain edge cases should be handled.</p> Motivation</h2> To maintain consensus across all nodes, backward incompatible changes to Ethereum must be activated synchronously. Given the coordination required for this, changes are usually bundled together in network upgrades. A Meta EIP is typically used to list the changes included in a network upgrade, as well as its activation time.</p> However, backward compatible consensus changes do not require a network upgrade to be activated. For example, if a consensus rule is underspecified, an EIP can propose a constraint to bound it. If the constraint was never broken in Ethereum's history and is unlikely to be broken in the future, the EIP can be considered backward compatible. It could then be "retroactively activated", as both nodes which support the change and those which do not would agree on the current network state and history.</p> This Meta EIP lists all such EIPs which core developers have retroactively included as part of the Ethereum protocol specification.</p> Specification</h2> Retroactively Activated EIPs</h3> EIP-2681</a>: Limit account nonce to 2^64-1</li> EIP-3607</a>: Reject transactions from senders with deployed code</li> EIP-4803</a>: Limit transaction gas to a maximum of 2^63-1</li> EIP-7523</a>: Empty accounts deprecation</li> EIP-7610</a>: Revert creation in case of non-empty storage</li> </ul> Activation</h3> All EIPs listed above are considered activated as of Ethereum's genesis block. Note that EIP-7523 distinguishes pre- and post-merge behavior on the Ethereum mainnet.</p> Rationale</h2> This Meta EIP provides a global view of all changes included in the Ethereum protocol without an explicit network upgrade, as well as links to full specification.</p> Backwards Compatibility</h2> No backward compatibility issues found.</p> Security Considerations</h2> None.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Hardfork Meta - Fusaka 2024-02-01T00:00:00+00:00 Abstract</h2> This Meta EIP lists the EIPs included in the Fulu/Osaka network upgrade. It follows the Pectra upgrade, documented in EIP-7600</a>.</p> Specification</h2> Included EIPs</h3> Core EIPs</h4> EIP-7594</a>: PeerDAS - Peer Data Availability Sampling</li> EIP-7823</a>: Set upper bounds for MODEXP</li> EIP-7825</a>: Transaction Gas Limit Cap</li> EIP-7883</a>: ModExp Gas Cost Increase</li> EIP-7917</a>: Deterministic proposer lookahead</li> EIP-7918</a>: Blob base fee bounded by execution cost</li> EIP-7934</a>: RLP Execution Block Size Limit</li> EIP-7939</a>: Count leading zeros (CLZ) opcode</li> EIP-7951</a>: Precompile for secp256r1 Curve Support</li> </ul> Other EIPs</h4> EIP-7892</a>: Blob Parameter Only Hardforks</li> EIP-7642</a>: eth/69 - Drop pre-merge fields Client teams MUST support this EIP by the activation of the Fusaka network upgrade.</li> </ul> </li> EIP-7910</a>: eth_config JSON-RPC Method Client teams MUST support this JSON-RPC method by the activation of Fusaka network upgrade.</li> </ul> </li> EIP-7935</a>: Set default gas limit to 60M</li> </ul> Activation</h3> Network Name</th> Activation Epoch</th> Activation Timestamp</th> Activation Time (UTC)</th> Fork ID</th></tr></thead> Holešky</td> 165120</code></td> 1759308480</code></td> 2025-10-01 08:48:00</td> 0x783def52</code></td></tr> Sepolia</td> 272640</code></td> 1760427360</code></td> 2025-10-14 07:36:00</td> 0xe2ae4999</code></td></tr> Hoodi</td> 50688</code></td> 1761677592</code></td> 2025-10-28 18:53:12</td> 0xe7e0e7ff</code></td></tr> Mainnet</td> 411392</code></td> 1764798551</code></td> 2025-12-03 21:49:11</td> 0x5167e2a6</code></td></tr> </tbody></table> Blob Parameter Only Forks</h3> Blob Parameter Only (BPO) forks, defined in EIP-7892</a>, are scheduled alongside Fusaka to raise blob capacity without additional protocol changes.</p> BPO 1</h4> Network Name</th> Activation Epoch</th> Activation Timestamp</th> Activation Time (UTC)</th> Fork ID</th></tr></thead> Holešky</td> 166400</code></td> 1759800000</code></td> 2025-10-07 01:20:00</td> 0xa280a45c</code></td></tr> Sepolia</td> 274176</code></td> 1761017184</code></td> 2025-10-21 03:26:24</td> 0x56078a1e</code></td></tr> Hoodi</td> 52480</code></td> 1762365720</code></td> 2025-11-05 18:02:00</td> 0x3893353e</code></td></tr> Mainnet</td> 412672</code></td> 1765290071</code></td> 2025-12-09 14:21:11</td> 0xcba2a1c0</code></td></tr> </tbody></table> BPO 2</h4> Network Name</th> Activation Epoch</th> Activation Timestamp</th> Activation Time (UTC)</th> Fork ID</th></tr></thead> Holešky</td> 167936</code></td> 1760389824</code></td> 2025-10-13 21:10:24</td> 0x9bc6cb31</code></td></tr> Sepolia</td> 275712</code></td> 1761607008</code></td> 2025-10-27 23:16:48</td> 0x268956b6</code></td></tr> Hoodi</td> 54016</code></td> 1762955544</code></td> 2025-11-12 13:52:24</td> 0x23aa1351</code></td></tr> Mainnet</td> 419072</code></td> 1767747671</code></td> 2026-01-07 01:01:11</td> 0x07c9462e</code></td></tr> </tbody></table> Rationale</h2> This Meta EIP provides a global view of all changes included in the Fusaka network upgrade, as well as links to full specification.</p> Security Considerations</h2> None.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Hardfork Meta - Pectra 2024-01-18T00:00:00+00:00 Abstract</h2> This Meta EIP lists the EIPs Included in the Prague/Electra network upgrade. It follows the Dencun upgrade, documented in EIP-7569</a>.</p> Specification</h2> Included EIPs</h3> Core EIPs</h4> EIP-2537</a>: Precompile for BLS12-381 curve operations</li> EIP-2935</a>: Save historical block hashes in state</li> EIP-6110</a>: Supply validator deposits on chain</li> EIP-7002</a>: Execution layer triggerable exits</li> EIP-7251</a>: Increase the MAX_EFFECTIVE_BALANCE</li> EIP-7549</a>: Move committee index outside Attestation</li> EIP-7623</a>: Increase calldata cost</li> EIP-7685</a>: General purpose execution layer requests</li> EIP-7691</a>: Blob throughput increase</li> EIP-7702</a>: Set EOA account code</li> </ul> Other EIPs</h4> EIP-7840</a>: Add blob schedule to EL config files (Informational)</li> EIP-7642</a>: eth/69 - Drop pre-merge fields (Networking) While not necessary for the Pectra network upgrade, client teams MAY support EIP-7642 by the upgrade's activation and MUST support it by the next network upgrade.</li> </ul> </li> </ul> Full Specifications</h3> Consensus Layer</h4> EIP-6110, EIP-7002 EIP-7251, EIP-7549, EIP-7685 and EIP-7691 require changes to Ethereum's consensus layer. While the EIPs present an overview of these changes, the full specifications can be found in the specs/electra</code> and specs/_features</code> directories of the ethereum/consensus-specs</code> repository.</p> Execution Layer</h4> EIP-2537, EIP-2935, EIP-6110, EIP-7002, EIP-7623, EIP-7685, EIP-7702 and EIP-7840 require changes to Ethereum's execution layer. The EIPs fully specify those changes.</p> Activation</h3> Network Name</th> Activation Epoch</th> Activation Timestamp</th></tr></thead> Holešky</td> 115968</code></td> 1740434112</code></td></tr> Sepolia</td> 222464</code></td> 1741159776</code></td></tr> Hoodi</td> 2048</code></td> 1742999832</code></td></tr> Mainnet</td> 364032</code></td> 1746612311</code></td></tr> </tbody></table> Rationale</h2> This Meta EIP provides a global view of all changes included in the Prague/Electra network upgrade, as well as links to the full specification.</p> Security Considerations</h2> None.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Reserve Precompile Address Range for RIPs 2023-12-21T00:00:00+00:00 Abstract</h2> This EIP reserves precompile ranges to ensure there are no conflicts with those used by the Rollup Improvement Proposal (RIP) process.</p> Motivation</h2> As L2s begin to deploy RIPs, it is necessary to reserve an address range for use by the RIP process so as to ensure there are no conflicts between precompile addresses used by RIPs and EIPs.</p> Specification</h2> The address range between 0x0000000000000000000000000000000000000100</code> and 0x00000000000000000000000000000000000001ff</code> is reserved for use by the RIP process.</p> Rationale</h2> By reserving an address range for RIPs, it allows the RIP process to maintain its own registry of precompiles that are not (necessarily) deployed on L1 mainnet, the EIP process is freed from having to maintain a registry of RIP precompiles while still having 255 addresses for its own use.</p> Backwards Compatibility</h2> No backward compatibility issues found.</p> Security Considerations</h2> Nil.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Versioning Scheme for EIPs 2023-12-13T00:00:00+00:00 Abstract</h2> This EIP introduces a versioning scheme for Standards Track</a> EIPs by applying Semantic Versioning 2.0.0</a> based on changes made to the EIP's Specification section once its status has changed from Draft</code> to Review</code>.</p> Motivation</h2> EIP specifications often receive increasing modifications as more people review them, which is generally the case as client teams start implementing the specifications and the community gains a better understanding of their interaction with the rest of the protocol. These changes can be difficult to track. In particular, as EVM reference tests are often not maintained (and generally not released) by client teams or the EIP's authors, it can be difficult to ascertain whether a release of reference tests is sufficient, or even valid, to test the latest version of an EIP's specifications or the specification as currently implemented by a client.</p> This EIP proposes a semantic versioning scheme and an addition of a CHANGELOG section for EIPs that enables clearer communication within the community and allows the scope of a change to be ascertained at first glance. Furthermore, client implementation and testing toolchains can query EIP changes and automatically flag incompatibilities between the EIP's current specification and between client and test implementations.</p> Specification</h2> 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 and RFC 8174.</p> Once an EIP has moved out of "Draft" status, it MUST use the EIP versioning scheme outlined below. It MAY already use the versioning scheme in "Draft" status, which could be useful if the specification is actively being implemented. If more than one team is implementing the specification, it is RECOMMENDED to change the EIP's status to "Review".</p> The EIP versioning scheme MUST apply the following semantic versioning scheme of MAJOR.MINOR.PATCH</code>, based on Semantic Versioning 2.0.0</a>:</p> MAJOR</code>: A breaking change to the specifications that requires an implementation change and a change to the reference tests.</li> MINOR</code>: An addition to the specifications that requires additional implementation and additional test coverage to be added to the reference tests.</li> PATCH</code>: Any cosmetic change to, or a reformulation of, the EIP without specification change.</li> </ol> Before the EIP has moved out of Draft status and is being versioned, the version number MUST initially have MAJOR</code> version 0</code>.</p> For every change made to an EIP via a pull request (PR) made to ethereum/EIPs, a new entry MUST be added to the CHANGELOG section of the EIP that outlines the changes made within the PR. This CHANGELOG entry MUST include the following:</p> A new version number that follows the semantic versioning scheme outlined above.</li> The date when the changes were introduced.</li> The ethereum/EIPs PR number that implements the changes.</li> A line for each change made to the EIP's specifications that includes a short description of the change.</li> </ol> Additionally, the new version MUST be added to the metadata header of the EIP's markdown file (to a new "version" field), so that it may be easily parsed.</p> Tooling MUST be added to the ethereum/EIPs repository to help EIP authors apply the versioning scheme. This tooling SHOULD automatically:</p> Update the EIP version in the metadata header of the EIP's markdown file. If the EIP's status is changed from "Draft" to "Review", the version MUST be updated to 1.0.0</code>.</li> Add a new CHANGELOG entry based on the EIP Version and the PR's title.</li> </ol> To allow the tooling to make these changes, the EIP author MUST indicate the scope of change in one of the commit messages pushed to the PR's branch. The scope is indicated by starting a commit message with ("[Mm]ajor:</code>", "[Mm]inor:</code>", or "[Pp]atch</code>"). Multiple commit messages may contain scopes; in this case, the most severe scope change will be applied. If no scope can be detected in any of the commit messages, merging of the PR is blocked until such a commit message is pushed to the PR.</p> Rationale</h2> Making the version available in the EIP's metadata header allows for programmatic parsing of the version number by tooling used in reference tests or by client teams. Currently, the execution-spec-tests repository, which contains consensus tests for Ethereum execution clients, implements a rudimentary EIP version checker: EIP spec tests are required to declare the EIP's markdown file digest SHA that the test implementation was based on. The current value of the digest SHA is then polled via the Github API to verify that no changes have occurred since the test implementation. While this provides a warning to test implementers that the EIP has changed, it is clearly of limited use.</p> A richer versioning scheme, as defined by this EIP, can provide a lot of value to the testing toolchain. Client teams can provide an interface that reports the EIP version currently implemented and reference tests can specify the version they implement in generated tests as metadata. This allows a test runner to mark tests to xfail (expectedly fail) and issue a warning if the MAJOR</code> or MINOR</code> versions don't match. It would even be possible to automatically select the correct version of the reference tests to run against a client implementation, although given the pace of Ethereum development, it will likely be impractical to maintain and track multiple versions of tests.</p> Case Study</h3> This section explores how the versioning scheme would be applied to an existing EIPs recently under active development at the time of writing as an example.</p> The history of EIP-4788</a> contains many changes to its specification. EIP-4788 was updated to status "Review" on 2023-11-28. This case study assumes, however, that the EIP moved to status "Review" as of 2023-04-11 and updated to version 1.0.0 due to the start of a client team implementation.</p> Changelog</h4> 9.0.1 - 2023-09-26: Update ring buffer size rationale for new ring buffer size, #7786.</li> 9.0.0 - 2023-09-26: Post audit tweaks, #7672. Verify timestamp is non-zero.</li> Make HISTORY_BUFFER_LENGTH</code> prime (8191).</li> Load calldata once.</li> Update BEACON_ROOTS_ADDRESS</code>.</li> </ul> </li> 8.0.1 - 2023-08-28: 4788 cleanups, #7532.</li> 8.0.0 - 2023-08-24: Initial stab at v2, #7456. Require timestamp input to be exactly 32 bytes.</li> Revert if timestamp input does not match stored value (instead of returning zeroed word).</li> Remove precompile concept, use regular smart contract with provided bytecode.</li> </ul> </li> 7.0.3 - 2023-08-01: Mention genesis block with no existing beacon block root case, #7445.</li> 7.0.2 - 2023-07-07: Explicitly specify header schema, #7297.</li> 7.0.1 - 2023-07-07: Fix typo, #7293.</li> 7.0.0 - 2023-07-05: Bound precompile storage, #7178.</li> 6.0.1 - 2023-06-13: Clarify header and validity sections, #7179.</li> 6.0.0 - 2023-06-12: Update precompile address, #7173.</li> 5.0.0 - 2023-05-31: Key beacon roots by root, #7107.</li> 4.0.0 - 2023-05-24: Favor stateful precompile over opcode, #7065.</li> 3.0.0 - 2023-05-17: Send current slot from CL to avoid timestamp conversions, #7037.</li> 2.0.1 - 2023-05-15: Fix typo, #7005.</li> 2.0.0 - 2023-05-03: Update opcode to avoid clash, #6980.</li> 1.0.1 - 2023-04-13: Minor nits, #6870.</li> 1.0.0 - 2023-04-11: Use block roots; update to status "Draft", #6859. Update to "Draft" due to client implementation (NethermindEth/nethermind#5476).</li> Use block roots instead of state roots.</li> Roots are stored keyed by slot.</li> Use of ring buffer in state.</li> Use header timestamps to derive slot numbers, rather than consume additional header space.</li> </ul> </li> 0.2.1 - 2023-02-04: Update to status "Stagnant", #6432.</li> 0.2.0 - 2022-06-29: Rename "beacon block root" to "beacon state root", #5090.</li> 0.1.1 - 2022-05-06: Force usage of included LICENSE file, #5055.</li> 0.1.0 - 2022-02-17: Add EIP-4788: Beacon state root in EVM, #4788.</li> </ul> Backwards Compatibility</h2> It is not necessary to retroactively add a CHANGELOG or versions for versions of the EIP prior to the introduction of this EIP. Upon the next change to the EIP's Specification section, the author MUST introduce a CHANGELOG section and a version number that follows the semantic versioning scheme outlined above.</p> Security Considerations</h2> None.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Hardfork Meta Backfill - Berlin to Shapella 2023-12-01T00:00:00+00:00 Abstract</h2> Following Muir Glacier hard fork, Meta EIPs were abandoned in favor of other ways to track changes included in Ethereum network upgrades. This EIP aggregates the specifications for these upgrades, which themselves list the specific changes included. Specifically, it covers the Beacon Chain launch (Serenity Phase 0), Berlin, London, Altair, Arrow Glacier, Gray Glacier, The Merge (Paris + Bellatrix) and Shapella (Shanghai + Capella).</p> Motivation</h2> For many years, Ethereum used Meta EIPs to document network upgrades. Recently, consensus has formed around using them again. This EIP aggregates the network upgrades who did not have Meta EIPs and links out to their specifications.</p> Specification</h2> The network upgrades below are listed in order of activation. Upgrades to Ethereum's execution layer are marked "[EL]", and those to Ethereum's consensus layer are marked "[CL]".</p> Beacon Chain Launch - Serenity Phase 0 [CL]</h3> The full specifications for the Beacon Chain at launch can be found in the v1.0.0</code> release of the ethereum/consensus-specs</code> repository</a>. Additionally, EIP-2982</a> provides context on the Beacon Chain design and rationale for its mainnet parametrization.</p> Berlin [EL]</h3> The set of EIPs included in Berlin were originally specified in EIP-2070</a>, but then moved to the berlin.md</code></a> file of the ethereum/execution-specs</code> repository.</p> London [EL]</h3> The set of EIPs included in London are specified in the london.md</code></a> file of the ethereum/execution-specs</code> repository.</p> Altair [CL]</h3> The full specifications for the Altair network upgrade can be found in the v1.1.0</code> release of the ethereum/consensus-specs</code> repository</a>.</p> Arrow Glacier [EL]</h3> The set of EIPs included in Arrow Glacier are specified in thearrow-glacier.md</code></a> file of the ethereum/execution-specs</code> repository.</p> Gray Glacier [EL]</h3> The set of EIPs included in Gray Glacier are specified in thegray-glacier.md</code></a> file of the ethereum/execution-specs</code> repository.</p> The Merge</h3> The Merge was the first upgrade to require coordination between the execution and consensus layers. The consensus layer first activated the Bellatrix upgrade, which was followed by the activation of Paris on the execution layer.</p> Bellatrix [CL]</h4> The full specifications for the Bellatrix network upgrade can be found in the v1.2.0</code> release of the ethereum/consensus-specs</code> repository</a>.</p> Paris [EL]</h4> The set of EIPs included in Paris are specified in the paris.md</code></a> file of the ethereum/execution-specs</code> repository.</p> Shapella</h3> The Shapella upgrade was the first upgrade to activate at the same time on both the execution and consensus layers. To enable this, the upgrade activation mechanism on the execution layer was changed to use timestamps instead of blocks. This is described in EIP-6953</a> and EIP-6122</a>.</p> Shanghai [EL]</h4> The set of EIPs included in Shanghai are specified in theshanghai.md</code></a> file of the ethereum/execution-specs</code> repository.</p> Capella [CL]</h4> The full specifications for the Capella network upgrade can be found in the v1.3.0</code> release of the ethereum/consensus-specs</code> repository</a>.</p> Rationale</h2> The EIP repository is well known within the Ethereum community, and Meta EIPs have historically been useful to clearly list the EIPs included in a specific network upgrade.</p> While the specification process for the execution and consensus layers differ, there is value in having a single, harmonized, list of EIPs included in each upgrade, and for the lists for both layers to be part of the same repository.</p> Re-introducing Hardfork Meta EIPs enables this, and allows for de-duplication in cases where an EIP affects both the execution and consensus layer of Ethereum. This EIP covers the upgrades which did not use a Hardfork Meta EIP.</p> Backwards Compatibility</h2> No backward compatibility issues found.</p> Security Considerations</h2> None.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Hardfork Meta - Dencun 2023-12-01T00:00:00+00:00 Abstract</h2> This Meta EIP lists the EIPs included in the Dencun network upgrade across both Ethereum's execution and consensus layers. See EIP-7568</a> for the specifications of past upgrades.</p> Specification</h2> Included EIPs</h3> EIP-1153</a>: Transient storage opcodes</li> EIP-4788</a>: Beacon block root in the EVM</li> EIP-4844</a>: Shard Blob Transactions</li> EIP-5656</a>: MCOPY - Memory copying instruction</li> EIP-6780</a>: SELFDESTRUCT only in same transaction</li> EIP-7044</a>: Perpetually Valid Signed Voluntary Exits</li> EIP-7045</a>: Increase Max Attestation Inclusion Slot</li> EIP-7514</a>: Add Max Epoch Churn Limit</li> EIP-7516</a>: BLOBBASEFEE opcode</li> </ul> Full Specifications</h3> Consensus Layer</h4> EIPs 4788, 4844, 7044, 7045 and 7514 require changes to Ethereum's consensus layer. These are specified in the deneb</code> folder of the ethereum/consensus-specs</code> repository.</p> Execution Layer</h4> EIPs 1153, 4788, 4844, 5656, 6780 and 7516 require changes to Ethereum's execution layer. The EIPs fully specify the changes.</p> Activation</h3> Network Name</th> Activation Epoch</th> Activation Timestamp</th></tr></thead> Goerli</td> 231680</code></td> 1705473120</code></td></tr> Sepolia</td> 132608</code></td> 1706655072</code></td></tr> Holešky</td> 29696</code></td> 1707305664</code></td></tr> Mainnet</td> 269568</code></td> 1710338135</code></td></tr> </tbody></table> Note</strong>: rows in the table above will be filled as activation times are decided by client teams.</p> Rationale</h2> This Meta EIP provides a global view of all changes included in the Dencun network upgrade, as well as links to full specification.</p> Security Considerations</h2> None.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> ERC/EIP Repository split 2023-07-13T00:00:00+00:00 Abstract</h2> Describes the motivation and rational for splitting the EIP repositories into an EIP repository, targeting core ethereum changes and an ERC repository, targeting application layer specifications.</p> Motivation</h2> Long ago when the EIPs repository was created, there was a vision of a single home for all standards related to Ethereum. The community was small and most people were interacting at every level of the ecosystem. It made sense to combine application standards with core consensus changes.</p> Since then, the ecosystem has grown. Today, the chasm between application development and core development is wide. Fewer people are involved across the ecosystem (for better or worse); yet the repository remains unified.</p> For years, we've considered separating the repository. This would allow ERC and EIP specifications to evolve more naturally due to the independence. But it's always difficult to reach critical threshold to make a change like this happen. Each time we get lost in the details of the migration and the debate grinds progress to a halt.</p> Now that the Consensus Layer is also utilizing the EIP process, the cracks are becoming more visible. There are changes we could make to the process that might benefit them more, but because we also need to ensure the quality of ERCs, we are restricted.</p> There are also many more efforts to catalyze applications around the ERC process. Attempts have been made to develop working groups and review groups for certain ERC "categories" (a distinction that doesn't even technically exist because of the unified repo).</p> Specification</h2> This specification only details with the initial mechanism of the split. The particulars of how each repository will govern itself is out of scope for this EIP, as it is the motivating point of this EIP that the divergent needs of the community will require highly divergent methods.</p> All ERCs and Interface-category EIPs are removed from this repository and migrated to a new repo. The history should be intact so that repo should be forked of this one with the non-ERCs removed.</li> The new ERCs repository goes live and includes the changes from the script.</li> Setup ercs.ethereum.org subdomain and update the CI to point to the ERCs repo.</li> Set up a redirect for ERCs on eips.ethereum.org to go to the new website.</li> Create a unified document for editors to assign EIP/ERC numbers. EIPs and ERCs will no longer be based on an initial PR number but on a number incremented by the EIP editors of their respective repositories. EIPs will be assigned even numbers and ERCs will be assigned odd numbers. The exact timing of this migration is a policy decision of the editors.</li> </ol> The EIP repository will be associated with core protocol changes, specifically the kind that would be discussed in one of the AllCoreDevs calls; whereas the ERC repository will be affiliated with all remaining areas such as smart contract application interfaces, wallet standards, DeFi protocol standards, and all other such improvements that do not require core protocol changes.</p> This association is to persist across any other process changes the EIP editors may introduce such as working groups, topic groups, expert groups, special interest groups, splitting of the process, or other such changes. Any sub-groupings that includes core protocol changes would be associated with the EIP repository and other sub-groupings are associated with the ERC repository. Any such process change are out of scope of this EIP and are independent of the structural changes to the repositories specified in this EIP.</p> There may be further structural changes to repository layouts to accommodate more sub-groupings. Such proposals are out of scope of this EIP.</p> Rationale</h2> There are two major communities served by the EIP process that are highly divergent and very differentiated in their needs.</p> Let's consider the impact of specification ambiguity, the impacts are different based on the community. The core protocol community has a low tolerance for difference of implementation and a high penalty for specification ambiguity. An improperly implemented part of a new spec could cause the ethereum mainnet to split, possibly costing millions to billions of value lost to node operators as well as community members using the services offered by the Ethereum protocols. A poorly specified solidity interface, however, can be adapted and implemented in multiple compatible ways across any smart choosing to implement it. A missing RPC API (such as a configuration option specifying the number of decimals in the chains native currency) can have limited to zero impact on the rest of the community not choosing to use that wallet.</p> Timeframe for delivery of a feature is also similarly differentiated. A Core protocol EIP adjusting the gas cost for transaction data needs to be rolled out at a specific time uniformly across the network. Whereas a new RPC to support new semantics to gas estimation would not need uniform rollout across the Ethereum clients, and in fact would also need to be rolled out by service provides that provide RPC services for Ethereum networks. Wallets can use early support as a differentiating factor in their appeal to community members.</p> To address this divergence the AllCoreDevs call has adopted a lifecycle for EIPs different from the Draft -> Review -> Last Call -> Final lifecycle of the EIP repository. It would best be described as Draft -> Eligible for Inclusion -> Considered for Inclusion -> Testnet -> Mainnet. The EIPs also get slotted for a fork in the third step, a consideration that simply does not apply to a smart contract or wallet standard.</p> Several alternatives have been proposed, but the actual implementation only further underscores the specialization that each side of the split encounters.</p> Alternative: Working Groups</h3> One repeated concern of editors is that they often lack the technical experience to adequately judge if an EIP is complete and sound. Considering that EIPs covers wide variety of topics such as elliptic curve cryptography, VM performance, DeFi market dynamics, compression protocols, NFT Royalties, and consensus protocols it is impossible for a single editor to provide sensible feedback on every one of those topics.</p> When examining how the core protocol and ERC communities would approach the working group process, however, it underscores how different they would handle it. For core protocol change the working group would be one of the two AllCoreDevs meetings, either AllCoreDevs-Execution or AllCoreDevs-Consensus. And sometimes both. There is no EIP that would be shipped in mainnet that would not first be extensively considered by one of these two groups.</p> ERC proposals have no such standing groups. Wallet impacting changes may go through the AllWalletDevs group, but it is entirely possible for a wallet or group of wallets to collaborate on a protocol outside AllWalletDevs. Smart contract APIs have no such standing meeting.</p> The Working Group model, however, would be a critical social signal for the ERC community. It would signal a critical mass for a particular proposal issue if enough experts could get together to agree to review a set of changes.</p> While working groups are excellent for the ERC community, it is overhead for the core protocol community that would only add friction to an already established process with know governance checkpoints.</p> Alternative: Specialized Editors</h3> This alternative has already been implemented with the introduction of the eip-editors.yml</code> file. This allows for different groups of editors to review different types of EIPs.</p> There has been no measurable impact on the divergence of the community. Most categories have a significant overlap with other categories.</p> This alternative does not address the governance and workflow issues that the Core Protocol Developers would want to implement. All subgroups would still be subject to the same workflow as other groups.</p> Alternative: Pain unrelated to process divergences</h3> This is a catch-all for a number of proposals, from allowing discord links in discussion-to to allowing more freedom in external links.</p> While the theory that this may reduce the total amount of pain felt by users and editors, bringing the pain level down to a more acceptable level, this does not address the core divergence issue. Many of these pain relief proposals should probably be done anyway, weather or not the EIP repository splits.</p> Alternative: Replace EIP Editors with AI Chatbots</h3> Nobody wins in this proposal. We would instead end up debating training sets, competing implementations, and whether to use commercial providers. And that's if things go well.</p> AI chatbots, however, would not be able to compartmentalize the divergent needs of the multiple groups if all adjudication were to be handled with one model or one chat session. Higher quality output would be received if separate training repositories were used for each major functional area.</p> Alternatives are not Mutually Exclusive</h3> It is critical to note that most of the discussed alternatives all have merits and address important pain points. The adoption of a split should not be viewed as a rejection of those alternatives. To quote a famous internet meme "Why Not Both?"</p> Objection: This splits the ethereum community</h3> One objection is that splitting the repository would result in the community no longer being able to say "we are all of us Ethereum Magicians."</p> First it is important to note that such splits are already occurring. The AllCoreDevs call has split into a Consensus and Execution layer call. ACD calls no longer discuss client issues like wallet apis, the AllWalletDevs call has adopted those issues and has grown into user experience issues. Cross chain issues have been adopted by the Chain Agnostic Improvement Process (CAIP) group.</p> Rather than splitting this should be viewed as "sharding", where a sub-community of interest rallies around a shared sub issue, and by gathering are able to increase the total scope of the community. CAIP is a perfect example where operating separate from EIPs have allowed them to strengthen the ethereum community.</p> Is a single cell organism weakened when it grows large and then splits into two? Is an animal weakened when cells split and specialize into different tasks? It is this very act of division and specialization that allows it to accomplish the things that would be impossible as a single uniform cell.</p> Objection: This should be an EIP-1</a> proposal</h3> Since this is directly impacting the ERC process it should be documented in EIP-1</a> first.</p> As the old programming adage goes: "Refactor first before adding any new features." Adding new processes specific to the post-split governing docs would only confuse the existing process, adding special cases for one class of EIPs that don't apply to another. It is precisely this kind of problem the proposed split is aiming to change.</p> This is also valid grounds for a Meta category EIP, as how many and which repository to put a proposal in is core to the "procedures, guidelines, [and] changes to the decision-making process".</p> Some process changes that can be expected in a Core Protocol EIP may include:</p> Changing the work flow to add the Eligible for Inclusion/Considered for Inclusion stages to a pre-last-call EIP.</li> Adding test net and mainnet steps to the lifecycle</li> Adding a "fork" header to the RFCs section, for EIPs that are (or will be) implemented in a specific fork</li> Changing the testing section to a header link to reference tests</li> </ul> Some process change ERC may want to adopt:</p> A strong working group model and adding an optional "forming working group" step editors may require.</li> Add an "outdated" or "replaced" lifecycle step for EIPs that are abrogated by future specs.</li> Deputize single-eip reviewers for specific EIPs</li> </ul> Objection: Structural changes to a repository and process changes do not need to be bundled.</h3> It is possible to split the structure of the repositories separately from any EIP process changes related to this. Bundling the changes is unnecessary and such structure and process changes should be handled independently.</p> To accommodate this objection this EIP has been revised to only address structural changes in the repository and can be adapted to any other, independent, process changes and mapped onto those outcomes.</p> Backwards Compatibility</h2> Old Links</h3> Old ERC links pointing to the old url https://eips.ethereum.org/</code> will continue to work. Redirect instructions will be put into place to redirect to the new ERC repos for their corresponding location.</p> Stray Proposals</h3> ERC community members may continue to post new ERCs in the EIP proposal. Editors will be able to redirect them to the new repository. ERCs that do not respond to editor requests would not be merged anyway.</p> Security Considerations</h2> This proposal only addresses the EIP and ERC proposal process and is not expected to expose any new attack surfaces by virtue of its adoption.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Linter Scope 2023-06-20T00:00:00+00:00 Abstract</h2> Currently in practice EIP linter tools (EIPW, for example) will block a Pull Request for lint errors even if that lint errors was not introduced in that Pull Request. This EIP make it explicit that lint errors for untouched lines shall be considered ignorable except for status change.</p> Specification</h2> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</p> In an update to an EIP, A Pull Request SHOULD NOT be required to fix linter errors in untouched lines unless it's changing the Status of the EIP.</p> Rationale</h2> This policy allows micro contributions for anyone who just want to fix a typo or change a section of a section in a large EIP.</p> Security Considerations</h2> None</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Deprecate SELFDESTRUCT 2022-11-27T00:00:00+00:00 Abstract</h2> This EIP deprecates the SELFDESTRUCT</code> opcode and warns against its use. A breaking change to this functionality is likely to come in the future.</p> Motivation</h2> Discussions about how to change SELFDESTRUCT</code> are ongoing. But there is a strong consensus that something</em> will change.</p> Specification</h2> Documentation of the SELFDESTRUCT</code> opcode is updated to warn against its use and to note that a breaking change may be forthcoming.</p> Rationale</h2> As time goes on, the cost of doing something increases, because any change to SELFDESTRUCT</code> will be a breaking change.</p> The Ethereum Blog and other official sources have not provided any warning to developers about a potential forthcoming change.</p> Backwards Compatibility</h2> This EIP updates non-normative text in the Yellow Paper. No changes to clients is applicable.</p> Security Considerations</h2> None.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Process for Approving External Resources 2022-09-30T00:00:00+00:00 Abstract</h2> Ethereum improvement proposals (EIPs) occasionally link to resources external to this repository. This document sets out the requirements for origins that may be linked to, and the process for approving a new origin.</p> Specification</h2> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</p> Definitions</h3> Link</strong>: Any method of referring to a resource, including: markdown links, anchor tags (<a></code>), images, citations of books/journals, and any other method of referencing content not in the current resource.</li> Resource</strong>: A web page, document, article, file, book, or other media that contains content.</li> Origin</strong>: A publisher/chronicler of resources, like a standards body (eg. w3c) or a system of referring to documents (eg. Digital Object Identifier System).</li> </ul> Requirements for Origins</h3> Permissible origins MUST</strong> provide a method of uniquely identifying a particular revision of a resource. Examples of such methods may include git commit hashes, version numbers, or publication dates.</p> Permissible origins MUST</strong> have a proven history of availability. A origin existing for at least ten years and reliably serving resources would be sufficient—but not necessary—to satisfy this requirement.</p> Permissible origins MUST NOT</strong> charge a fee for accessing resources.</p> Origin Removal</h3> Any approved origin that ceases to satisfy the above requirements MUST</strong> be removed from EIP-1</a>. If a removed origin later satisfies the requirements again, it MAY be re-approved by following the process described in Origin Approval</a>.</p> Finalized EIPs (eg. those in the Final</code> or Withdrawn</code> statuses) SHOULD NOT</strong> be updated to remove links to these origins.</p> Non-Finalized EIPs MUST</strong> remove links to these origins before changing statuses.</p> Origin Approval</h3> Should the editors determine that an origin meets the requirements above, EIP-1 MUST</strong> be updated to include:</p> The name of the allowed origin;</li> The permitted markup and formatting required when referring to resources from the origin; and</li> A fully rendered example of what a link should look like.</li> </ul> Rationale</h2> Unique Identifiers</h3> If it is impossible to uniquely identify a version of a resource, it becomes impractical to track changes, which makes it difficult to ensure immutability.</p> Availability</h3> If it is possible to implement a standard without a linked resource, then the linked resource is unnecessary. If it is impossible to implement a standard without a linked resource, then that resource must be available for implementers.</p> Free Access</h3> The Ethereum ecosystem is built on openness and free access, and the EIP process should follow those principles.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> EIP Editor Handbook 2022-05-02T00:00:00+00:00 Introduction</h2> We, the Ethereum Improvement Proposal (EIP) Editors, maintain a repository of documents related to the Ethereum protocol and its ecosystem. Consider us both archivists</em> making sure the community as a whole does not lose its history, and a publisher</em> making sure interested parties can stay up-to-date with the latest proposals.</p> Mission</h2> What we Do</h3> Our mission is to serve the broad Ethereum community, both present and future, by:</p> Publishing Proposals</strong>: Making proposals, including their history and associated discussions available over the long term at no cost.</p> By doing so, we foster transparency and ensure that valuable insights from past proposals are accessible for future decision-making and learning.</p> </li> Facilitating Discussion</strong>: Providing a forum for discussing proposals open to anyone who wants to participate civilly.</p> By encouraging open dialogue and collaboration, we aim to harness the collective knowledge and expertise of the Ethereum community in shaping proposals.</p> </li> Upholding Quality</strong>: Upholding a measure of minimally-subjective quality for each proposal as defined by its target audience.</p> By adhering to defined criteria, we promote the development of high-quality and relevant proposals that drive the evolution of Ethereum.</p> </li> </ul> What we Don't</h3> On the other hand, we do not</em>:</p> Decide Winners</strong>: If there are multiple competing proposals, we will publish all of them. We are not in the business of deciding what is the right path for Ethereum, nor do we believe that there is One True Way to satisfy a need.</p> </li> Assert Correctness</strong>: While we might offer technical feedback from time to time, we are not experts nor do we vet every proposal in depth. Publishing a proposal is not an endorsement or a statement of technical soundness.</p> </li> Manage</strong>: We do not track implementation status, schedule work, or set fork dates or contents.</p> </li> Track Registries</strong>: We want all proposals to eventually become immutable, but a registry will never get there if anyone can keep adding items. To be clear, exhaustive and/or static lists are fine.</p> </li> Provide Legal Advice</strong>: Trademarks, copyrights, patents, prior art, and other legal matters are the responsibility of authors and implementers, not EIP Editors. We are not lawyers, and while we may occasionally make comments touching on these areas, we cannot guarantee any measure of correctness.</p> </li> </ul> Documenting all of the things we would not do is impossible, and the above are just a few examples. We reserve the right to do less work whenever possible!</p> Structure</h2> EIP Editors</h3> We, the Editors, consist of some number of EIP Editors and one Keeper of Consensus (or just Keeper for short) elected by and from the EIP Editors.</p> EIP Editors are responsible for governing the EIP process itself, electing a Keeper, and stewarding proposals.</p> The Keeper's two responsibilities (on top of their EIP Editor duties) are: to determine when rough consensus has been reached on a matter, and determine when/if it is appropriate to re-open an already settled matter.</p> Membership</h2> Anyone may apply to join as an EIP Editor. Specific eligibility requirements are left to individual current EIP Editors, but the general requirements are:</p> A strong belief in the above mission;</li> Proficiency with English (both written and spoken);</li> Reading and critiquing EIPs;</li> Participation in governance.</li> </ul> EIP Editors are expected to meet these requirements throughout their tenure, and not doing so is grounds for removal. Any member may delegate some or all of their responsibilities/powers to tools and/or to other people.</p> Making Decisions</h2> Informally</h3> For decisions that are unlikely to be controversial—especially for decisions affecting a single proposal—an EIP Editor may choose whatever option they deem appropriate in accordance with our mission.</p> Formally</h3> Electing a Keeper, adding/removing EIP Editors, and any possibly-controversial decisions must all be made using variations of this formal process.</p> Preparation</h4> Call for Input</h5> For any matter requiring a decision, a call for input must be published in writing to the usual channels frequented by EIP Editors.</p> Quorum</h5> Within thirty days of the call for input, to establish a valid quorum, all EIP Editors must express their opinion, vote (where appropriate), or lack thereof on the matter under consideration.</p> After thirty days from the call for input, if not all EIP Editors have responded, the quorum is reduced to the Editors that have responded. This deadline may be extended in exceptional situations.</p> Deciding</h4> Electing a Keeper of Consensus</h5> Any EIP Editor can call for an election for Keeper. Business continues as usual while the election is running. The EIP Editor with the most votes once quorum is met is named Keeper until the next election completes. If there is a tie, we'll randomly choose between the EIP Editors with the most votes, using a fair and agreed upon method (for example, a coin toss over a video call or a commit/reveal game of rock paper scissors.)</p> Adding an EIP Editor</h5> An EIP Editor is added once quorum is met, provided the candidate consents and no current EIP Editor objects.</p> Removing an EIP Editor</h5> An EIP Editor is involuntarily retired once quorum is met, provided no current EIP Editor (aside from the one being removed) objects. An EIP Editor may voluntarily leave their position at any time.</p> If the departing Editor was also the Keeper, an election for a new Keeper begins immediately.</p> Other Decisions</h5> All other decisions are made through a "rough consensus" process. This does not require all EIP Editors to agree, although this is preferred. In general, the dominant view of the Editors shall prevail. Dominance, in this process, is not determined by persistence or volume but rather a more general sense of agreement. Note that 51% does not mean "rough consensus" has been reached, and 99% is better than rough. It is up to the Keeper to determine if rough consensus has been reached. Every EIP Editor is entitled to have their opinion heard and understood before the Keeper makes that determination.</p> No one, not the EIP Editors and certainly not the Keeper, holds veto powers (except when adding/removing an Editor as defined above.) It is imperative that the EIP process evolve, albeit cautiously.</p> This section has been adapted from RFC 2418</a>.</em></p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Ephemeral Testnet Yolo 2020-04-19T00:00:00+00:00 Disclaimer: This is for testing basic infrastructure. It will be nuked. It is not for deploying dapps, nor does it define what will go into mainnet. For information on network upgrades, please follow the relevant meta EIPs and ongoing discussion on Ethereum/pm.</strong></p> Abstract</h2> The specification for Ephemeral Testnet Yolo. Clients who wish to sync need to implement the following features into their client. It is for testing basic infrastructure and will be nuked.</p> Specification</h2> Name: Yolo ID: YOLO-v1</code></p> EIP 2537 Commit Hash - 5edff4ae6ff62c7e0bbfad624fc3d0ba7dc84392</a></li> EIP 2315 Commit Hash - e8accf22cdc5562d6982c560080c6cd6b7f94867</a></li> </ul> [ ] Proposed - [x] Consensus to include.</em></p> Timeline</h2> Deployed: June 3rd 2020</li> </ul> Client Consensus -> Implementation</h2> YOLO-v1</p> Client</strong></th> Signal</th> Spec</th> Merged</th> Syncing</th></tr></thead> Besu</td> x</td> x</td> </td> </td></tr> EthereumJS</td> x</td> </td> </td> </td></tr> Geth</td> x</td> x</td> x</td> x</td></tr> Nethermind</td> x</td> x</td> </td> </td></tr> OpenEthereum</td> x</td> x</td> </td> </td></tr> Trinity</td> </td> </td> </td> </td></tr> </tbody></table> Signal</strong> - Client intends to participate. (You are on the bus)</em></p> Spec</strong> - Client is satisfied with the proposed specification. (You agree with the direction)</em></p> Merge</strong> - Changes are implemented in the client and configurable for YOLO. (You are ready to hit the gas and go)</em></p> Syncing</strong> Client syncs with the network</p> Syncing Instructions</h2> Geth</strong></p> Yolo V1 testnet is up and running https://yolonet.xyz/</li> Support is baked into Geth master branch via --yolov1</li> Genesis config json is at https://yolonet.xyz/yolo.json</li> EF bootnode at enode://9e1096aa59862a6f164994cb5cb16f5124d6c992cdbf4535ff7dea43ea1512afe5448dca9df1b7ab0726129603f1a3336b631e4d7a1a44c94daddd03241587f9@35.178.210.161:30303</li> Stats page secret is YOLOv1, with geth you can --ethstats='yournode:YOLOv1@stats.yolonet.xyz'</li> Faucet is unauthenticated, you can reach it from the dashboard</li> </ul> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> "Hardfork Meta: Muir Glacier" 2019-11-22T00:00:00+00:00 Abstract</h2> This meta-EIP specifies the changes included in the Ethereum hard fork named Muir Glacier. This hard fork addresses the impending Ice Age on Ethereum Mainnet and includes a commitment to solving the problems with the ice age more permanently.</p> Motivation</h2> Ethereum achieves a consistent block time due to its' difficulty retargeting algorithm. If a block-time is higher than 20 seconds, it reduces the difficulty, and if a block time is lower than 10 seconds, it increases the difficulty. This mechanism reaches typically an equilibrium of around 13-14 seconds. Included within this mechanism is something we refer to as the Difficulty Bomb or the Ice Age. It artificially adds to the difficulty in such a way that the retargeting mechanism, at some point, can not adapt to the increase, and we see increased block times throughout the network. The ice age increments every 100,000 blocks. It at first is barely noticeable, but once it is visible, there is a drastic effect on block-times in the network.</p> The primary problem with the Ice Age is that it is included in the complex mechanism that targets block times, which is an entirely separate in purpose. What is worse is due to being intwined with that algorithm, it is very difficult to simulate or predict its effect on the network. To predict the impact of the ice age, you must both make assumptions about the difficulty of main-net in the future, and predict the effect of changes in difficulty to the impact on the ice age and thus block-times.</p> This fork will push back the Iceage as far as far as is reasonable and will give us time to update the Iceage to no longer have these design problems. There are two solutions to consider within that time frame.</p> Update the mechanism so that behavior is predictable.</li> Remove the Iceage entirely</li> </ul> Specification</h2> Codename: Muir Glacier</li> </ul> Activation</h3> Block >= 9,200,000</code> on the Ethereum mainnet</li> Block >= 7,117,117</code> on the Ropsten testnet</li> Block >= N/A</code> on the Kovan testnet</li> Block >= N/A</code> on the Rinkeby testnet</li> Block >= N/A</code> on the Görli testnet</li> </ul> Included EIPs</h3> EIP-2384</a>: Istanbul/Berlin Difficulty Bomb Delay</li> </ul> Rationale</h2> I want to address the rationale for the intention of the Iceage and the implementation of the Iceage separately.</p> The original intentions of the ice age include:</strong></p> At the time of upgrades, inhibit unintentional growth of the resulting branching forks leading up to Eth 2.0. *</li> Encourage a prompt upgrade schedule for the path to Eth 2.0. *</li> Forces the community to come back into agreement repeatedly...and it gives whatever portion of the community that wants to a chance to fork off</li> Is a check for the Core Devs in the case that a decision is made to freeze the code base of clients without the blessing of the community.</li> </ul> *Note: None of these effects the Freedom to Fork. They are meant to encourage core-devs and the community to upgrade along with the network and prevent the case where sleeper forks remain dormant only later to be resurrected. The requirement for an active fork is to change a client in a way to respond to the ice age. This is in fact what Ethereum Classic has done.</p> This is not meant to be exhaustive, but the ideas above capture much of what has been written on the original intentions and process of creating the fork. Any additions to this list that need to be made, I am happy to include. Regardless, to effectively implement an updated design for the ice age, all of the intentions need to be revisited and clarified as part of any updates. This clarification will give a clear expectation for the community and core developers moving forward.</p> The implementation</strong></p> The existing implementation of the ice age, while it does work in practice, is unnecessarily complex to model and confusing to communicate to the community. Any updates to the design should be:</p> Easy to model the effect on the network</li> Easy to predict when it occurs</li> </ul> This fork would give us time to address the community to understand their priorities better as far as the intentions of the Ice Age, and give time for proposals for better mechanisms to achieve those goals.</p> POA Testnets</h3> Muir Glacier never activates on PoA chains – thus will have zero impact on forkid</a>.</p> Note on Issuance Reduction</h3> Previous Hardforks to address the Ice Age have also included reductions in the block reward from 5 Eth to 3 Eth to 2 Eth, respectively. In this case, there is no change in issuance, and the block reward remains 2 Eth per block.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> EIPs Eligible for Inclusion 2019-11-13T00:00:00+00:00 Simple Summary</h2> As part of an EIP centric forking model, this EIP tracks the first step in the approval process for any EIP to be included in a fork or upgrade. Specifically, the stage where the Core Developers vet the concept of an EIP and give a "green light" sufficient for EIP authors to move forward in development.</p> Abstract</h2> The pipeline for Core EIPs, per the EIP-Centric upgrade model, is as follows.</p> [ DRAFT ] -> [ ELLIGLE FOR INCLUSION ] -> [ IMPLEMENTATION ] -> [ TESTING ] -> [ ACCEPTED ] -> [ DEPLOYED ]</span></span></code></pre> This EIP documents all EIPs marked as Eligible For Inclusion</strong> by the All Core Devs. Typically to reach this stage, an EIP must be discussed in brief on an AllCoreDevs Call and motioned by rough consenses to be moved to this stage. Any additions to this list are required to provide a link to the meeting notes when this discussion and decision took place.</p> The requirements for Eligible for Inclusion</strong> is that the AllCoreDevs, representing the major clients and ecosystem stakeholders etc:</p> Are positive towards the EIP,</li> Would accept (well written) PRs to include the EIP into the codebase. So that it could be toggled on for testing…</li> …but not with an actual block number for activation</li> </ul> </li> </ul> Motivation</h2> Development of clear specifications and pull requests to existing Ethereum Clients is a large investment of time and resources. The state of Eligible for Inclusion</em> is a signal from the Ethereum Core Developers to an EIP Author validiating the idea behind an EIP and confirms investing their time further pursing it is worthwhile.</p> Specification</h2> EIP</th> Title</th> Pipeline Status</th> Date of Initial Decision</th> REF</th></tr></thead> EIP-663</td> Unlimited SWAP and DUP instructions</td> ELIGIBLE</td> 2019-11-01</td> 🔗</a></td></tr> EIP-1057</td> ProgPoW, a Programmatic Proof-of-Work</td> ELIGIBLE</td> 2019-11-01</td> 🔗</a></td></tr> EIP-1380</td> Reduced gas cost for call to self</td> ELIGIBLE</td> 2019-11-01</td> 🔗</a></td></tr> EIP-1559</td> Fee market change for ETH 1.0 chain</td> ELIGIBLE</td> 2019-11-01</td> 🔗</a></td></tr> EIP-1702</td> Generalized Account Versioning Scheme</td> ELIGIBLE</td> 2019-11-01</td> 🔗</a></td></tr> EIP-1962</td> EC arithmetic and pairings with runtime definitions</td> ELIGIBLE</td> 2019-11-01</td> 🔗</a></td></tr> EIP-1985</td> Sane limits for certain EVM parameters</td> ELIGIBLE</td> 2019-11-01</td> 🔗</a></td></tr> EIP-2046</td> Reduced gas cost for static calls made to precompiles</td> ELIGIBLE</td> 2019-11-01</td> 🔗</a></td></tr> EIP-2315</td> Simple Subroutines for the EVM</td> ELIGIBLE</td> 2020-02-21</td> 🔗</a></td></tr> EIP-2537</td> Precompile for BLS12-381 curve operations</td> ELIGIBLE</td> 2020-03-06</td> 🔗</a></td></tr> </tbody></table> Rationale</h2> EIP Number</strong></p> Title</strong></p> Pipeline Status</strong> : Show the current status in the context of the EIP centric model. The list is sorted by furthest along in the process.</p> Date of Initial Decision</strong> : Date of the initial decision for Eligibility for Inclusion</p> REF</strong> : Link to the decision on the AllCoreDevs Notes</p> References</h2> EIP Centric Forking Model Proposal by @holiman - https://notes.ethereum.org/@holiman/S1ELAYY7S?type=view</li> </ul> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> "Hardfork Meta: Berlin" 2019-05-20T00:00:00+00:00 Abstract</h2> This meta-EIP specifies the changes included in the Ethereum hardfork named Berlin.</p> Specification</h2> Codename: Berlin</li> </ul> In the current stage of coordination, the changes are tracked and discussed in the eth1.0-specs</a> repository. For an accurate status please refer to the berlin.md</code></a> file.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> "Hardfork Meta: Petersburg" 2019-01-21T00:00:00+00:00 Abstract</h2> This meta-EIP specifies the changes included in the Ethereum hardfork that removes EIP-1283</a> from Constantinople</a>.</p> Specification</h2> Codename: Petersburg</li> Aliases: St. Petersfork, Peter's Fork, Constantinople Fix</li> Activation: Block >= 7_280_000</code> on the Ethereum Mainnet</li> Block >= 4_939_394</code> on the Ropsten testnet</li> Block >= 10_255_201</code> on the Kovan testnet</li> Block >= 4_321_234</code> on the Rinkeby testnet</li> Block >= 0</code> on the Görli testnet</li> </ul> </li> Removed EIPs: EIP-1283</a>: Net gas metering for SSTORE without dirty maps</li> </ul> </li> </ul> If Petersburg</code> and Constantinople</code> are applied at the same block, Petersburg</code> takes precedence: with the net effect of EIP-1283 being disabled</em>.</p> If Petersburg</code> is defined with an earlier block number than Constantinople</code>, then there is no immediate effect</em> from the Petersburg</code> fork. However, when Constantinople</code> is later activated, EIP-1283 should be disabled</em>.</p> References</h2> The list above includes the EIPs that had to be removed from Constantinople due to a potential reentrancy attack vector</a>. Removing this was agreed upon at the All-Core-Devs call #53 in January 2019</a>.</li> https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/</li> </ol> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> "Hardfork Meta: Istanbul" 2019-01-04T00:00:00+00:00 Abstract</h2> This meta-EIP specifies the changes included in the Ethereum hardfork named Istanbul.</p> Specification</h2> Codename: Istanbul</li> </ul> Activation</h3> Block >= 9,069,000</code> on the Ethereum Mainnet</li> Block >= 6,485,846</code> on the Ropsten testnet</li> Block >= 14,111,141</code> on the Kovan testnet</li> Block >= 5,435,345</code> on the Rinkeby testnet</li> Block >= 1,561,651</code> on the Görli testnet</li> </ul> Included EIPs</h3> EIP-152</a>: Add Blake2 compression function F</code> precompile</li> EIP-1108</a>: Reduce alt_bn128 precompile gas costs</li> EIP-1344</a>: Add ChainID opcode</li> EIP-1884</a>: Repricing for trie-size-dependent opcodes</li> EIP-2028</a>: Calldata gas cost reduction</li> EIP-2200</a>: Rebalance net-metered SSTORE gas cost with consideration of SLOAD gas cost change</li> </ul> References</h2> Included EIPs were finalized in All Core Devs Call #68</a></li> https://medium.com/ethereum-cat-herders/istanbul-testnets-are-coming-53973bcea7df</li> </ol> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> "Hardfork Meta: Ethereum ProgPoW" 2018-11-16T00:00:00+00:00 Abstract</h2> This meta-EIP specifies the changes included in the alternative Ethereum hardfork named Ethereum ProgPoW.</p> Specification</h2> Codename: Ethereum ProgPoW</li> Aliases: N/A</li> Activation: Block >= 7280000</code> on the Ethereum mainnet</li> </ul> </li> Included EIPs: EIP-1057</a>: ProgPoW, a Programmatic Proof-of-Work</li> </ul> </li> </ul> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> "Hardfork Meta: Constantinople" 2018-04-20T00:00:00+00:00 Abstract</h2> This meta-EIP specifies the changes included in the Ethereum hardfork named Constantinople.</p> Specification</h2> Codename: Constantinople</li> Aliases: Metropolis/Constantinople, Metropolis part 2</li> Activation: Block >= 7_280_000</code> on the Ethereum Mainnet</li> Block >= 4,230,000</code> on the Ropsten testnet</li> Block >= 9_200_000</code> on the Kovan testnet</li> Block >= 3_660_663</code> on the Rinkeby testnet</li> </ul> </li> Included EIPs: EIP-145</a>: Bitwise shifting instructions in EVM</li> EIP-1014</a>: Skinny CREATE2</li> EIP-1052</a>: EXTCODEHASH Opcode</li> EIP-1234</a>: Delay difficulty bomb, adjust block reward</li> EIP-1283</a>: Net gas metering for SSTORE without dirty maps</li> </ul> </li> </ul> References</h2> The list above includes the EIPs discussed as candidates for Constantinople at the All Core Dev Constantinople Session #1</a>. See also Constantinople Progress Tracker</a>.</li> https://blog.ethereum.org/2019/02/22/ethereum-constantinople-st-petersburg-upgrade-announcement/</li> </ol> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Ethereum Network Upgrade Windows 2018-03-25T00:00:00+00:00 Simple Summary</h2> A proposal to define a limited number of annual time windows in which network upgrades (aka hard forks) should be performed within. Policies for scheduling network upgrades outside these windows are also described.</p> Abstract</h2> Four different weeks, spaced roughly evenly throughout the year, are targeted for network upgrades to be launched. Regular network upgrades should announce their intention to launch in a particular window early in their process and choose a block number four to six weeks prior to that window. If a network upgrade is cancelled then it would be rescheduled for the next window. Not all windows will be used. Priority upgrades outside the roadmap may be scheduled in the third week of any month, but such use is discouraged. Critical upgrades are scheduled as needed.</p> Motivation</h2> The aim of this EIP is to provide some level of regularity and predictability to the Ethereum network upgrade/hard fork process. This will allow service providers such as exchanges and node operators a predictable framework to schedule activities around. This also provides a framework to regularize the delivery of network upgrades.</p> Specification</h2> Scheduling is defined for three categories of network upgrades. First are Roadmap</code> network upgrades that include deliberate protocol improvements. Next are Priority</code> network updates, where there are technical reasons that necessitate a prompt protocol change but these reasons do not present a systemic risk to the protocol or the ecosystem. Finally, Critical</code> network upgrades are to address issues that present a systemic risk to the protocol or the ecosystem.</p> Roadmap Network Upgrades</h3> Roadmap network upgrades are network upgrades that are deliberate and measured to improve the protocol and ecosystem. Historical examples are Homestead, Byzantium, and Constantinople.</p> Roadmap network upgrades should be scheduled in one of four windows: the week with the third Wednesday in January, April, July, and October. When initiating a network upgrade or early in the planning process a particular window should be targeted.</p> Note to reviewers:</strong> The months and week chosen are to provide an initial recommendation and are easily modifiable prior to final call. They thread the needle between many third quarter and fourth quarter holidays.</p> </blockquote> Implementors are expected to have software for a Roadmap network upgrade ready two to four weeks prior to the upgrade. Hence a block number for the network upgrade should be chosen four to six weeks prior to the network upgrade window. Scheduling details such as whether this choice is made prior to or after testnet deployment are out of scope of this EIP.</p> Depending on the release cadence of Roadmap network upgrades some windows will not be used. For example if a six month release cadence is chosen a roadmap upgrade would not occur in adjacent upgrade windows. Hence for a six month cadence if a roadmap upgrade occurred in April then the July window would not be used for network upgrades.</p> If a planned roadmap upgrade needs to be rescheduled then strong consideration should be given to rescheduling the upgrade for the next window in three months time. For the case of a six month cadence this may cause releases to be in adjacent release windows. For a three month cadence the next network upgrade would be merged with the current upgrade or the next network upgrade would be delayed.</p> To be compatible with the scheduled release windows the cadence of the Roadmap Network Upgrades should be a multiple of three months. Whether it is three, six, nine, or more month cadence is out of scope of this EIP.</p> Priority Network Upgrades</h3> Priority network upgrades are reserved for upgrades that require more urgency than a roadmap network upgrade yet do not present a systemic risk to the network or the ecosystem. To date there have been no examples of a priority upgrade. Possible examples may include roadmap upgrades that need to occur in multiple upgrades or for security risks that have a existing mitigation in place that would be better served by a network upgrade. Another possible reason may be to defuse the difficulty bomb due to postponed roadmap upgrades.</p> Priority network upgrades are best launched in unused roadmap launch windows, namely the third week of January, April, July, and October. If necessary they may be launched in the third week of any month, but strong consideration and preference should be given to unused roadmap launch windows.</p> Priority network upgrades should be announced and a block chosen far enough in advance so major clients implementors can release software with the needed block number in a timely fashion. These releases should occur at least a week before the launch window. Hence priority launch windows should be chosen two to four weeks in advance.</p> Critical Network Upgrades</h3> Critical network upgrades are network upgrades that are designed to address systemic risks to the protocol or to the ecosystem. Historical examples include Dao Fork, Tangerine Whistle, and Spurious Dragon.</p> This EIP provides neither guidance nor restrictions to the development and deployment of these emergency hard forks. These upgrades are typically launched promptly after a solution to the systemic risk is agreed upon between the client implementors.</p> It is recommended that such upgrades perform the minimum amount of changes needed to address the issues that caused the need for the Critical network upgrade and that other changes be integrated into subsequent Priority and Roadmap network upgrades.</p> Network Upgrade Block Number Choice</h3> When choosing an activation block the number can be used to communicate the role of a particular network in the Ethereum Ecosystem. Networks that serve as a value store or are otherwise production grade have different stability concerns than networks that serve as technology demonstration or are explicitly designated for testing.</p> To date all Mainnet activation blocks have ended in three or more zeros, including Critical Network Upgrades. Ropsten and Kovan initially started with three zeros but switched to palindromic numbers. Rinkeby has always had palindromic activation blocks. Goerli has yet to perform a network upgrade.</p> To continue this pattern network upgrade activation block numbers for mainnet deployments and production grade networks should chose a number whose base 10 representation ends with three or more zeros.</p> For testnet and testing or development grades network operators are encouraged to choose a block activation number that is a palindrome in base 10.</p> Block numbers for Roadmap and Priority network upgrades should be chosen so that it is forecast to occur relatively close to Wednesday at 12:00 UTC+0 during the launch window. This should result in an actual block production occurring sometime between Monday and Friday of the chosen week.</p> Rationale</h2> The rationale for defining launch windows is to give business running Ethereum infrastructure a predictable schedule for when upgrades may or may not occur. Knowing when a upgrade is not going to occur gives the businesses a clear time frame within which to perform internal upgrades free from external changes. It also provides a timetable for developers and IT professionals to schedule time off against.</p> Backwards Compatibility</h2> Except for the specific launch windows the previous network upgrades would have complied with these policies. Homestead, Byzantium, and Constantinople would have been Roadmap Network Upgrades. There were no Priority Network Upgrades, although Spurious Dragon would have been a good candidate. Dao Fork was a Critical Network Upgrade in response to TheDao. Tangerine Whistle and Spurious Dragon were critical upgrades in response to the Shanghai Spam Attacks. Constantinople Fix (as it is termed in the reference tests) was in response to the EIP-1283 security issues.</p> If this policy were in place prior to Constantinople then the initial 2018 launch would likely have been bumped to the next window after the Ropsten testnet consensus failures. The EIP-1283 issues likely would have resulted in an out of window upgrade because of the impact of the difficulty bomb.</p> Implementation</h2> The windows in this EIP are expected to start after the Istanbul Network upgrade, which is the next planned Roadmap upgrade. Istanbul is currently slated for mainnet launch on 2019-10-16, which is compatible with the schedule in this EIP.</p> The Roadmap Upgrade windows starting with Istanbul would be as follows:</p> Block Target</th> Launch Week Range</th></tr></thead> 2019-10-16</td> 2019-10-14 to 2019-10-18</td></tr> 2020-01-15</td> 2020-01-13 to 2020-01-17</td></tr> 2020-04-15</td> 2020-04-13 to 2020-04-17</td></tr> 2020-07-15</td> 2020-07-13 to 2020-07-17</td></tr> 2020-10-21</td> 2020-10-19 to 2020-10-23</td></tr> 2021-01-20</td> 2021-01-18 to 2021-01-22</td></tr> 2021-04-21</td> 2021-04-19 to 2021-04-23</td></tr> 2021-07-21</td> 2021-07-19 to 2021-07-23</td></tr> 2021-10-20</td> 2021-10-18 to 2021-10-22</td></tr> 2022-01-19</td> 2022-01-17 to 2022-01-21</td></tr> 2022-04-20</td> 2022-04-18 to 2022-04-22</td></tr> 2022-07-20</td> 2022-07-18 to 2022-07-22</td></tr> 2022-10-19</td> 2022-10-17 to 2022-10-21</td></tr> </tbody></table> The Priority windows through next year, excluding Roadmap windows, are as follows:</p> Block Target</th> Launch Week Range</th></tr></thead> 2019-11-20</td> 2019-11-18 to 2019-11-22</td></tr> 2019-12-18</td> 2019-12-16 to 2019-12-20</td></tr> 2020-02-19</td> 2020-02-17 to 2020-02-21</td></tr> 2020-03-18</td> 2020-03-16 to 2020-03-20</td></tr> 2020-05-20</td> 2020-05-18 to 2020-05-22</td></tr> 2020-06-17</td> 2020-06-15 to 2020-06-19</td></tr> 2020-08-19</td> 2020-08-18 to 2020-08-21</td></tr> 2020-09-16</td> 2020-09-14 to 2020-09-18</td></tr> 2020-11-18</td> 2020-11-16 to 2020-11-20</td></tr> 2020-12-16</td> 2020-12-14 to 2020-12-18</td></tr> </tbody></table> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Standardized Ethereum Recovery Proposals 2018-02-02T00:00:00+00:00 Simple Summary</h2> Provide a standardized format for Ethereum Recovery Proposals (ERPs), which relate to recovery of certain classes of lost funds. Individual ERPs will follow the same process as any EIP, but will be formatted and evaluated in a standard way to ensure consistency and transparency.</p> This EIP does not advocate for or against the acceptance of any particular recovery proposals, nor would its acceptance alone result in any state changes to the blockchain.</strong></p> Abstract</h2> This proposal identifies a common solution method that can be used to address certain classes of lost funds on the Ethereum blockchain. In particular, it is intended to address cases where there is no disagreement about the right outcome between directly affected parties, enabling timely and low-risk solutions to many issues that have already occurred or are likely to occur again as Ethereum grows.</p> The solution method is divided into three parts:</p> Standards that will need to be met by any follow-on ERP in order to be considered for approval.</li> Recommendations for a common format for ERPs to use to specify a set of corrective actions that can be interpreted by clients.</li> Guidelines for client teams to implement code that can read, interpret, and apply the corrective actions at a specific block. The set of possible corrective actions is intentionally limited to minimize risk associated with any ERP.</li> </ol> Motivation</h2> The issue of fund recovery on the Ethereum blockchain is often controversial. Frozen fund recovery proposals are almost never successful due to the relatively ad-hoc nature of such requests and the subjectivity that is often required to evaluate the merits. This EIP attempts to remove these barriers by providing both a standardized format for fund recovery EIPs and an objective standard by which to measure future proposals.</p> Specification</h2> This EIP describes a common format to be used for a subclass of EIPs, referred to as ethereum recovery proposals (ERPs), that propose an irregular state change required to address a fund recovery scenario that cannot be addressed using the standard protocol. Each ERP will reference this EIP will follow the guidelines set out here.</p> The purpose of each ERP is (a) to clearly describe the issue to be corrected, (b) to describe why an irregular state change is both necessary and justified, and (c) to demonstrate that the proposed actions will achieve the ERP's objectives.</p> Each ERP will be required to use a standard format to represent the set of proposed state changes and must include a verification script that can reliably generate those changes. ERPs that do not meet (at least) these requirements will not be considered for approval.</p> Each ERP should contain the following items:</p> Preamble</strong>: EIP (RFC 822) header containing metadata about the ERP, including the EIP number, a short title (44 character maximum), and the real names (and optional contact information) for each author.</li> Simple Summary</strong>: A simplified and layman-accessible explanation of the ERP.</li> Detailed description</strong>: A human-readable description of the proposed corrective actions and the criteria used to determine the proposed actions.</li> Justification</strong>: A concise description of why the corrective actions are both reasonable and unlikely to be challenged by any directly affected party.</li> Verification script</strong>: A machine-readable script that outputs one State Change Object. The script should clearly implement the selection and action generating logic outlined in the description such that reviewers can independently re-generate an identical State Change Object.</li> State Change Object</strong>: The output of the verification script and the input to the ethereum clients. Primarily, it specifies the complete set of proposed state change actions.</li> Appendix (optional)</strong>: with supporting evidence. Attachments in the appendix may include documents verifying details specified as part of the recovery proposal description.</li> </ul> The following sections give more detailed descriptions of the expectations for the Justification, Verification Script, and the format of the State Change Object.</p> Justification</h3> A concise description of why this action is both reasonable (cannot be accomplished without an irregular state change) and unlikely to be challenged by a directly</em> affected party.</p> Considerable example</strong> (concise, includes supporting evidence, no negative impact): A crowdsale run by XYZ incorrectly published the testnet address of their crowdsale contract to their public website at the start of their crowdsale on Jan 19, 2018. 501 ETH was sent by 328 users on the mainnet to the incorrect address between block 4,235,987 and 4,236,050. See here for the testnet contract, and see here for the transactions to the same address on the mainnet. See here for a statement made by XYZ on their website. Because there is a contract at this address on the testnet and the corresponding nonce for the creator address has already been used on the mainnet, it is considered effectively impossible that anyone coincidentally holds the private key. We have verified that all transactions came from addresses with no associated code, so there should be no issue returning eth to the senders.</em></p> Insufficient example</strong> (not enough detail, no supporting evidence): We accidentally put the wrong contract address up on our website. Can you please refund any eth sent to 0x1234 back to the senders. Thanks.</em></p> Unacceptable example</strong> (not objective, one person’s word against another): I sent tokens to X for services and he did a lousy job. I want my money back, but he won’t refund me. Please help!!</em></p> Verification Script</h3> A machine-readable script that outputs a single State Change Object. This script should be implemented so that it is easily audited by a reviewer. Verification scripts should be javascript files that may use the web3.js</a> library.</p> There are a few guidelines for verification scripts:</p> Scripts should always be written to be as concise as reasonably possible, and anyone executing the verification script should review it first to verify that it does not contain any unsafe operations.</li> No verification script should ever require an unlocked ethereum wallet</li> The script should hardcode the highest block included during execution (otherwise the results may differ between runs).</li> </ul> The purpose of the ERP Verification script is to unambiguously specify (through code) the criteria used to compute the set of State Change Actions. The script’s output, as described above, will be the input used by all Ethereum clients. Client teams should avoid manually pre-processing the artifact or using the artifact to simply guide changes in the code. Instead, the artifact should be bundled with the client and processed directly by the client at the specified block. This will minimize the amount of client effort required for each ERP and help to ensure compatibility between clients. We anticipate that some ERP Verification scripts may be trivial, but we recommend their inclusion for consistency.</p> State Change Object</h3> The State Change Object is a standard format that will be interpretable by all Ethereum clients.</p> It is a single JSON object containing the following fields:</p> erpId</strong>: A string identifier for this ERP (likely the associated EIP number, e.g. “EIP-1234”). This will be converted from ascii to a hex string, then added as extra data on the target block.</li> targetBlock</strong>: The block at which the stateChange should be applied. Clients would use this to determine when a set of state changes should occur</li> actions</strong>: An array of State Change Actions.</li> metadata</strong> sourceBlock</strong>: The highest block considered by the script when it was run.</li> version</strong>: The version of the verification script when it was run.</li> </ul> </li> </ul> State Change Actions</h3> A State Change action is a JSON object that includes a “type” field and a set of “data” fields, where the contents of the data fields are dependent on the type and must follow the schema defined for that type. This allows clients to support a limited set of operations initially and add more based on a subsequent EIP if needed. Support for the following action types should be implemented by clients upon adoption of this EIP:</p> weiTransfer</h4> The weiTransfer</code> action transfers ETH from one address to another.</p> Data fields</em></p> type</strong> (string</em>): weiTransfer</code></li> fromAddress</strong> (hex string</em>): The address from which ETH should be transferred</li> toAddress</strong> (hex string</em>): The address to which ETH should be sent</li> value</strong> (decimal string</em>): The amount of ETH to be transferred, in units of wei. The value must be a whole number greater than zero.</li> </ul> storeCode</h4> The storeCode</code> action stores the given code at the given address.</p> Data fields</em></p> type</strong> (string</em>): storeCode</code></li> toAddress</strong> (hex string</em>): The address to which the contract should be restored.</li> expectedCodeHash</strong> (hex string</em>): the expected hash of the code already at the toAddress.The empty string should be used if no code is expected at the toAddress. In all other cases, the “0x” prefix is optional.</li> code</strong> (hex string</em>): the new bytecode associated with the contract</li> </ul> Appendix (Optional)</h3> The appendix can include additional supporting evidence or attachments that will help reviewers understand or verify the claims made in the ERP.</p> For the storeCode operation, it should include the proposed contract source (e.g. Solidity) as well as the other details required such that a reviewer can compile the source and generate the same bytecode. It should also include the source that was originally stored at that address, if possible/applicable. If the two contracts are not identical, changes should be noted. If they are identical, the author should indicate why no changes are necessary (this is unlikely). Additionally, any relevant reviews, audits, and test cases should be included to the extent that they address the issues encountered with the original contract.</p> If accepted, an ERP could easily compile the block at while the changes are to take place, and the source of the actions (which would be the output of the script, in a standardized object output). These can be bundled with the client for seamless execution.</p> ERP Approval Process</h2> ERPs are a subclass of EIPs and will, therefore, follow the same approval process.</p> Testing</h3> The ERP authors are currently seeking feedback from client teams about the proper testing procedures</em></p> Ethereum Client Implementation</h2> Clients that choose to adopt the proposal outlined in this EIP will implement a module that scans a designated directory for SCO files (each time the client process launches) to construct a mapping between target blocks and SCO file names. When starting work on a new block, clients should first consult the set of SCO target blocks discovered and determine if there are any recovery actions required for the current block.</p> E.g. in this example, erpsByTargetBlock</code> is the mapping between the target block number associated with each ERP's State Change Object and a reference (i.e. file name) to the resource with the actual data.</p> if (erpsByTargetBlock.get(currentBlock) != null) {</span></span> try {</span></span> applyRecoveryActions(erpsByTargetBlock.get(currentBlock));</span></span> }</span></span> catch (e) {</span></span> // recovery actions should be treated as a batch. </span></span> // If one fails, they all fail.</span></span> }</span></span> }</span></span> </span> </span> // continue with normal block processing...</span></span></code></pre> The applyRecoveryActions</code> method must apply the recovery actions in the same order as they are stored in the SCO file. Clients are responsible for ensuring that no State Change Action will result in an account transferring an amount that is greater than its current balance. The toAddress</code> for both weiTransfer</code> and storeCode</code> should always be a valid address (i.e. never 0x0</code>).</p> Additionally, each block affected by an ERP should include extra data to indicate that the state change occurred. The extra data included in the block should be the erpId found in the SCO file, converted to hex (i.e. hexStringToBytes(asciiToHex(erpId))</code>). Clients should also validate that the expected header appears in the target block if the block is received from a peer.</p> The ERP should link to pull requests for each client repository, and these pull requests should link back to the ERP and also contain its EIP preamble and summary.</p> Each PR associated with an ERP should consist of a single file (the SCO file) added to the client’s designated SCO directory. No additional client code should be required.</p> Limitations of this EIP</h3> This EIP is focused on standardizing how recovery proposals can be formatted, to optimize readability and eliminate or minimize as much as possible the potential for mistakes or intentional abuses.</p> The following are considered out of scope from this EIP:</p> Which fund recovery proposals, if any, should be accepted for implementation.</li> How common classes of recovery proposal plaintiff may organize ERPs representing a collective group of individual parties</li> </ul> Rationale</h2> The primary consideration for the approach described above was to minimize the amount of risk associated with recovery actions that would otherwise not have a viable solution. A secondary consideration was to standardize the format used in the proposals for recovery actions.</p> First, including a verification script guarantees that the way in which the recovery actions were determined is unambiguous. This does not mean that the recovery actions are necessarily correct, only that the logic used to determine them is fully specified and auditable.</p> Second, requiring that the output of the verification script is directly interpretable by client programs minimizes the work necessary for each client to adopt a particular ERP. It also reduces the risk that two clients will make different decisions about the implementation of a particular ERP.</p> Third, action types are intentionally limited and inflexible, which reduces the likelihood of unintended consequences or maliciously constructed files affecting the blockchain state. The format is easily extensible with new actions types if needed but that would require a separate EIP.</p> Implementation</h2> A reference implementation has been written for the EthereumJ platform. See the pull request here</a>.</p> ERP Examples</h2> This section will include examples and SCO resource files, as well as a brief tutorial on how to test using a private testnet.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> "Hardfork Meta: DAO Fork" 2017-11-26T00:00:00+00:00 Abstract</h2> This documents the changes included in the hard fork named "DAO Fork". Unlike other hard forks, the DAO Fork did not change the protocol; all EVM opcodes, transaction format, block structure, and so on remained the same. Rather, the DAO Fork was an "irregular state change" that transferred ether balances from a list of accounts ("child DAO" contracts) into a specified account (the "WithdrawDAO" contract).</p> Specification</h2> Codename: DAO Fork</li> Activation: Block == 1,920,000 on Mainnet</li> </ul> </li> </ul> See references [1] and [2] for the original, full specification. It is summarized here for convenience.</p> At block 1880000, the following accounts are encoded into a list L</code>:</p> The DAO (0xbb9bc244d798123fde783fcc1c72d3bb8c189413</code>)</li> its extraBalance (0x807640a13483f8ac783c557fcdf27be11ea4ac7a</code>)</li> all children of the DAO creator (0x4a574510c7014e4ae985403536074abe582adfc8</code>)</li> and the extraBalance of each child</li> </ul> Reference list L</summary> 0xd4fe7bc31cedb7bfb8a345f31e668033056b2728,</span></span> 0xb3fb0e5aba0e20e5c49d252dfd30e102b171a425,</span></span> 0x2c19c7f9ae8b751e37aeb2d93a699722395ae18f,</span></span> 0xecd135fa4f61a655311e86238c92adcd779555d2,</span></span> 0x1975bd06d486162d5dc297798dfc41edd5d160a7,</span></span> 0xa3acf3a1e16b1d7c315e23510fdd7847b48234f6,</span></span> 0x319f70bab6845585f412ec7724b744fec6095c85,</span></span> 0x06706dd3f2c9abf0a21ddcc6941d9b86f0596936,</span></span> 0x5c8536898fbb74fc7445814902fd08422eac56d0,</span></span> 0x6966ab0d485353095148a2155858910e0965b6f9,</span></span> 0x779543a0491a837ca36ce8c635d6154e3c4911a6,</span></span> 0x2a5ed960395e2a49b1c758cef4aa15213cfd874c,</span></span> 0x5c6e67ccd5849c0d29219c4f95f1a7a93b3f5dc5,</span></span> 0x9c50426be05db97f5d64fc54bf89eff947f0a321,</span></span> 0x200450f06520bdd6c527622a273333384d870efb,</span></span> 0xbe8539bfe837b67d1282b2b1d61c3f723966f049,</span></span> 0x6b0c4d41ba9ab8d8cfb5d379c69a612f2ced8ecb,</span></span> 0xf1385fb24aad0cd7432824085e42aff90886fef5,</span></span> 0xd1ac8b1ef1b69ff51d1d401a476e7e612414f091,</span></span> 0x8163e7fb499e90f8544ea62bbf80d21cd26d9efd,</span></span> 0x51e0ddd9998364a2eb38588679f0d2c42653e4a6,</span></span> 0x627a0a960c079c21c34f7612d5d230e01b4ad4c7,</span></span> 0xf0b1aa0eb660754448a7937c022e30aa692fe0c5,</span></span> 0x24c4d950dfd4dd1902bbed3508144a54542bba94,</span></span> 0x9f27daea7aca0aa0446220b98d028715e3bc803d,</span></span> 0xa5dc5acd6a7968a4554d89d65e59b7fd3bff0f90,</span></span> 0xd9aef3a1e38a39c16b31d1ace71bca8ef58d315b,</span></span> 0x63ed5a272de2f6d968408b4acb9024f4cc208ebf,</span></span> 0x6f6704e5a10332af6672e50b3d9754dc460dfa4d,</span></span> 0x77ca7b50b6cd7e2f3fa008e24ab793fd56cb15f6,</span></span> 0x492ea3bb0f3315521c31f273e565b868fc090f17,</span></span> 0x0ff30d6de14a8224aa97b78aea5388d1c51c1f00,</span></span> 0x9ea779f907f0b315b364b0cfc39a0fde5b02a416,</span></span> 0xceaeb481747ca6c540a000c1f3641f8cef161fa7,</span></span> 0xcc34673c6c40e791051898567a1222daf90be287,</span></span> 0x579a80d909f346fbfb1189493f521d7f48d52238,</span></span> 0xe308bd1ac5fda103967359b2712dd89deffb7973,</span></span> 0x4cb31628079fb14e4bc3cd5e30c2f7489b00960c,</span></span> 0xac1ecab32727358dba8962a0f3b261731aad9723,</span></span> 0x4fd6ace747f06ece9c49699c7cabc62d02211f75,</span></span> 0x440c59b325d2997a134c2c7c60a8c61611212bad,</span></span> 0x4486a3d68fac6967006d7a517b889fd3f98c102b,</span></span> 0x9c15b54878ba618f494b38f0ae7443db6af648ba,</span></span> 0x27b137a85656544b1ccb5a0f2e561a5703c6a68f,</span></span> 0x21c7fdb9ed8d291d79ffd82eb2c4356ec0d81241,</span></span> 0x23b75c2f6791eef49c69684db4c6c1f93bf49a50,</span></span> 0x1ca6abd14d30affe533b24d7a21bff4c2d5e1f3b,</span></span> 0xb9637156d330c0d605a791f1c31ba5890582fe1c,</span></span> 0x6131c42fa982e56929107413a9d526fd99405560,</span></span> 0x1591fc0f688c81fbeb17f5426a162a7024d430c2,</span></span> 0x542a9515200d14b68e934e9830d91645a980dd7a,</span></span> 0xc4bbd073882dd2add2424cf47d35213405b01324,</span></span> 0x782495b7b3355efb2833d56ecb34dc22ad7dfcc4,</span></span> 0x58b95c9a9d5d26825e70a82b6adb139d3fd829eb,</span></span> 0x3ba4d81db016dc2890c81f3acec2454bff5aada5,</span></span> 0xb52042c8ca3f8aa246fa79c3feaa3d959347c0ab,</span></span> 0xe4ae1efdfc53b73893af49113d8694a057b9c0d1,</span></span> 0x3c02a7bc0391e86d91b7d144e61c2c01a25a79c5,</span></span> 0x0737a6b837f97f46ebade41b9bc3e1c509c85c53,</span></span> 0x97f43a37f595ab5dd318fb46e7a155eae057317a,</span></span> 0x52c5317c848ba20c7504cb2c8052abd1fde29d03,</span></span> 0x4863226780fe7c0356454236d3b1c8792785748d,</span></span> 0x5d2b2e6fcbe3b11d26b525e085ff818dae332479,</span></span> 0x5f9f3392e9f62f63b8eac0beb55541fc8627f42c,</span></span> 0x057b56736d32b86616a10f619859c6cd6f59092a,</span></span> 0x9aa008f65de0b923a2a4f02012ad034a5e2e2192,</span></span> 0x304a554a310c7e546dfe434669c62820b7d83490,</span></span> 0x914d1b8b43e92723e64fd0a06f5bdb8dd9b10c79,</span></span> 0x4deb0033bb26bc534b197e61d19e0733e5679784,</span></span> 0x07f5c1e1bc2c93e0402f23341973a0e043f7bf8a,</span></span> 0x35a051a0010aba705c9008d7a7eff6fb88f6ea7b,</span></span> 0x4fa802324e929786dbda3b8820dc7834e9134a2a,</span></span> 0x9da397b9e80755301a3b32173283a91c0ef6c87e,</span></span> 0x8d9edb3054ce5c5774a420ac37ebae0ac02343c6,</span></span> 0x0101f3be8ebb4bbd39a2e3b9a3639d4259832fd9,</span></span> 0x5dc28b15dffed94048d73806ce4b7a4612a1d48f,</span></span> 0xbcf899e6c7d9d5a215ab1e3444c86806fa854c76,</span></span> 0x12e626b0eebfe86a56d633b9864e389b45dcb260,</span></span> 0xa2f1ccba9395d7fcb155bba8bc92db9bafaeade7,</span></span> 0xec8e57756626fdc07c63ad2eafbd28d08e7b0ca5,</span></span> 0xd164b088bd9108b60d0ca3751da4bceb207b0782,</span></span> 0x6231b6d0d5e77fe001c2a460bd9584fee60d409b,</span></span> 0x1cba23d343a983e9b5cfd19496b9a9701ada385f,</span></span> 0xa82f360a8d3455c5c41366975bde739c37bfeb8a,</span></span> 0x9fcd2deaff372a39cc679d5c5e4de7bafb0b1339,</span></span> 0x005f5cee7a43331d5a3d3eec71305925a62f34b6,</span></span> 0x0e0da70933f4c7849fc0d203f5d1d43b9ae4532d,</span></span> 0xd131637d5275fd1a68a3200f4ad25c71a2a9522e,</span></span> 0xbc07118b9ac290e4622f5e77a0853539789effbe,</span></span> 0x47e7aa56d6bdf3f36be34619660de61275420af8,</span></span> 0xacd87e28b0c9d1254e868b81cba4cc20d9a32225,</span></span> 0xadf80daec7ba8dcf15392f1ac611fff65d94f880,</span></span> 0x5524c55fb03cf21f549444ccbecb664d0acad706,</span></span> 0x40b803a9abce16f50f36a77ba41180eb90023925,</span></span> 0xfe24cdd8648121a43a7c86d289be4dd2951ed49f,</span></span> 0x17802f43a0137c506ba92291391a8a8f207f487d,</span></span> 0x253488078a4edf4d6f42f113d1e62836a942cf1a,</span></span> 0x86af3e9626fce1957c82e88cbf04ddf3a2ed7915,</span></span> 0xb136707642a4ea12fb4bae820f03d2562ebff487,</span></span> 0xdbe9b615a3ae8709af8b93336ce9b477e4ac0940,</span></span> 0xf14c14075d6c4ed84b86798af0956deef67365b5,</span></span> 0xca544e5c4687d109611d0f8f928b53a25af72448,</span></span> 0xaeeb8ff27288bdabc0fa5ebb731b6f409507516c,</span></span> 0xcbb9d3703e651b0d496cdefb8b92c25aeb2171f7,</span></span> 0x6d87578288b6cb5549d5076a207456a1f6a63dc0,</span></span> 0xb2c6f0dfbb716ac562e2d85d6cb2f8d5ee87603e,</span></span> 0xaccc230e8a6e5be9160b8cdf2864dd2a001c28b6,</span></span> 0x2b3455ec7fedf16e646268bf88846bd7a2319bb2,</span></span> 0x4613f3bca5c44ea06337a9e439fbc6d42e501d0a,</span></span> 0xd343b217de44030afaa275f54d31a9317c7f441e,</span></span> 0x84ef4b2357079cd7a7c69fd7a37cd0609a679106,</span></span> 0xda2fef9e4a3230988ff17df2165440f37e8b1708,</span></span> 0xf4c64518ea10f995918a454158c6b61407ea345c,</span></span> 0x7602b46df5390e432ef1c307d4f2c9ff6d65cc97,</span></span> 0xbb9bc244d798123fde783fcc1c72d3bb8c189413,</span></span> 0x807640a13483f8ac783c557fcdf27be11ea4ac7a</span></span></code></pre></details> At the beginning of block 1920000, all ether throughout all accounts in L</code> will be transferred to a contract deployed at 0xbf4ed7b27f1d666546e30d74d50d173d20bca754</code>. The contract was created from the following Solidity code (compiler version v0.3.5-2016-07-01-48238c9</code>):</p> //</span> Deployed on mainnet at 0xbf4ed7b27f1d666546e30d74d50d173d20bca754</span></span> </span> contract</span> DAO</span> {</span></span> function</span> balanceOf</span>(</span>address</span> addr</span>)</span> returns</span> (</span>uint</span>)</span>;</span></span> function</span> transferFrom</span>(</span>address</span> from</span>,</span> address</span> to</span>,</span> uint</span> balance</span>)</span> returns</span> (</span>bool</span>)</span>;</span></span> uint</span> public</span> totalSupply</span>;</span></span> }</span></span> </span> contract</span> WithdrawDAO</span> {</span></span> DAO </span>constant</span> public</span> mainDAO </span>=</span> DAO</span>(</span>0xbb9bc244d798123fde783fcc1c72d3bb8c189413</span>)</span>;</span></span> address</span> public</span> trustee </span>=</span> 0xda4a4626d3e16e094de3225a751aab7128e96526</span>;</span></span> </span> function</span> withdraw</span>(</span>)</span>{</span></span> uint</span> balance </span>=</span> mainDAO</span>.</span>balanceOf</span>(</span>msg.sender</span>)</span>;</span></span> </span> if</span> (</span>!</span>mainDAO</span>.</span>transferFrom</span>(</span>msg.sender</span>,</span> this</span>,</span> balance</span>)</span> ||</span> !</span>msg.sender</span>.</span>send</span>(</span>balance</span>)</span>)</span></span> throw</span>;</span></span> }</span></span> </span> function</span> trusteeWithdraw</span>(</span>)</span> {</span></span> trustee</span>.</span>send</span>(</span>(</span>this</span>.</span>balance </span>+</span> mainDAO</span>.</span>balanceOf</span>(</span>this</span>)</span>)</span> -</span> mainDAO</span>.</span>totalSupply</span>(</span>)</span>)</span>;</span></span> }</span></span> }</span></span></code></pre> This contract is deployed on Mainnet in block 1883496 in transaction hash 0xfeae1ff3cf9b6927d607744e3883ea105fb16042d4639857d9cfce3eba644286</code>. The deployment code of the contract is:</p> 0x606060405273da4a4626d3e16e094de3225a751aab7128e96526600060006101000a81548173ffffffffffffffffffffffffffffffffffffffff02191690830217905550610462806100516000396000f360606040526000357c0100000000000000000000000000000000000000000000000000000000900480632e6e504a1461005a5780633ccfd60b14610069578063eedcf50a14610078578063fdf97cb2146100b157610058565b005b61006760048050506100ea565b005b6100766004805050610277565b005b6100856004805050610424565b604051808273ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b6100be600480505061043c565b604051808273ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b600060009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16600073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166318160ddd604051817c01000000000000000000000000000000000000000000000000000000000281526004018090506020604051808303816000876161da5a03f115610002575050506040518051906020015073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166370a0823130604051827c0100000000000000000000000000000000000000000000000000000000028152600401808273ffffffffffffffffffffffffffffffffffffffff1681526020019150506020604051808303816000876161da5a03f11561000257505050604051805190602001503073ffffffffffffffffffffffffffffffffffffffff16310103604051809050600060405180830381858888f19350505050505b565b600073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166370a0823133604051827c0100000000000000000000000000000000000000000000000000000000028152600401808273ffffffffffffffffffffffffffffffffffffffff1681526020019150506020604051808303816000876161da5a03f1156100025750505060405180519060200150905073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166323b872dd333084604051847c0100000000000000000000000000000000000000000000000000000000028152600401808473ffffffffffffffffffffffffffffffffffffffff1681526020018373ffffffffffffffffffffffffffffffffffffffff16815260200182815260200193505050506020604051808303816000876161da5a03f1156100025750505060405180519060200150158061041657503373ffffffffffffffffffffffffffffffffffffffff16600082604051809050600060405180830381858888f19350505050155b1561042057610002565b5b50565b73bb9bc244d798123fde783fcc1c72d3bb8c18941381565b600060009054906101000a900473ffffffffffffffffffffffffffffffffffffffff168156</span></span></code></pre> This deployment results in the runtime bytecode:</p> 0x60606040526000357c0100000000000000000000000000000000000000000000000000000000900480632e6e504a1461005a5780633ccfd60b14610069578063eedcf50a14610078578063fdf97cb2146100b157610058565b005b61006760048050506100ea565b005b6100766004805050610277565b005b6100856004805050610424565b604051808273ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b6100be600480505061043c565b604051808273ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b600060009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16600073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166318160ddd604051817c01000000000000000000000000000000000000000000000000000000000281526004018090506020604051808303816000876161da5a03f115610002575050506040518051906020015073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166370a0823130604051827c0100000000000000000000000000000000000000000000000000000000028152600401808273ffffffffffffffffffffffffffffffffffffffff1681526020019150506020604051808303816000876161da5a03f11561000257505050604051805190602001503073ffffffffffffffffffffffffffffffffffffffff16310103604051809050600060405180830381858888f19350505050505b565b600073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166370a0823133604051827c0100000000000000000000000000000000000000000000000000000000028152600401808273ffffffffffffffffffffffffffffffffffffffff1681526020019150506020604051808303816000876161da5a03f1156100025750505060405180519060200150905073bb9bc244d798123fde783fcc1c72d3bb8c18941373ffffffffffffffffffffffffffffffffffffffff166323b872dd333084604051847c0100000000000000000000000000000000000000000000000000000000028152600401808473ffffffffffffffffffffffffffffffffffffffff1681526020018373ffffffffffffffffffffffffffffffffffffffff16815260200182815260200193505050506020604051808303816000876161da5a03f1156100025750505060405180519060200150158061041657503373ffffffffffffffffffffffffffffffffffffffff16600082604051809050600060405180830381858888f19350505050155b1561042057610002565b5b50565b73bb9bc244d798123fde783fcc1c72d3bb8c18941381565b600060009054906101000a900473ffffffffffffffffffffffffffffffffffffffff168156</span></span></code></pre> Blocks with block numbers in the range [1_920_000, 1_920_009] MUST</strong> have 0x64616f2d686172642d666f726b</code> (hex encoded ASCII string dao-hard-fork</code>) in the extraData</code> field of the block.</p> References</h2> https://blog.slock.it/hard-fork-specification-24b889e70703</li> https://blog.ethereum.org/2016/07/15/to-fork-or-not-to-fork/</li> </ol> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> "Hardfork Meta: Homestead" 2017-04-23T00:00:00+00:00 Abstract</h2> This specifies the changes included in the hard fork named Homestead.</p> Specification</h2> Codename: Homestead</li> Activation: Block >= 1,150,000 on Mainnet</li> Block >= 494,000 on Morden</li> Block >= 0 on future testnets</li> </ul> </li> Included EIPs: EIP-2</a> (Homestead Hard-fork Changes)</li> EIP-7</a> (DELEGATECALL)</li> EIP-8</a> (Networking layer: devp2p Forward Compatibility Requirements for Homestead)</li> </ul> </li> </ul> References</h2> https://blog.ethereum.org/2016/02/29/homestead-release/</li> </ol> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> "Hardfork Meta: Spurious Dragon" 2017-04-23T00:00:00+00:00 Abstract</h2> This specifies the changes included in the hard fork named Spurious Dragon.</p> Specification</h2> Codename: Spurious Dragon</li> Aliases: State-clearing</li> Activation: Block >= 2,675,000 on Mainnet</li> Block >= 1,885,000 on Morden</li> </ul> </li> Included EIPs: EIP-155</a> (Simple replay attack protection)</li> EIP-160</a> (EXP cost increase)</li> EIP-161</a> (State trie clearing)</li> EIP-170</a> (Contract code size limit)</li> </ul> </li> </ul> References</h2> https://blog.ethereum.org/2016/11/18/hard-fork-no-4-spurious-dragon/</li> </ol> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> "Hardfork Meta: Tangerine Whistle" 2017-04-23T00:00:00+00:00 Abstract</h2> This specifies the changes included in the hard fork named Tangerine Whistle (EIP 150).</p> Specification</h2> Codename: Tangerine Whistle</li> Aliases: EIP 150, Anti-DoS</li> Activation: Block >= 2,463,000 on Mainnet</li> </ul> </li> Included EIPs: EIP-150</a> (Gas cost changes for IO-heavy operations)</li> </ul> </li> </ul> References</h2> https://blog.ethereum.org/2016/10/13/announcement-imminent-hard-fork-eip150-gas-cost-changes/</li> https://blog.ethereum.org/2016/10/18/faq-upcoming-ethereum-hard-fork/</li> </ol> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> "Hardfork Meta: Byzantium" 2017-04-23T00:00:00+00:00 Abstract</h2> This specifies the changes included in the hard fork named Byzantium.</p> Specification</h2> Codename: Byzantium</li> Aliases: Metropolis/Byzantium, Metropolis part 1</li> Activation: Block >= 4,370,000 on Mainnet</li> Block >= 1,700,000 on Ropsten testnet</li> </ul> </li> Included EIPs: EIP-100</a> (Change difficulty adjustment to target mean block time including uncles)</li> EIP-140</a> (REVERT instruction in the Ethereum Virtual Machine)</li> EIP-196</a> (Precompiled contracts for addition and scalar multiplication on the elliptic curve alt_bn128)</li> EIP-197</a> (Precompiled contracts for optimal ate pairing check on the elliptic curve alt_bn128)</li> EIP-198</a> (Precompiled contract for bigint modular exponentiation)</li> EIP-211</a> (New opcodes: RETURNDATASIZE and RETURNDATACOPY)</li> EIP-214</a> (New opcode STATICCALL)</li> EIP-649</a> (Difficulty Bomb Delay and Block Reward Reduction)</li> EIP-658</a> (Embedding transaction status code in receipts)</li> </ul> </li> </ul> References</h2> https://blog.ethereum.org/2017/10/12/byzantium-hf-announcement/</li> </ol> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Formal process of hard forks 2017-03-23T00:00:00+00:00 Abstract</h2> To describe the formal process of preparing and activating hard forks.</p> Motivation</h2> Today discussions about hard forks happen at various forums and sometimes in ad-hoc ways.</p> Specification</h2> A Meta EIP should be created and merged as a Draft</em> as soon as a new hard fork is planned.</p> This EIP should contain:</p> the desired codename of the hard fork,</li> activation block number once decided</li> a timeline section</li> an EIPs to include section</li> the Requires</strong> header should point to the previous hard fork meta EIP.</li> </ul> The draft shall be updated with summaries of the decisions around the hard fork.</p> Timeline</h3> Once a timeline with key dates is agreed upon for other crucial dates. The basic outline of a hardfork timeline should include:</p> Hard deadline to accept proposals for this hard fork</li> Soft deadline for major client implementations</li> Projected date for testnet network upgrade</li> Projected date for mainnet upgrade (the activation block number / projected date for this block)</li> </ul> EIP Inclusion Process</h3> Anyone that wishes to propose a Core EIP for the hard fork should make a PR against the Meta EIP representing the hard fork. The EIP must be published as at least Draft</code>. It enters the Proposed EIPs</em> section, along with at least one person who is a point of contact for wanting to include the EIP.</p> EIPs can move states by discussion done on the "All Core Devs Meetings</a>":</p> If accepted for a hard fork, the EIP should be moved to the Accepted EIPs</em> section. If the EIP has major client implementations and no security issues by the timeline date, it is scheduled for inclusion.</li> If rejected from a hard fork, the EIP should be moved to the Rejected EIPs</em> section.</li> Once the EIPs in the Accepted EIPs</em> section have successfully launched on a testnet roll out, they are moved to the Included EIPs</em> section.</li> </ul> The Meta EIP representing the hard fork should move in to the Accepted</code> state once the changes are frozen (i.e. all referenced EIPs are in the Accepted</code> state) and in to the Final</code> state once the hard fork has been activated.</p> Template</h2> A template for the Istanbul Hardfork Meta 1679</a> is included below (source file on GitHub</a>):</p> {% raw %}</span></span> ---</span></span> eip: 1679</span></span> title: "Hardfork Meta: Istanbul"</span></span> author: Alex Beregszaszi (@axic), Afri Schoedon (@5chdn)</span></span> type: Meta</span></span> status: Draft</span></span> created: 2019-01-04</span></span> requires: 1716</span></span> ---</span></span> </span> ## Abstract</span></span> </span> This meta-EIP specifies the changes included in the Ethereum hardfork named Istanbul.</span></span> </span> ## Specification</span></span> </span> - Codename: Istanbul</span></span> - Activation: TBD</span></span> </span> ### Included EIPs</span></span> </span> - TBD</span></span> </span> ### Accepted EIPs</span></span> </span> - TBD</span></span> </span> ### Rejected EIPs</span></span> </span> - TBD</span></span> </span> ### Proposed EIPs</span></span> </span> - TBD</span></span> </span> ## Timeline</span></span> </span> * 2019-05-17 (Fri) hard deadline to accept proposals for "Istanbul"</span></span> * 2019-07-19 (Fri) soft deadline for major client implementations</span></span> * 2019-08-14 (Wed) projected date for testnet network upgrade (Ropsten, Görli, or ad-hoc testnet)</span></span> * 2019-10-16 (Wed) projected date for mainnet upgrade ("Istanbul")</span></span> </span> ## References</span></span> </span> - TBD (e.g. link to Core Dev notes or other references)</span></span> </span> ## Copyright</span></span> </span> Copyright and related rights waived via [CC0](/LICENSE.md).</span></span> </span> {% endraw %}</span></span></code></pre>Rationale</h2> A meta EIP for coordinating the hard fork should help in visibility and traceability of the scope of changes as well as provide a simple name and/or number for referring to the proposed fork.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> EIP Classification 2015-11-17T00:00:00+00:00 Abstract</h1> This document describes a classification scheme for EIPs, adapted from BIP 123</a>.</p> EIPs are classified by system layers with lower numbered layers involving more intricate interoperability requirements.</p> The specification defines the layers and sets forth specific criteria for deciding to which layer a particular standards EIP belongs.</p> Motivation</h1> Ethereum is a system involving a number of different standards. Some standards are absolute requirements for interoperability while others can be considered optional, giving implementers a choice of whether to support them.</p> In order to have a EIP process which more closely reflects the interoperability requirements, it is necessary to categorize EIPs accordingly. Lower layers present considerably greater challenges in getting standards accepted and deployed.</p> Specification</h1> Standards EIPs are placed in one of four layers:</p> Consensus</li> Networking</li> API/RPC</li> Applications</li> </ol> 1. Consensus Layer</h1> The consensus layer defines cryptographic commitment structures. Its purpose is ensuring that anyone can locally evaluate whether a particular state and history is valid, providing settlement guarantees, and assuring eventual convergence.</p> The consensus layer is not concerned with how messages are propagated on a network.</p> Disagreements over the consensus layer can result in network partitioning, or forks, where different nodes might end up accepting different incompatible histories. We further subdivide consensus layer changes into soft forks and hard forks.</p> Soft Forks</h2> In a soft fork, some structures that were valid under the old rules are no longer valid under the new rules. Structures that were invalid under the old rules continue to be invalid under the new rules.</p> Hard Forks</h2> In a hard fork, structures that were invalid under the old rules become valid under the new rules.</p> 2. Networking Layer</h1> The networking layer specifies the Ethereum wire protocol (eth) and the Light Ethereum Subprotocol (les). RLPx is excluded and tracked in the devp2p repository</a>.</p> Only a subset of subprotocols are required for basic node interoperability. Nodes can support further optional extensions.</p> It is always possible to add new subprotocols without breaking compatibility with existing protocols, then gradually deprecate older protocols. In this manner, the entire network can be upgraded without serious risks of service disruption.</p> 3. API/RPC Layer</h1> The API/RPC layer specifies higher level calls accessible to applications. Support for these EIPs is not required for basic network interoperability but might be expected by some client applications.</p> There's room at this layer to allow for competing standards without breaking basic network interoperability.</p> 4. Applications Layer</h1> The applications layer specifies high level structures, abstractions, and conventions that allow different applications to support similar features and share data.</p> EIP Purpose and Guidelines 2015-10-27T00:00:00+00:00 What is an EIP?</h2> EIP stands for Ethereum Improvement Proposal. An EIP is a design document providing information to the Ethereum community, or describing a new feature for Ethereum or its processes or environment. The EIP should provide a concise technical specification of the feature and a rationale for the feature. The EIP author is responsible for building consensus within the community and documenting dissenting opinions.</p> EIP Rationale</h2> We intend EIPs to be the primary mechanisms for proposing new features, for collecting community technical input on an issue, and for documenting the design decisions that have gone into Ethereum. Because the EIPs are maintained as text files in a versioned repository, their revision history is the historical record of the feature proposal.</p> For Ethereum implementers, EIPs are a convenient way to track the progress of their implementation. Ideally each implementation maintainer would list the EIPs that they have implemented. This will give end users a convenient way to know the current status of a given implementation or library.</p> EIP Types</h2> There are three types of EIP:</p> A Standards Track EIP</strong> describes any change that affects most or all Ethereum implementations, such as—a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Standards Track EIPs consist of three parts—a design document, an implementation, and (if warranted) an update to the formal specification</a>. Furthermore, Standards Track EIPs can be broken down into the following categories:</p> Core</strong>: improvements requiring a consensus fork (e.g. EIP-5</a>, EIP-101</a>), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions</a> (for example, [EIP-90], and the miner/node strategy changes 2, 3, and 4 of EIP-86</a>).</li> Networking</strong>: includes improvements around devp2p</a> (EIP-8</a>) and Light Ethereum Subprotocol</a>, as well as proposed improvements to network protocol specifications of whisper</a> and swarm</a>.</li> Interface</strong>: includes improvements around language-level standards like method names (EIP-6</a>) and contract ABIs</a>.</li> ERC</strong>: application-level standards and conventions, including contract standards such as token standards (ERC-20</a>), name registries (ERC-137</a>), URI schemes, library/package formats, and wallet formats.</li> </ul> </li> A Meta EIP</strong> describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP.</p> </li> An Informational EIP</strong> describes an Ethereum design issue, or provides general guidelines or information to the Ethereum community, but does not propose a new feature. Informational EIPs do not necessarily represent Ethereum community consensus or a recommendation, so users and implementers are free to ignore Informational EIPs or follow their advice.</p> </li> </ul> It is highly recommended that a single EIP contain a single key proposal or new idea. The more focused the EIP, the more successful it tends to be. A change to one client doesn't require an EIP; a change that affects multiple clients, or defines a standard for multiple apps to use, does.</p> An EIP must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly.</p> Special requirements for Core EIPs</h3> If a Core</strong> EIP mentions or proposes changes to the EVM (Ethereum Virtual Machine), it should refer to the instructions by their mnemonics and define the opcodes of those mnemonics at least once. A preferred way is the following:</p> REVERT (0xfe)</span></span></code></pre>EIP Work Flow</h2> Shepherding an EIP</h3> Parties involved in the process are you, the champion or EIP author</em>, the EIP editors</em></a>, and the Ethereum Core Developers</em></a>.</p> Before you begin writing a formal EIP, you should vet your idea. Ask the Ethereum community first if an idea is original to avoid wasting time on something that will be rejected based on prior research. It is thus recommended to open a discussion thread on the Ethereum Magicians forum</a> to do this.</p> Once the idea has been vetted, your next responsibility will be to present (by means of an EIP) the idea to the reviewers and all interested parties, invite editors, developers, and the community to give feedback on the aforementioned channels. You should try and gauge whether the interest in your EIP is commensurate with both the work involved in implementing it and how many parties will have to conform to it. For example, the work required for implementing a Core EIP will be much greater than for an ERC and the EIP will need sufficient interest from the Ethereum client teams. Negative community feedback will be taken into consideration and may prevent your EIP from moving past the Draft stage.</p> Core EIPs</h3> For Core EIPs, given that they require client implementations to be considered Final</strong> (see "EIPs Process" below), you will need to either provide an implementation for clients or convince clients to implement your EIP.</p> The best way to get client implementers to review your EIP is to present it on an AllCoreDevs call. You can request to do so by posting a comment linking your EIP on an AllCoreDevs agenda GitHub Issue</a>.</p> The AllCoreDevs call serves as a way for client implementers to do three things. First, to discuss the technical merits of EIPs. Second, to gauge what other clients will be implementing. Third, to coordinate EIP implementation for network upgrades.</p> These calls generally result in a "rough consensus" around what EIPs should be implemented. This "rough consensus" rests on the assumptions that EIPs are not contentious enough to cause a network split and that they are technically sound.</p> :warning: The EIPs process and AllCoreDevs call were not designed to address contentious non-technical issues, but, due to the lack of other ways to address these, often end up entangled in them. This puts the burden on client implementers to try and gauge community sentiment, which hinders the technical coordination function of EIPs and AllCoreDevs calls. If you are shepherding an EIP, you can make the process of building community consensus easier by making sure that the Ethereum Magicians forum</a> thread for your EIP includes or links to as much of the community discussion as possible and that various stakeholders are well-represented.</p> In short, your role as the champion is to write the EIP using the style and format described below, shepherd the discussions in the appropriate forums, and build community consensus around the idea.</em></p> EIP Process</h3> The following is the standardization process for all EIPs in all tracks:</p> </p> Idea</strong> - An idea that is pre-draft. This is not tracked within the EIP Repository.</p> Draft</strong> - The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.</p> Review</strong> - An EIP Author marks an EIP as ready for and requesting Peer Review.</p> Last Call</strong> - This is the final review window for an EIP before it is moved to Final</code>. An EIP enters Last Call</code> when the specification is stable and the author opens a PR with a review end date (last-call-deadline</code>), typically 14 days later.</p> If this period results in necessary normative changes it will revert the EIP to Review</code>.</p> Final</strong> - This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.</p> A PR moving an EIP from Last Call to Final SHOULD contain no changes other than the status update. Any content or editorial proposed change SHOULD be separate from this status-updating PR and committed prior to it.</p> Stagnant</strong> - Any EIP in Draft</code> or Review</code> or Last Call</code> if inactive for a period of 6 months or greater is moved to Stagnant</code>. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to Draft</code> or its earlier status. If not resurrected, a proposal may stay forever in this status.</p> EIP Authors are notified of any algorithmic change to the status of their EIP</em></p> </blockquote> Withdrawn</strong> - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.</p> Living</strong> - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.</p> What belongs in a successful EIP?</h2> Each EIP should have the following parts:</p> Preamble - RFC 822 style headers containing metadata about the EIP, including the EIP number, a short descriptive title (limited to a maximum of 44 characters), a description (limited to a maximum of 140 characters), and the author details. Irrespective of the category, the title and description should not include EIP number. See below</a> for details.</li> Abstract - Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.</li> Motivation (optional)</em> - A motivation section is critical for EIPs that want to change the Ethereum protocol. It should clearly explain why the existing protocol specification is inadequate to address the problem that the EIP solves. This section may be omitted if the motivation is evident.</li> Specification - The technical specification should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (besu, erigon, ethereumjs, go-ethereum, nethermind, or others).</li> Rationale - The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale should discuss important objections or concerns raised during discussion around the EIP.</li> Backwards Compatibility (optional)</em> - All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their consequences. The EIP must explain how the author proposes to deal with these incompatibilities. This section may be omitted if the proposal does not introduce any backwards incompatibilities, but this section must be included if backward incompatibilities exist.</li> Test Cases (optional)</em> - Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Tests should either be inlined in the EIP as data (such as input/expected output pairs) or included in ../assets/eip-###/<filename></code>. This section may be omitted for non-Core proposals.</li> Reference Implementation (optional)</em> - An optional section that contains a reference/example implementation that people can use to assist in understanding or implementing this specification. This section may be omitted for all EIPs.</li> Security Considerations - All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life-cycle of the proposal. E.g. include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.</li> Copyright Waiver - All EIPs must be in the public domain. The copyright waiver MUST link to the license file and use the following wording: Copyright and related rights waived via [CC0](/LICENSE.md).</code></li> </ul> EIP Formats and Templates</h2> EIPs should be written in markdown</a> format. There is a template</a> to follow.</p> EIP Header Preamble</h2> Each EIP must begin with an RFC 822</a> style header preamble, preceded and followed by three hyphens (---</code>). This header is also termed "front matter" by Jekyll</a>. The headers must appear in the following order.</p> eip</code>: EIP number</em></p> title</code>: The EIP title is a few words, not a complete sentence</em></p> description</code>: Description is one full (short) sentence</em></p> author</code>: The list of the author's or authors' name(s) and/or username(s), or name(s) and email(s). Details are below.</em></p> discussions-to</code>: The url pointing to the official discussion thread</em></p> status</code>: Draft, Review, Last Call, Final, Stagnant, Withdrawn, Living</em></p> last-call-deadline</code>: The date last call period ends on</em> (Optional field, only needed when status is Last Call</code>)</p> type</code>: One of Standards Track</code>, Meta</code>, or Informational</code></em></p> category</code>: One of Core</code>, Networking</code>, Interface</code>, or ERC</code></em> (Optional field, only needed for Standards Track</code> EIPs)</p> created</code>: Date the EIP was created on</em></p> requires</code>: EIP number(s)</em> (Optional field)</p> withdrawal-reason</code>: A sentence explaining why the EIP was withdrawn.</em> (Optional field, only needed when status is Withdrawn</code>)</p> Headers that permit lists must separate elements with commas.</p> Headers requiring dates will always do so in the format of ISO 8601 (yyyy-mm-dd).</p> author</code> header</h3> The author</code> header lists the names, email addresses or usernames of the authors/owners of the EIP. Those who prefer anonymity may use a username only, or a first name and a username. The format of the author</code> header value must be:</p> Random J. User <address@dom.ain></p> </blockquote> or</p> Random J. User (@username)</p> </blockquote> or</p> Random J. User (@username) <address@dom.ain></p> </blockquote> if the email address and/or GitHub username is included, and</p> Random J. User</p> </blockquote> if neither the email address nor the GitHub username are given.</p> At least one author must use a GitHub username, in order to get notified on change requests and have the capability to approve or reject them.</p> discussions-to</code> header</h3> While an EIP is a draft, a discussions-to</code> header will indicate the URL where the EIP is being discussed.</p> The preferred discussion URL is a topic on Ethereum Magicians</a>. The URL cannot point to GitHub pull requests, any URL which is ephemeral, and any URL which can get locked over time (i.e. Reddit topics).</p> type</code> header</h3> The type</code> header specifies the type of EIP: Standards Track, Meta, or Informational. If the track is Standards please include the subcategory (core, networking, interface, or ERC).</p> category</code> header</h3> The category</code> header specifies the EIP's category. This is required for standards-track EIPs only.</p> created</code> header</h3> The created</code> header records the date that the EIP was assigned a number. Both headers should be in yyyy-mm-dd format, e.g. 2001-08-14.</p> requires</code> header</h3> EIPs may have a requires</code> header, indicating the EIP numbers that this EIP depends on. If such a dependency exists, this field is required.</p> A requires</code> dependency is created when the current EIP cannot be understood or implemented without a concept or technical element from another EIP. Merely mentioning another EIP does not necessarily create such a dependency.</p> Linking to External Resources</h2> Other than the specific exceptions listed below, links to external resources SHOULD NOT</strong> be included. External resources may disappear, move, or change unexpectedly.</p> The process governing permitted external resources is described in EIP-5757</a>.</p> Execution Client Specifications</h3> Links to the Ethereum Execution Client Specifications may be included using normal markdown syntax, such as:</p> [</span>Ethereum Execution Client Specifications</span>]</span>(</span>https://github.com/ethereum/execution-specs/blob/9a1f22311f517401fed6c939a159b55600c454af/README.md</span>)</span></span></code></pre> Which renders to:</p> Ethereum Execution Client Specifications</a></p> Permitted Execution Client Specifications URLs must anchor to a specific commit, and so must match this regular expression:</p> ^(https://github.com/ethereum/execution-specs/(blob|commit)/[0-9a-f]{40}/.*|https://github.com/ethereum/execution-specs/tree/[0-9a-f]{40}/.*)$</span></span></code></pre>Execution Specification Tests</h3> Links to the Ethereum Execution Specification Tests (EEST) may be included using normal markdown syntax, such as:</p> [</span>Ethereum Execution Specification Tests</span>]</span>(</span>https://github.com/ethereum/execution-spec-tests/blob/c9b9307ff320c9bb0ecb9a951aeab0da4d9d1684/README.md</span>)</span></span></code></pre> Which renders to:</p> Ethereum Execution Specification Tests</a></p> Permitted Execution Specification Tests URLs must anchor to a specific commit, and so must match one of these regular expressions:</p> ^https://(www\.)?github\.com/ethereum/execution-spec-tests/(blob|tree)/[a-f0-9]{40}/.+$</span></span></code></pre>^https://(www\.)?github\.com/ethereum/execution-spec-tests/commit/[a-f0-9]{40}$</span></span></code></pre>Consensus Layer Specifications</h3> Links to specific commits of files within the Ethereum Consensus Layer Specifications may be included using normal markdown syntax, such as:</p> [</span>Beacon Chain</span>]</span>(</span>https://github.com/ethereum/consensus-specs/blob/26695a9fdb747ecbe4f0bb9812fedbc402e5e18c/specs/sharding/beacon-chain.md</span>)</span></span></code></pre> Which renders to:</p> Beacon Chain</a></p> Permitted Consensus Layer Specifications URLs must anchor to a specific commit, and so must match this regular expression:</p> ^https://github.com/ethereum/consensus-specs/(blob|commit)/[0-9a-f]{40}/.*$</span></span></code></pre>Networking Specifications</h3> Links to specific commits of files within the Ethereum Networking Specifications may be included using normal markdown syntax, such as:</p> [</span>Ethereum Wire Protocol</span>]</span>(</span>https://github.com/ethereum/devp2p/blob/40ab248bf7e017e83cc9812a4e048446709623e8/caps/eth.md</span>)</span></span></code></pre> Which renders as:</p> Ethereum Wire Protocol</a></p> Permitted Networking Specifications URLs must anchor to a specific commit, and so must match this regular expression:</p> ^https://github.com/ethereum/devp2p/(blob|commit)/[0-9a-f]{40}/.*$</span></span></code></pre>Portal Specifications</h3> Links to specific commits of files within the Ethereum Portal Specifications may be included using normal markdown syntax, such as:</p> [</span>Portal Wire Protocol</span>]</span>(</span>https://github.com/ethereum/portal-network-specs/blob/5e321567b67bded7527355be714993c24371de1a/portal-wire-protocol.md</span>)</span></span></code></pre> Which renders as:</p> Portal Wire Protocol</a></p> Permitted Networking Specifications URLs must anchor to a specific commit, and so must match this regular expression:</p> ^https://github.com/ethereum/portal-network-specs/(blob|commit)/[0-9a-f]{40}/.*$</span></span></code></pre>World Wide Web Consortium (W3C)</h3> Links to a W3C "Recommendation" status specification may be included using normal markdown syntax. For example, the following link would be allowed:</p> [</span>Secure Contexts</span>]</span>(</span>https://www.w3.org/TR/2021/CRD-secure-contexts-20210918/</span>)</span></span></code></pre> Which renders as:</p> Secure Contexts</a></p> Permitted W3C recommendation URLs MUST anchor to a specification in the technical reports namespace with a date, and so MUST match this regular expression:</p> ^https://www\.w3\.org/TR/[0-9][0-9][0-9][0-9]/.*$</span></span></code></pre>Web Hypertext Application Technology Working Group (WHATWG)</h3> Links to WHATWG specifications may be included using normal markdown syntax, such as:</p> [</span>HTML</span>]</span>(</span>https://html.spec.whatwg.org/commit-snapshots/578def68a9735a1e36610a6789245ddfc13d24e0/</span>)</span></span></code></pre> Which renders as:</p> HTML</a></p> Permitted WHATWG specification URLs must anchor to a specification defined in the spec</code> subdomain (idea specifications are not allowed) and to a commit snapshot, and so must match this regular expression:</p> ^https:\/\/[a-z]*\.spec\.whatwg\.org/commit-snapshots/[0-9a-f]{40}/$</span></span></code></pre> Although not recommended by WHATWG, EIPs must anchor to a particular commit so that future readers can refer to the exact version of the living standard that existed at the time the EIP was finalized. This gives readers sufficient information to maintain compatibility, if they so choose, with the version referenced by the EIP and the current living standard.</p> Internet Engineering Task Force (IETF)</h3> Links to an IETF Request For Comment (RFC) specification may be included using normal markdown syntax, such as:</p> [</span>RFC 8446</span>]</span>(</span>https://www.rfc-editor.org/rfc/rfc8446</span>)</span></span></code></pre> Which renders as:</p> RFC 8446</a></p> Permitted IETF specification URLs MUST anchor to a specification with an assigned RFC number (meaning cannot reference internet drafts), and so MUST match this regular expression:</p> ^https:\/\/www.rfc-editor.org\/rfc\/.*$</span></span></code></pre>Bitcoin Improvement Proposal</h3> Links to Bitcoin Improvement Proposals may be included using normal markdown syntax, such as:</p> [</span>BIP 38</span>]</span>(</span>https://github.com/bitcoin/bips/blob/3db736243cd01389a4dfd98738204df1856dc5b9/bip-0038.mediawiki</span>)</span></span></code></pre> Which renders to:</p> BIP 38</a></p> Permitted Bitcoin Improvement Proposal URLs must anchor to a specific commit, and so must match this regular expression:</p> ^(https://github.com/bitcoin/bips/blob/[0-9a-f]{40}/bip-[0-9]+\.mediawiki)$</span></span></code></pre>National Vulnerability Database (NVD)</h3> Links to the Common Vulnerabilities and Exposures (CVE) system as published by the National Institute of Standards and Technology (NIST) may be included, provided they are qualified by the date of the most recent change, using the following syntax:</p> [</span>CVE-2023-29638 (2023-10-17T10:14:15)</span>]</span>(</span>https://nvd.nist.gov/vuln/detail/CVE-2023-29638</span>)</span></span></code></pre> Which renders to:</p> CVE-2023-29638 (2023-10-17T10:14:15)</a></p> Chain Agnostic Improvement Proposals (CAIPs)</h3> Links to a Chain Agnostic Improvement Proposals (CAIPs) specification may be included using normal markdown syntax, such as:</p> [</span>CAIP 10</span>]</span>(</span>https://github.com/ChainAgnostic/CAIPs/blob/5dd3a2f541d399a82bb32590b52ca4340b09f08b/CAIPs/caip-10.md</span>)</span></span></code></pre> Which renders to:</p> CAIP 10</a></p> Permitted Chain Agnostic URLs must anchor to a specific commit, and so must match this regular expression:</p> ^(https://github.com/ChainAgnostic/CAIPs/blob/[0-9a-f]{40}/CAIPs/caip-[0-9]+\.md)$</span></span></code></pre>Ethereum Yellow Paper</h3> Links to the Ethereum Yellow Paper may be included using normal markdown syntax, such as:</p> [</span>Ethereum Yellow Paper</span>]</span>(</span>https://github.com/ethereum/yellowpaper/blob/9c601d6a58c44928d4f2b837c0350cec9d9259ed/paper.pdf</span>)</span></span></code></pre> Which renders to:</p> Ethereum Yellow Paper</a></p> Permitted Yellow Paper URLs must anchor to a specific commit, and so must match this regular expression:</p> ^(https://github\.com/ethereum/yellowpaper/blob/[0-9a-f]{40}/paper\.pdf)$</span></span></code></pre>Execution Client Specification Tests</h3> Links to the Ethereum Execution Client Specification Tests may be included using normal markdown syntax, such as:</p> [</span>Ethereum Execution Client Specification Tests</span>]</span>(</span>https://github.com/ethereum/execution-spec-tests/blob/d5a3188f122912e137aa2e21ed2a1403e806e424/README.md</span>)</span></span></code></pre> Which renders to:</p> Ethereum Execution Client Specification Tests</a></p> Permitted Execution Client Specification Tests URLs must anchor to a specific commit, and so must match this regular expression:</p> ^(https://github.com/ethereum/execution-spec-tests/(blob|commit)/[0-9a-f]{40}/.*|https://github.com/ethereum/execution-spec-tests/tree/[0-9a-f]{40}/.*)$</span></span></code></pre>Digital Object Identifier System</h3> Links qualified with a Digital Object Identifier (DOI) may be included using the following syntax:</p> This is a sentence with a footnote.</span>[</span>^1</span>]</span></span> </span> [</span>^1</span>]</span>:</span></span> ```csl-json</span></span> {</span></span> "type": "article",</span></span> "id": 1,</span></span> "author": [</span></span> {</span></span> "family": "Jameson",</span></span> "given": "Hudson"</span></span> }</span></span> ],</span></span> "DOI": "00.0000/a00000-000-0000-y",</span></span> "title": "An Interesting Article",</span></span> "original-date": {</span></span> "date-parts": [</span></span> [2022, 12, 31]</span></span> ]</span></span> },</span></span> "URL": "https://sly-hub.invalid/00.0000/a00000-000-0000-y",</span></span> "custom": {</span></span> "additional-urls": [</span></span> "https://example.com/an-interesting-article.pdf"</span></span> ]</span></span> }</span></span> }</span></span> ```</span></span></code></pre> Which renders to:</p> This is a sentence with a footnote.1</a></sup></p> See the Citation Style Language Schema</a> for the supported fields. In addition to passing validation against that schema, references must include a DOI and at least one URL.</p> The top-level URL field must resolve to a copy of the referenced document which can be viewed at zero cost. Values under additional-urls</code> must also resolve to a copy of the referenced document, but may charge a fee.</p> Execution API Specification</h3> Links to the Ethereum Execution API Specification may be included using normal markdown syntax, such as:</p> [</span>Ethereum Execution API Specification</span>]</span>(</span>https://github.com/ethereum/execution-apis/blob/dd00287101e368752ba264950585dde4b61cdc17/README.md</span>)</span></span></code></pre> Which renders to:</p> Ethereum Execution API Specification</a></p> Permitted Execution API Specification URLs must anchor to a specific commit, and so must match this regular expression:</p> ^(https://github.com/ethereum/execution-apis/(blob|commit)/[0-9a-f]{40}/.*|https://github.com/ethereum/execution-apis/tree/[0-9a-f]{40}/.*)$</span></span></code></pre>Linking to other EIPs</h2> References to other EIPs should follow the format EIP-N</code> where N</code> is the EIP number you are referring to. Each EIP that is referenced in an EIP MUST</strong> be accompanied by a relative markdown link the first time it is referenced, and MAY</strong> be accompanied by a link on subsequent references. The link MUST</strong> always be done via relative paths so that the links work in this GitHub repository, forks of this repository, the main EIPs site, mirrors of the main EIP site, etc. For example, you would link to this EIP as ../00001.md</code>.</p> Auxiliary Files</h2> Images, diagrams and auxiliary files should be included in a subdirectory of the assets</code> folder for that EIP as follows: assets/eip-N</code> (where N</strong> is to be replaced with the EIP number). When linking to an image in the EIP, use relative links such as ./assets/image.png</code>.</p> Transferring EIP Ownership</h2> It occasionally becomes necessary to transfer ownership of EIPs to a new champion. In general, we'd like to retain the original author as a co-author of the transferred EIP, but that's really up to the original author. A good reason to transfer ownership is because the original author no longer has the time or interest in updating it or following through with the EIP process, or has fallen off the face of the 'net (i.e. is unreachable or isn't responding to email). A bad reason to transfer ownership is because you don't agree with the direction of the EIP. We try to build consensus around an EIP, but if that's not possible, you can always submit a competing EIP.</p> If you are interested in assuming ownership of an EIP, send a message asking to take over, addressed to both the original author and the EIP editor. If the original author doesn't respond to the email in a timely manner, the EIP editor will make a unilateral decision (it's not like such decisions can't be reversed :)).</p> EIP Editors</h2> The current EIP editors are</p> Matt Garnett (@lightclient)</li> Sam Wilson (@SamWilsn)</li> Zainan Victor Zhou (@xinbenlv)</li> Gajinder Singh (@g11tech)</li> Jochem Brouwer (@jochem-brouwer)</li> </ul> Emeritus EIP editors are</p> Alex Beregszaszi (@axic)</li> Casey Detrio (@cdetrio)</li> Gavin John (@Pandapip1)</li> Greg Colvin (@gcolvin)</li> Hudson Jameson (@Souptacular)</li> Martin Becze (@wanderer)</li> Micah Zoltu (@MicahZoltu)</li> Nick Johnson (@arachnid)</li> Nick Savers (@nicksavers)</li> Vitalik Buterin (@vbuterin)</li> </ul> If you would like to become an EIP editor, please check EIP-5069</a>.</p> EIP Editor Responsibilities</h2> For each new EIP that comes in, an editor does the following:</p> Read the EIP to check if it is ready: sound and complete. The ideas must make technical sense, even if they don't seem likely to get to final status.</li> The title should accurately describe the content.</li> Check the EIP for language (spelling, grammar, sentence structure, etc.), markup (GitHub flavored Markdown), code style</li> </ul> If the EIP isn't ready, the editor will send it back to the author for revision, with specific instructions.</p> Once the EIP is ready for the repository, the EIP editor will:</p> Assign an EIP number (generally incremental; editors can reassign if number sniping is suspected)</li> Merge the corresponding pull request</a></li> Send a message back to the EIP author with the next step.</li> </ul> Many EIPs are written and maintained by developers with write access to the Ethereum codebase. The EIP editors monitor EIP changes, and correct any structure, grammar, spelling, or markup mistakes we see.</p> The editors don't pass judgment on EIPs. We merely do the administrative & editorial part.</p> Style Guide</h2> Titles</h3> The title</code> field in the preamble:</p> Should not include the word "standard" or any variation thereof; and</li> Should not include the EIP's number.</li> </ul> Descriptions</h3> The description</code> field in the preamble:</p> Should not include the word "standard" or any variation thereof; and</li> Should not include the EIP's number.</li> </ul> EIP numbers</h3> When referring to an EIP with a category</code> of ERC</code>, it must be written in the hyphenated form ERC-X</code> where X</code> is that EIP's assigned number. When referring to EIPs with any other category</code>, it must be written in the hyphenated form EIP-X</code> where X</code> is that EIP's assigned number.</p> RFC 2119 and RFC 8174</h3> EIPs are encouraged to follow RFC 2119</a> and RFC 8174</a> for terminology and to insert the following at the beginning of the Specification section:</p> 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 and RFC 8174.</p> </blockquote> History</h2> This document was derived heavily from Bitcoin's BIP-0001</a> written by Amir Taaki which in turn was derived from Python's PEP-0001</a>. In many places text was simply copied and modified. Although the PEP-0001 text was written by Barry Warsaw, Jeremy Hylton, and David Goodger, they are not responsible for its use in the Ethereum Improvement Process, and should not be bothered with technical questions specific to Ethereum or the EIP. Please direct all comments to the EIP editors.</p> Copyright</h2> Copyright and related rights waived via CC0</a>.</p> Jameson, H. (n.d.). An Interesting Article</span>. https://doi.org/00.0000/a00000-000-0000-y</a> (Original work published 2022) ↩</a></p> </li> </ol> </section>