Understanding Censorship Resistance on Ethereum

Censorship resistance isn’t a nice-to-have—it’s a fundamental requirement for decentralized networks.

Strip that away, and what’s left? A permissioned, gatekept system controlled by a handful of players. The exact thing blockchains were built to replace.

Ethereum for example operates on neutrality. Transactions should be included because they’re valid, not because they passed some arbitrary approval process. That’s the deal. No special treatment. No preferential lanes. No veto power.

Ethereum only works if it plays by its own rules. That’s where clients come in. They validate transactions, execute them against smart contracts, and make sure the network stays secure—without bias, without gatekeepers. Every Ethereum client, whether it’s Lodestar or Lighthouse, is built with one important ethos in mind: to uphold Ethereum’s permissionlessness via decentralization.

No single entity should control the network, nor should the network depend fully on one client. It’s not just software—it’s a commitment to keeping Ethereum open, neutral, and unstoppable.

What is censorship?

Blockchain Censorship isn’t some abstract concept. It’s when valid transactions are deliberately blocked, delayed, or manipulated.

It happens at different levels:

• Validators, relayers, or block builders rejecting transactions – Whether due to regulatory pressure, personal bias, or financial incentives.
• Block suppression & reorgs – Dropping or rewriting history to selectively exclude transactions. Playing timing games, withholding/delaying blocks to maximize MEV.
• Network-level censorship – Nodes, RPCs, or infrastructure providers refusing to relay certain transactions. 

While its never really happened before, theoretically, malicious actors could even DDOS proposers and censor them by causing them to miss their proposals.

And yet, Ethereum fights back. The way the network is designed, even if a validator or infrastructure provider—like a centralized sequencer on L2—tries to censor transactions, users have ways around it—whether by using alternative RPCs, submitting transactions directly on L1, or leveraging multiple clients.

A perfect example? Soneium.

• Sony launched an L2.
• They tried to enforce transaction censorship at the RPC level.
• Didn’t work.
• Users bypassed their restrictions by submitting transactions directly to Ethereum L1—Where Sonieum inherits the base decentralization of the Layer 1’s censorship resistance.

Decentralization worked—but not without friction. No single entity, not even a massive corporation, could fully stop Ethereum from remaining permissionless, but bypassing censorship isn’t easy.

While it's technically possible to submit transactions around centralized sequencers through L1, most users don’t know how to craft their own calldata or interact with Ethereum outside of a wallet interface that relies on a centralized RPC.

The reality is, decentralization isn’t just about technical capability—it’s about accessibility. True censorship resistance means making these workarounds more user-friendly, so people aren’t locked out simply because they don’t know the manual override exists.

Decentralization did what it was supposed to do—Ethereum’s censorship resistance isn’t a feature. It’s a reflex. The network fights back, routes around obstacles, and stays open.

Upholding censorship resistance

Ethereum wasn’t built with perfect censorship resistance from day one—it’s a constant process of adaptation.

The network sets rules, actors try to game them, and then the protocol evolves to close the gaps. It’s a cat-and-mouse game where decentralization isn’t just assumed—it’s actively maintained.

Clients play a critical role in helping the network navigate the tradeoffs and edge cases that come with balancing neutrality, security, and usability.

Researchers and client teams work to minimize censorship and prevent centralization from creeping in, but there’s no final solution—just an ongoing effort to keep Ethereum as open and permissionless as possible.

Protocol adherence

Clients ensure all valid transactions and blocks are processed in accordance with the consensus specification which outlines what makes a block valid or invalid to compete as the canonical head of the chain.

But inclusion isn’t guaranteed. Right now, Ethereum’s censorship resistance comes from the fact that no single entity controls the network.

• If a transaction is valid, it should be included.
• Block proposers can exclude transactions—but they don’t control every block.

If they try? The transaction will find its way into the chain through another method or route. It might cost more and take longer than usual, but the network can’t censor a transaction forever because no single entity controls the network. There’s always going to be another builder or even a solo staker who can include it from the public mempool. And if all else fails, the censored transaction can just pay a higher priority fee to get included.

A censored transaction doesn’t disappear—it just takes a different path. No single participant can enforce total censorship, but making Ethereum fully resistant to censorship is an ongoing challenge.

Fair block proposals & attestations

Validators propose blocks and attest to the validity of others' blocks. Transactions should be processed based on protocol rules—not off-chain influence. This is a big reason why local block building is so important. But we’re seeing a shift in how people submit transactions.

With the rise of private transaction submissions (for MEV protection and privacy reasons), many block builders now operate in opaque environments, deciding which transactions get included with little oversight. This is one of the biggest problems, eroding the neutrality that used to be way more transparent.

Inclusion shouldn’t be up for debate.

Unless you're paying a priority fee, block builders and proposers shouldn’t be favouring one transaction over another—or worse, ignoring them altogether. But reality doesn’t always match the ideal.

Inclusion Lists (like the proposed FOCIL, EIP-7805) are designed to force-in transactions that might otherwise be censored, ensuring they make it into the block-building process. The goal? To enhance Ethereum’s censorship resistance by allowing a committee of validators to enforce transaction inclusion, ensuring that no single block builder can quietly filter transactions out. Unlike other mechanisms that rely on economic incentives, FOCIL operates on an honesty assumption—requiring just one validator in the committee to act fairly for the system to work.

But it’s not a perfect fix.

Most validators outsource block production to MEV-boost relays—over 90% of them because it’s profitable. This puts transaction inclusion largely in the hands of a few builders, who are incentivized to maximize MEV, not necessarily uphold neutrality.

Right now, Ethereum’s censorship resistance hinges on competition—if one builder refuses to include a transaction, another can pick it up, a solo staker can grab it from the public mempool, or a higher priority fee can push it through. But as more transactions bypass the public mempool entirely, this safety net weakens.

The challenge ahead isn’t just maintaining Ethereum’s neutrality—it’s designing incentives that make neutrality the default.

Resilient networking layer

Ethereum’s network layer is designed to make censorship impractical. Clients ensure transactions and blocks propagate peer-to-peer, with no single point of failure. If one block builder or proposer refuses to include a transaction, plenty of others in the network will, keeping Ethereum decentralized as it scales.

• Transactions and blocks propagate peer-to-peer.
• If a block builder or relay refuses to include a transaction, users can bypass it.

Slashing & accountability

Validators trying to undermine the system aren’t just a risk—they’re a liability. But when it comes to censorship, the reality is more complicated. Right now, transaction censorship itself isn’t slashable—there’s no direct penalty for validators or builders who exclude transactions.

But that doesn’t mean there’s no accountability.

Validators who break Ethereum’s fundamental consensus rules—like proposing conflicting blocks or submitting attestation violations—do get slashed, losing a portion of their stake.

Meanwhile, builders who submit optimistic invalid blocks that later get rejected face their own penalties. These mechanisms reinforce the network’s security, even if censorship itself isn’t yet directly punishable.

Ethereum’s resilience doesn’t come from a single enforcement layer—it comes from a mix of incentives, competition, and ongoing protocol improvements to close censorship gaps.

Client Diversity

Ethereum thrives on diversity—not just in its community but in its software. A network dominated by a single client isn’t just centralized—it’s fragile.

If everyone used Geth, a critical bug could take down the entire execution layer. If everyone used Prysm, the consensus layer would be at risk. That’s why no single client should ever make up more than 1/3 of the network.

More implementations = more resilience.

A diverse client ecosystem ensures Ethereum stays decentralized. Ethereum’s security doesn’t come from one entity, one company, or one decision-maker. It comes from the collective effort of an entire ecosystem, ensuring that no single flaw can bring the network down.

Ethereum’s future is a choice

This is a collaborative effort. No single client—no single team—can uphold Ethereum’s values alone. Decentralization isn’t self-executing. It requires constant reinforcement from validators, client teams, developers, and the broader community.

Ethereum isn’t a get-rich-quick chain—it’s a long-term bet on decentralized infrastructure. If you’re here for a quick exit, you’re in the wrong place. But if you’re here to build, to fight for decentralization, and to keep this system open and resilient, then you’re in the right place.

Failed L2s? Collapsed bridges? Projects that didn’t make it? That’s not failure—it’s compost. Ethereum grows on top of it. Like any real system, it evolves, sheds dead weight, and strengthens over time. The worst thing we could do is let this turn into a zero-sum game. We aren’t competing with each other—we’re competing with stagnation, centralization, and the idea that power should stay in the hands of a few.

Ethereum wasn’t built to be another financial instrument. It’s supposed to be a new way to build systems that work for everyone. And that’s still within our reach—if we make the choice to keep building.

Contribute to Lodestar! 

At ChainSafe, we’re constantly seeking exceptional talent to join our teams and welcome contributors to the Lodestar consensus client. To any TypeScript developers looking to take on challenges and push the boundaries of the JavaScript ecosystem, get in touch!

To get involved, visit our GitHub repository

If you wish to contact the team, join Chainsafe's Discord in the #lodestar-general channel or explore our job openings page. Alternatively, you can email us at info@chainsafe.io.

Remember to visit our official website and follow us on Twitter for more updates.

Lodestar is built and maintained by ChainSafe

Website | Youtube | Twitter | Linkedin | GitHub