Vitalik Buterin Outlines Why Ethereum Needs Ossifiability for Long-Term Resilience

Vitalik Buterin published posts on January 12, 2026, sharing why Ethereum needs the ability to ossify for long-term resilience.

The Ethereum co-founder stated the blockchain must pass the walkaway test, meaning it should function without ongoing vendor updates. Ethereum is meant to be a home for trustless and trust-minimized applications in finance, governance, and other sectors.

The protocol must support applications that function like tools rather than services that need constant vendor maintenance.

Ethereum Must Pass Walkaway Test for Long-Term Resilience

Buterin stated Ethereum itself must pass the walkaway test. The blockchain is designed for trustless and trust-minimized applications.

It must support applications that function like tools, where ownership is transferred completely upon purchase. This contrasts with services that lose functionality when vendors lose interest in maintenance or face security compromises.

Building such applications is not possible on a base layer that depends on ongoing vendor updates to remain usable.

This applies even when the vendor is the all-core developers process. Ethereum, the blockchain, must have the traits developers strive for in Ethereum’s applications. The base layer cannot require continuous intervention.

This means Ethereum must reach a place where it can ossify if developers want to. The protocol does not have to stop making changes.

Ethereum must reach a point where its value proposition is not strictly dependent on any features not already built into the protocol. The ability to freeze development while maintaining full functionality defines ossifiability.

The walkaway test ensures that if all developers were to disappear tomorrow, Ethereum would continue to operate for decades.

Applications built on the blockchain would maintain functionality without protocol updates. This resilience creates the foundation for truly decentralized applications that outlast their creators.

Seven Requirements for Ethereum Protocol Ossification

Buterin shared seven specific requirements for Ethereum to achieve ossifiability. First, full quantum resistance is needed.

The protocol should resist delaying quantum resistance in favor of short-term efficiency gains. Individual users have that right, but the protocol should not.

Being able to say Ethereum’s protocol is cryptographically safe for a hundred years is something developers should strive to achieve as soon as possible.

Second, an architecture that can expand to sufficient scalability is required. The protocol requires properties that allow for expansion to many thousands of transactions per second over time.

This includes ZK-EVM validation and data sampling through PeerDAS. Ideally, further scaling occurs through parameter-only changes rather than hard forks. These changes should use the validator voting mechanism employed for gas limits.

Third, a state architecture that can last decades is necessary. This involves deciding and implementing partial statelessness and state expiry forms.

The solution must let Ethereum run with thousands of TPS for decades without breaking sync, hard disk, or I/O requirements. It also requires future-proofing tree and storage types for the long-term environment.

Fourth, a general-purpose account model through full account abstraction is needed. This means moving away from enshrined ECDSA for signature validation. Fifth, a gas schedule free of DoS vulnerabilities is required for both execution and ZK-proving.

Sixth, a PoS economic model that can last decades while remaining decentralized is needed. The model should support ETH usefulness as trustless collateral in governance-minimized stablecoins.

Seventh, a block building model resistant to centralization pressure while guaranteeing censorship resistance in unknown future environments is required.

Buterin stated developers should tick off at least one box every year, ideally multiple. The goal is to do the right thing once, based on knowledge rather than compromise halfway fixes.

Bandwidth Scaling Safer than Latency Reduction Approach

Buterin stated increasing bandwidth is safer than reducing latency. With PeerDAS and zero-knowledge proofs, developers know how to scale potentially thousands of times compared to current status.

The numbers become significantly more favorable with sharding. No law of physics prevents combining extreme scale with decentralization.

Reducing latency faces different constraints. Ethereum is fundamentally constrained by speed of light plus additional factors.

Nodes, especially attesters, must operate in rural environments worldwide, both in home and commercial settings outside data centers.

The protocol needs to support censorship resistance and anonymity for nodes, particularly proposers and attesters.

Running a node in non-concentrated locations must not only be possible but also economically viable. If staking outside New York City results in a 10% drop in revenues, more people will stake in NYC over time.

Ethereum itself must pass the walkaway test, so developers cannot build a blockchain depending on constant social re-juggling for decentralization. Economics cannot handle the entire load, but it must handle most of it.