[Idea / Meta EIP] Protocol Maturity and Ossification Framework

EIPs EIPs Meta
1

Ethereum has well-developed processes for proposing, discussing, standardizing, and including changes to the protocol.

What I believe is missing is the inverse process:

How does Ethereum establish that some part of the protocol is mature, finished, and no longer intended to be changed?

This question is too foundational to remain implicit.

This is not a proposal to ossify Ethereum today, nor is it about any particular current EIP.

It is a proposal to begin defining how Ethereum can intentionally move from protocol development toward protocol maturity and eventual ossification, rather than leaving that question indefinitely implicit.

Motivation

For years I have assumed that Ethereum’s continued protocol development has a destination.

Ethereum is still being built. There are important unresolved problems around scaling, state, security, validator economics, and other areas. It therefore makes sense that the protocol continues changing today.

But this raises a separate and much longer-term question:

When does a protocol property stop being something we are trying to improve and become something future users are supposed to be able to rely upon?

The existing EIP process is very good at expressing:

Here is something about Ethereum we propose changing.

It does not appear to have an equivalent mechanism for expressing:

We consider this property mature. Ethereum intends for this to stop changing.

That distinction seems increasingly important as Ethereum matures.

EIP Final status does not solve this problem. Final describes the status of an EIP document or standard. It does not establish that the protocol property described by that EIP should never subsequently be modified by another EIP.

In other words, Ethereum has document finality, but not clearly expressed protocol-property finality.

I think we should consider creating a framework for the latter.

Why discuss this now?

A natural response may be that Ethereum is nowhere near finished, and therefore ossification can be discussed later.

I think that risks creating a circular problem:

We will decide what “finished” means when Ethereum is closer to being finished.

But without defining what maturity looks like, there may never be a point at which the protocol is recognized as finished. There will always be another optimization, another useful feature, another research direction, another technological development, and another proposed EIP.

If possible future improvement is sufficient reason to keep every protocol property permanently open to reconsideration, then ossification can be postponed indefinitely.

We should not wait until Ethereum is “finished” to define what “finished” means.

The framework for recognizing maturity should exist before we need to use it.

Proposal

I would like to explore a Meta EIP defining a protocol maturity / ossification framework.

Rather than attempting to ossify Ethereum as a whole at once, the framework could classify individual protocol properties or areas according to their intended maturity.

For example:

Active

The property remains under active research and development.

Substantial changes are expected and should be evaluated through the normal EIP process.

Stabilizing

The direction of the property is increasingly settled, but further significant changes are still expected or considered legitimate.

Protocol development should increasingly favor convergence and long-term stability.

Ossification Candidate

There is reason to believe the property has reached sufficient maturity.

Changes should face a substantially higher burden of justification, and the community should explicitly discuss whether the property is ready to become part of Ethereum’s permanent social contract.

Ossified

Ethereum has reached explicit social consensus that the property is no longer part of the normal protocol design space.

An ossified property is a normative commitment that future Ethereum protocol upgrades SHOULD NOT change it.

This does not mean that software somehow makes forks physically impossible. No decentralized protocol can prevent people from creating different software or a different chain.

Rather, it means that changing such a property would no longer be considered an ordinary Ethereum improvement. It would constitute a departure from an explicitly established Ethereum protocol commitment.

Classify properties, not EIPs

I think this distinction is important.

The object being ossified should generally not be an EIP document itself. It should be the protocol property or invariant established by one or more EIPs.

For example, Ethereum might eventually establish social consensus that some aspect of monetary policy, consensus behavior, execution semantics, or another fundamental property is mature and should no longer change.

That commitment should remain understandable even if the historical implementation of the property spans multiple EIPs.

The framework could therefore maintain a registry of protocol properties and their maturity status, with references to the EIPs that define or modify them.

Conceptually:

Protocol property Maturity Defining EIPs
Example property A Active EIP-XXXX
Example property B Stabilizing EIP-YYYY, EIP-ZZZZ
Example property C Ossification Candidate EIP-AAAA
Example property D Ossified EIP-BBBB

The examples above are deliberately abstract. This initial proposal is about creating the mechanism, not prematurely deciding which existing Ethereum properties belong in each category.

Ossification impact for future EIPs

If such a framework existed, Core EIPs could eventually be expected to identify their effect on protocol maturity.

For example, an EIP might contain an Ossification Impact or Protocol Maturity Impact section specifying:

  • Which existing protocol properties it modifies.

  • The current maturity status of those properties.

  • Whether it increases or decreases Ethereum’s remaining mutable protocol surface.

  • Whether it introduces another permanently configurable or governable parameter.

  • Whether the proposed functionality could reasonably exist above the base protocol instead.

  • Whether the proposal moves some area closer to a stable end state.

  • If it modifies an Ossification Candidate or Ossified property, why reopening that property is justified.

This introduces a question that I think is currently missing from protocol development.

Today we primarily ask:

Should Ethereum make this change?

As Ethereum matures, we should increasingly also ask:

Should this still be something Ethereum considers changeable?

Those are different questions.

Increasing burden of proof

A fundamental principle of this framework could be:

Protocol maturity SHOULD increase the burden of proof for protocol change.

During early development, a reasonable threshold may be:

Would this substantially improve Ethereum?

As a subsystem matures:

Is changing Ethereum itself necessary to solve this problem?

And once a property has explicitly ossified:

This property is no longer open to ordinary protocol redesign.

The existence of a potential improvement should not by itself imply that Ethereum should adopt it indefinitely.

There will always be potential improvements.

If Ethereum intends to become dependable infrastructure and a long-term settlement system, stability itself eventually becomes one of the properties we are optimizing for.

Why this matters

Without some concept of protocol-property finality, every fundamental property of Ethereum potentially remains subject to reconsideration by an indefinite succession of future developers, researchers, client teams, validators, stakeholders, and social majorities.

That may in fact be what the Ethereum community wants.

But if so, I think that should be explicit.

Conversely, if Ethereum is intended to progressively mature until large parts of the protocol become effectively permanent, I think that should be explicit too.

This proposal is therefore not intended to presuppose the answer.

It is intended to create a mechanism through which Ethereum can actually answer the question.

Open questions

I would particularly appreciate input on the following:

  1. Should Ethereum explicitly recognize eventual protocol ossification as an intended part of its lifecycle?

  2. Are categories such as Active → Stabilizing → Ossification Candidate → Ossified useful, or is another model preferable?

  3. What process should be required to mark a protocol property as an Ossification Candidate?

  4. What level and form of social consensus should be required to classify something as Ossified?

  5. Should future Core EIPs be required to identify which mature protocol properties they affect?

  6. Should an Ossified classification mean, normatively, that future EIPs modifying that property are considered incompatible with Ethereum’s established social contract?

  7. Are there protocol properties that the community already considers effectively ossified today? If so, can we identify them?

  8. Conversely, are there properties that Ethereum explicitly intends to keep mutable indefinitely? If so, can we identify those as well?

  9. Does the existing EIP process have an appropriate mechanism for expressing this already, or is this genuinely a missing layer?

Goal

The goal is clarity.

I would like Ethereum to have an explicit, inspectable record of:

  • what remains under development,

  • what is converging toward stability,

  • what the community is considering making permanent,

  • what has actually become part of Ethereum’s long-term protocol commitment,

  • and what, if anything, is intentionally expected to remain open to redesign indefinitely.

Ethereum has extensive machinery for deciding how things enter the protocol.

I think we should begin discussing the machinery for deciding when parts of the protocol have finished changing.