Ethereum Improvement Proposal (EIP)

Een Ethereum Improvement Proposal doorloopt een formele levenscyclus die is vastgelegd in EIP-1, het document dat het proces zelf beschrijft. Zodra een voorstel is ingediend, wordt het als Draft samengevoegd door een vrijwillige EIP-editor, wiens taak puur procedureel is: opmaak en structuur controleren, niet het idee beoordelen. Vandaar kan het doorstromen naar Review, daarna Last Call (een verplichte periode van minimaal 14 dagen voor publiek commentaar), en uiteindelijk Final. Voorstellen die zes maanden of langer stilliggen krijgen de status Stagnant, en auteurs kunnen ze volledig intrekken.

EIP's vallen in een aantal categorieën. Core-EIP's veranderen consensusregels en vereisen gecoördineerde client-upgrades die worden geactiveerd via een netwerkbrede hard fork. Networking- en Interface-EIP's gaan over peer-to-peer-protocollen en conventies op taalniveau. ERC-EIP's definiëren standaarden op applicatieniveau die ontwikkelaars vrijwillig toepassen, zoals ERC-20 voor fungible tokens of ERC-721 voor NFT's. Een aparte categorie Meta regelt proceswijzigingen in plaats van het protocol zelf.

Er is geen formele stemming. Core-EIP's komen tot stand via geleidelijke consensus tussen client-teams tijdens de All Core Devs-calls; een EIP wordt pas Final zodra deze daadwerkelijk is geactiveerd op mainnet. Bekende voorbeelden zijn EIP-1559, dat de opbouw van transactiekosten herstructureerde, en EIP-4844, dat blob-opslag voor rollups introduceerde. Het systeem, gemodelleerd naar het BIP-proces van Bitcoin, geeft iedereen in de Ethereum-gemeenschap de mogelijkheid om wijzigingen transparant voor te stellen en te bediscussiëren.