The ECIP sample is the best place to start. The sample was updated for Ethereum use by Martin Becze, it was predominantly derived from the Bitcoin improvement proposal based on the Python improvement proposal system. Fork the repository and add your ECIP to it, using the provided ECIP markdown template. Submit by creating a Pull Request to the Ethereum Classic Labs' ECIPs repository.
- Review ECIP-1.
- Fork the repository by clicking "Fork" in the top right.
- Add your ECIP to your fork of the repository. There is a template ECIP here.
- Submit a Pull Request to Ethereum Classic Labs' ECIPs repository.
Your first PR should be a first draft of the final ECIP. It must meet the formatting criteria enforced by the build (largely, correct metadata in the header). An editor will manually review the first PR for a new ECIP and assign it a number before merging it. Make sure you include a discussions-to header with the URL to a discussion forum or open GitHub issue where people can discuss the ECIP as a whole.
If your ECIP requires images, the image files should be included in a subdirectory of the assets folder for that ECIP as follow: assets/eip-X (for ecip X). When linking to an image in the ECIP, use relative links such as ../assets/ecip-X/image.png.
When you believe your ECIP is mature and ready to progress past the draft phase, you should do one of two things:
- For a Standards Track ECIP of type Core, ask to have your issue added to the agenda of an upcoming All Dev Team meeting, where it can be discussed for inclusion in a future hard fork. If implementers agree to include it, the ECIP editors will update the state of your ECIP to 'Accepted'.
- For all other ECIPs, open a PR changing the state of your ECIP to 'Final'. An editor will review your draft and ask if anyone objects to its finalization. If the editor decides there is no rough consensus - for instance, because contributors point out significant issues with the ECIP - they may close the PR and request that you fix the issues in the draft before trying again.
- Draft - An ECIP that is undergoing rapid iteration and changes.
- Last Call - An ECIP that is done with its initial iteration and ready for review by a wider audience.
- Accepted - An ECIP that has been in Last Call for at least 2 weeks and any technical changes that were requested have been addressed by the author.
- Final - An ECIP that was accepted, implemented, and no longer can be modified without submitting a new proposal, e.g., it has been released in a hard fork.
- Deferred - An ECIP that is not being considered for immediate adoption. May be reconsidered in the future for a subsequent hard fork.
- Replaced - When a Final ECIP is no longer relevant, its status may be changed to Replaced or Obsolete.
- Rejected - Reasons for rejecting ECIPs include duplication of effort, disregard for formatting rules, unfocused or too broad, being technically unsound, not providing proper motivation, or obvious popular disapproval.
- Withdrawn - ECIP authors may decide to change the status between Draft, Deferred, or Withdrawn. The ECIP editor may also change the status to Deferred if no progress is being made on the ECIP.
| Number | Title | Author | Type | Layer | Status / Discussion |
|---|---|---|---|---|---|
| ECIP-1010 | Delay Difficulty Bomb Explosion | Igor Artamonov | Standard | Consensus (hard-fork) | Accepted |
| ECIP-1017 | Monetary Policy and Final Modification to the Ethereum Classic Emission Schedule | Matthew Mazur | Standard | Consensus (hard-fork) | Accepted |
| Number | Title | Author | Type | Layer | Status / Discussion |
|---|---|---|---|---|---|
| EIP-2 | Homestead Hard-fork Changes | Vitalik Buterin | Standard | Consensus (hard-fork) | Final |
| EIP-7 | DELEGATECALL | Vitalik Buterin | Standard | Consensus (hard-fork) | Final |
| EIP-8 | devp2p Forward Compatibility Requirements for Homestead | Felix Lange | Standard | Networking | Final |
| EIP-141 | Designated invalid EVM instruction | Alex Beregszaszi | Standard | Consensus | Final |
| EIP-150 | Long-term gas cost changes for IO-heavy operations | Vitalik Buterin | Standard | Consensus (hard-fork) | Final |
| EIP-155 | Simple replay attack protection | Vitalik Buterin | Standard | Consensus (hard-fork) | Final |
| EIP-160 | EXP cost increase | Vitalik Buterin | Standard | Consensus (hard-fork) | Final |
Ethereum Classic Improvement Proposals (ECIPs), are technical write-ups that describe suggested changes to the Ethereum Protocol. Finalized proposals agreed up by volunteer client developers, and the users of the Ethereum Classic main net blockchain are implemented by Ethereum Classic client developers.
Every pull request will be reviewed and discussed by volunteer Ethereum Classic client developers and any developers on Github willing to contribute their well reasoned opinions. Regardless if there is general agreement you are able to use the information generated from the discussion to create a second draft. This can be done by either updating the pull request or submitting a new pull request. This process can be repeated (See figure 1) until the volunteer developer community agrees to add the pull request.
Having an ECIP within the folder of the repository does not make it a formally accepted standard until its status becomes Active. For an ECIP to become Active requires the mutual consent of the community. Those proposing changes should consider that ultimately consent may rest with the consensus of the Ethereum Classsic users.
ECIPs grew out of the now hard-forked Ethereum DAO hard-fork (or ETF) repository, at which time no other differences between Ethereum Classic/original main net and Ethereum DAO hard-forked besides the DAO hard-fork. Changes have since been added such as early defusal of the difficulty bomb.
Pushing changes to the protocol without consensus will cause a network split. The ECIP process should not be skipped, as previously done by Ethereum Foundation developers who unilaterally implemented a rushed hard-fork in the most widely used client thereby creating a network split at block 1920000.
The Ethereum Foundation raised money from the community to work towards the "mission to promote and support research, development and education to bring decentralized protocols", bur failed that goal when shortly after the DAO exploit was used Vitalik Buterin announced using the Ethereum Foundation blog that they had already unilaterally decided on forking. A chat log from an internal chat reveals this decision was made prior to the announcement, and comments like "default behavior of Geth to be pro-fork as per internal discussions" found in DAO hard-fork pull requests and the unwillingness to use their own proposal system show that the narrative in which the Ethereum Foundation followed the will of the community is clearly wrong. What the Ethereum foundation did was the opposite of decentralized decision making.
Decentralized decision making is part of the in-depth security that protects the integrity of the Ethereum Classic blockchain. It is critical for keeping the promise of "applications that run exactly as programmed without any possibility of downtime, censorship, fraud or third party interference."