Summary
Ethereum’s protocol decisions are grounded in values that go beyond technical efficiency: censorship resistance, credible neutrality, user sovereignty, and the ability to exit at any layer of the stack. The “Zero Option” (the ability to quit and still be okay) is the key property that distinguishes Ethereum from systems that require ongoing trust in intermediaries. The CROPS mandate (Censorship Resistance, Responsibility/Open Source, Privacy, Security) operationalizes these values for the EF in 2026.
The Zero Option
Definition: At every layer of the Ethereum stack, users should be able to stop relying on any particular party and still have their assets and history intact.
This is not primarily about:
- Transaction privacy (though that matters)
- Cheap gas (though that’s desirable)
- Fast finality (though that’s useful)
It’s primarily about:
- Can you exit? Can a user move from one wallet to another without the old wallet being able to block them?
- Can you self-custody? Can a user hold their own keys and transact without any intermediary’s permission?
- Can you run your own node? Can anyone verify the chain state without trusting any third party?
- Can you be censored into silence? Can any party prevent a transaction from ever being included?
The Zero Option keeps every intermediary in the stack honest: if they extract too much rent or behave badly, users can quit. Without this option, Ethereum degrades into a permissioned system dressed in decentralized clothing.
Stack Layers and Their Zero Option
| Layer | Current Zero Option | Risk |
|---|---|---|
| Wallet | Switch wallets; self-custody with hardware wallet | Wallet contract upgradability; key custody |
| RPC | Run your own node or switch RPC providers | Sybil-resistant alternatives are complex |
| Builder/relay | Fallback to local builds | Local builds ~60% less valuable; not truly viable |
| Validator | Permissionless staking (32 ETH) | High capital requirement; large stakers dominate |
| Protocol | Fork Ethereum | Nuclear option; rarely realistic |
The relay/builder layer is the weakest Zero Option today: if all major builders and relays start censoring, individual validators can’t effectively opt out (local builds are too uncompetitive). ePBS and decentralized building are the technical remedies.
CROPS Mandate (EF, 2026)
The Ethereum Foundation’s 2026 mission is structured around five properties — “non-negotiable as Ethereum scales”:
| Letter | Property | What it means |
|---|---|---|
| C | Censorship Resistance | No single party can prevent any valid transaction from eventually being included |
| R | Responsibility (Open Source) | All critical code is open source; EF acts in the ecosystem’s interest, not its own |
| O | Open Source | Software is freely inspectable, forkable, and modifiable |
| P | Privacy | Users have meaningful options for transacting without revealing identity or content |
| S | Security | Protocol is safe against both technical attacks and governance capture |
Why CROPS Over Simple “Decentralization”
“Decentralization” is underspecified — it can mean architectural, political, or logical decentralization (Vitalik’s taxonomy). CROPS is more precise:
- A highly centralized chain could still achieve CROPS if the centralization is at infrastructure layers that anyone can replicate
- A technically decentralized chain can fail CROPS if governance is captured or privacy is absent
CROPS and the 2026 Roadmap
Each upcoming upgrade must preserve all five CROPS properties:
- ePBS (Glamsterdam): improves C (builder censorship resistance via FOCIL); maintains O (open protocol)
- FOCIL (Hegotá): directly implements C (inclusion lists enforce transaction inclusion)
- LUCID (Hegotá): directly implements P (encrypted mempool)
- Frame Transactions / EIP-8141 (Hegotá): enables P (encrypted frame txs) and better S (PQ key rotation)
- Dynamic availability (future Goldfish): strengthens C and R (chain never halts)
Cypherpunk vs. Defipunk Tension
Cypherpunk values (the original): financial privacy, resistance to surveillance, individual sovereignty, zero trust in institutions.
Defipunk values (emerged with DeFi): efficient markets, maximum MEV capture, institutional-grade execution, regulatory compliance for mass adoption.
These are often in tension:
- KYC/AML on wallets: defipunk-compatible (institutions need it); cypherpunk-hostile (surveillance)
- OFAC-compliant relays: defipunk-compatible (legal compliance); cypherpunk-hostile (censorship)
- OFA with identity: defipunk-compatible (efficient execution); cypherpunk-hostile (deanonymization)
EF’s position: CROPS explicitly takes the cypherpunk side on values, while acknowledging that DeFi infrastructure has legitimate needs. The “hardness” track ensures performance improvements don’t come at the cost of cypherpunk properties.
Institutional Adoption and the Neutral Infrastructure Argument
“Ethereum: A Counterparty Without Counterparty Risk” frames Ethereum as:
- Neutral settlement infrastructure that works for institutions, not against them
- 400% PBS premium demonstrates that Ethereum can be financially competitive with centralized alternatives
- The key value proposition: Ethereum is the only system that can credibly commit to not changing the rules retroactively
This is only true if CROPS properties hold. An Ethereum that censors, lacks privacy, or can be governance-captured is not a credibly neutral counterparty — it’s just another intermediary.
The Paradox of Institutional Adoption
Institutions that demand:
- Censorship-resistant infrastructure → they need CROPS (to prevent their assets from being frozen by competitors or hostile states)
- Regulatory compliance → they need selective disclosure, not broad censorship
These are compatible: FOCIL + encrypted mempools enable both. Censorship resistance means any valid transaction gets included eventually; privacy means the content is hidden until execution. Compliance happens at the application/wallet layer, not the protocol layer.
”The Ethereum Foundation’s Commitment to DeFi” (Adjacent)
The EF has made explicit that it considers DeFi a legitimate and important use case, not incidental. Key commitments:
- Maintain EVM compatibility and stability for DeFi protocols
- Don’t prioritize L1 execution cost reduction at the expense of DeFi protocol security
- Work with DeFi protocols on MEV mitigation rather than against them
- Support privacy tooling that enables institutional participation without sacrificing censorship resistance
Related Pages
- FOCIL: Fork-Choice Enforced Inclusion Lists (EIP-7805) — Technical implementation of censorship resistance
- Encrypted Mempools — Technical implementation of privacy
- BuilderNet and Decentralized Block Building — Phase 3 as the technical realization of CROPS in the building layer
- Ethereum Protocol Roadmap 2026 — CROPS-grounded interpretation of 2026 upgrades
Key Sources
- Ethereum Preserves the Right to Quit (2026) — Zero Option; cypherpunk/defipunk tension; layer-by-layer exit analysis
- What Does the Ethereum Foundation Even Do? (2026) — CROPS mandate; EF’s role and commitments
- A Deeper Look at Priority: Hardness (Fredrik, Thomas, Parithosh, Mar 2026) — Hardness track; CROPS in practice