---
eip: 233
title: Formal process of hard forks
author: Alex Beregszaszi (@axic)
discussions-to: https://ethereum-magicians.org/t/eip-233-formal-process-of-hard-forks/1387
type: Meta
status: Stagnant
created: 2017-03-23
---

## Abstract

To describe the formal process of preparing and activating hard forks.

## Motivation

Today discussions about hard forks happen at various forums and sometimes in ad-hoc ways.

## Specification

A Meta EIP should be created and merged as a *Draft* as soon as a new hard fork is planned.

This EIP should contain:
- the desired codename of the hard fork,
- activation block number once decided
- a timeline section
- an EIPs to include section
- the **Requires** header should point to the previous hard fork meta EIP.

The draft shall be updated with summaries of the decisions around the hard fork.

### Timeline

Once a timeline with key dates is agreed upon for other crucial dates. The basic outline of a hardfork timeline should include:
* Hard deadline to accept proposals for this hard fork
* Soft deadline for major client implementations
* Projected date for testnet network upgrade
* Projected date for mainnet upgrade (the activation block number / projected date for this block)

### EIP Inclusion Process

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`. It enters the _Proposed EIPs_ section, along with at least one person who is a point of contact for wanting to include the EIP.

EIPs can move states by discussion done on the "[All Core Devs Meetings](https://github.com/ethereum/pm/)":
- If accepted for a hard fork, the EIP should be moved to the _Accepted EIPs_ section. If the EIP has major client implementations and no security issues by the timeline date, it is scheduled for inclusion.
- If rejected from a hard fork, the EIP should be moved to the _Rejected EIPs_ section.
- Once the EIPs in the _Accepted EIPs_ section have successfully launched on a testnet roll out, they are moved to the _Included EIPs_ section.

---

The Meta EIP representing the hard fork should move in to the `Accepted` state once the changes are frozen (i.e. all referenced EIPs are in the `Accepted` state) and in to the `Final` state once the hard fork has been activated.

## Template

A template for the [Istanbul Hardfork Meta 1679](./eip-1679.md) is included below ([source file on GitHub](./eip-1679.md)):

```
{% raw %}
---
eip: 1679
title: "Hardfork Meta: Istanbul"
author: Alex Beregszaszi (@axic), Afri Schoedon (@5chdn)
type: Meta
status: Draft
created: 2019-01-04
requires: 1716
---

## Abstract

This meta-EIP specifies the changes included in the Ethereum hardfork named Istanbul.

## Specification

- Codename: Istanbul
- Activation: TBD

### Included EIPs

- TBD

### Accepted EIPs

- TBD

### Rejected EIPs

- TBD

### Proposed EIPs

- TBD

## Timeline

* 2019-05-17 (Fri) hard deadline to accept proposals for "Istanbul"
* 2019-07-19 (Fri) soft deadline for major client implementations
* 2019-08-14 (Wed) projected date for testnet network upgrade (Ropsten, Görli, or ad-hoc testnet)
* 2019-10-16 (Wed) projected date for mainnet upgrade ("Istanbul")

## References

- TBD (e.g. link to Core Dev notes or other references)

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).

{% endraw %}
```

## Rationale

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.

## Copyright

Copyright and related rights waived via [CC0](../LICENSE.md).