Glossary

Censorship Attack

A censorship attack occurs when miners or validators deliberately exclude specific transactions from blocks to prevent them from being confirmed.

Key Takeaways

  • A censorship attack occurs when block producers deliberately refuse to include valid transactions, undermining the network's censorship resistance guarantees.
  • Censorship ranges from soft (delaying transactions by a few blocks) to hard (a majority of validators coordinating to permanently exclude specific addresses), with regulatory censorship falling somewhere in between when validators filter OFAC-sanctioned addresses.
  • Mitigation mechanisms like inclusion lists and proposer-builder separation reforms aim to make censorship economically and technically impractical at the protocol level.

What Is a Censorship Attack?

A censorship attack is an attempt by miners, validators, or block builders to prevent specific transactions from being included in blocks. Rather than attacking the network itself, the attacker abuses their role as a block producer to selectively filter which transactions get confirmed. The targeted transactions are valid according to protocol rules but are deliberately excluded based on criteria chosen by the censor: the sender's address, the recipient, the contract being called, or even the transaction's value.

Censorship attacks represent a fundamental threat to the permissionless nature of blockchains. If block producers can reliably exclude transactions, the network effectively requires their permission to transact. This transforms a decentralized system into one with gatekeepers, defeating the core purpose of censorship resistance.

The severity of a censorship attack depends on how much block production capacity the censor controls. A single miner skipping a transaction causes a minor delay. A majority coalition refusing to include certain transactions can block them indefinitely.

How It Works

Censorship attacks exploit the fact that block producers choose which transactions from the mempool to include in their blocks. Under normal operation, block producers are economically incentivized to include all valid transactions because each one pays a fee. A censoring block producer deliberately forgoes this revenue to exclude targeted transactions.

Soft Censorship

In a soft censorship attack, some block producers refuse to include certain transactions, but they lack enough collective block production share to prevent inclusion entirely. The censored transaction is delayed: it takes longer to confirm because it must wait for a non-censoring block producer to find a block. If censoring miners control 30% of hashrate, a transaction might take roughly 43% longer to confirm on average, but it still gets through.

Soft censorship is the most common form because it requires no coordination between block producers. Each censor simply omits targeted transactions from their own blocks. The economic cost is low: the censor loses only the fees from the excluded transactions.

Hard Censorship

Hard censorship requires a majority of block production capacity (over 50% of hashrate or stake) to coordinate. The censoring coalition not only excludes targeted transactions from their own blocks but also orphans or rejects any blocks from non-censoring producers that include those transactions. This creates a permanent exclusion: no valid block containing the censored transaction can make it into the canonical chain.

Hard censorship is functionally equivalent to a 51% attack because it requires majority control and the willingness to use it against other block producers. Research from Imperial College London confirmed that no proof-of-stake or proof-of-work protocol can resist censorship when censoring parties control more than 50% of the committee or hashing power.

Regulatory Censorship

Regulatory censorship occupies a middle ground. Block producers in jurisdictions with sanctions laws may voluntarily filter transactions involving addresses on government blacklists (such as the OFAC Specially Designated Nationals list). Unlike coordinated hard censorship, each validator acts independently based on their own compliance assessment.

This form of censorship became a major concern in the Ethereum ecosystem after the U.S. Office of Foreign Assets Control sanctioned Tornado Cash in August 2022. Some MEV-Boost relay operators, including Flashbots (which held roughly 80% of the relay market at the time), began filtering transactions that interacted with sanctioned addresses. By November 2022, approximately 80% of Ethereum blocks were being produced through OFAC-compliant relays.

The community responded by diversifying the relay market. Non-censoring relay operators such as Ultra Sound and Agnostic Relay gained validator adoption, and by May 2023 the share of OFAC-compliant blocks had fallen to around 27%. This episode demonstrated both the real danger of censorship in proof-of-stake systems with concentrated infrastructure and the market's ability to self-correct when alternatives exist.

Censorship Attack Vectors

Censorship can occur at multiple points in the transaction lifecycle:

  • Mempool filtering: nodes refuse to relay certain transactions, limiting their propagation across the peer-to-peer network
  • Block building: the entity constructing blocks (miner, validator, or dedicated block builder under PBS) omits targeted transactions from the block template
  • Relay filtering: in systems using MEV-Boost relays, the relay can refuse to pass through blocks containing certain transactions
  • Attestation withholding: validators refuse to attest to blocks that include censored transactions, weakening those blocks' finality

Each vector has different difficulty levels and effectiveness. Mempool filtering is easy to circumvent because users can submit transactions directly to a non-censoring node. Relay filtering is more impactful because it affects the entire block selection pipeline. Block builder censorship under PBS is particularly concerning because the builder market tends toward concentration.

Tainting Attacks

A more subtle form of censorship involves "tainting" addresses. An attacker sends small amounts of cryptocurrency from a sanctioned address to legitimate users. If validators censor transactions from addresses that have received funds from sanctioned sources, the attacker can effectively freeze innocent users' accounts. This technique was documented in research from Imperial College London (2023) and has been observed in practice via dust attacks from Tornado Cash addresses.

Bitcoin vs. Ethereum Censorship Resistance

Bitcoin and Ethereum differ significantly in their susceptibility to censorship attacks due to their consensus mechanisms and block production infrastructure.

Bitcoin's Model

Bitcoin's proof-of-work mining model offers relatively strong censorship resistance. Any miner can include any valid transaction in a block they mine. Because miners compete independently and there is no intermediary relay layer in the base protocol, a censoring miner simply leaves revenue on the table: other miners will include the censored transaction and collect the fees.

The economic incentive works against censorship. A miner who excludes a transaction loses the fee revenue, and a competing miner gains it. As long as mining pools remain diverse and no single entity controls majority hashrate, soft censorship causes only brief delays. Bitcoin's permissionless mining entry further strengthens this: anyone with sufficient hardware can mine, making it difficult to enforce universal compliance.

Ethereum's Model

Ethereum's shift to proof of stake and the adoption of proposer-builder separation introduced new censorship vectors. Under PBS, specialized block builders construct blocks and submit them through relays to proposers (validators). This pipeline creates multiple points where censorship can be injected: at the builder level, at the relay level, or at the proposer level.

The Tornado Cash episode showed this in practice. When dominant relays began filtering transactions, the majority of Ethereum blocks briefly excluded sanctioned addresses. The problem was not that validators individually chose to censor but that the infrastructure they relied on for MEV extraction performed the filtering on their behalf.

Mitigations and Countermeasures

Inclusion Lists

Inclusion lists are the primary protocol-level solution being developed for Ethereum. The original design (EIP-7547) allowed a block proposer to specify up to 16 transactions that the next block's builder must include. However, this approach was vulnerable because a single proposer could be bribed or coerced.

The successor proposal, FOCIL (EIP-7805), distributes this responsibility across a committee of 16 pseudorandomly selected validators for each slot. Committee members each publish their own inclusion list, and the fork-choice rule penalizes builders who fail to include listed transactions. This makes censorship significantly harder because an attacker would need to compromise multiple committee members simultaneously.

Relay Diversification

The Ethereum community's response to relay-level censorship was pragmatic: build non-censoring alternatives. The emergence of multiple independent relays with different filtering policies gave validators the choice to route blocks through non-censoring relays. By diversifying the relay market, the community reduced the censorship power of any single relay operator.

Direct Transaction Submission

Users can bypass mempool-level censorship by submitting transactions directly to non-censoring nodes or using private transaction channels. On Bitcoin, the peer-to-peer network makes this straightforward: connect to any non-censoring node and broadcast. On Ethereum, services like Flashbots Protect and private mempools offer direct builder submission, though these introduce their own trust assumptions.

Economic Incentives

Censorship carries an inherent economic cost. Every excluded transaction represents forfeited fee revenue. In competitive block production markets, this creates a natural pressure against censorship: non-censoring producers earn more per block because they include all fee-paying transactions. Over time, this incentive drives block production capacity away from censoring entities.

Why It Matters

Censorship resistance is not an abstract property: it determines whether a blockchain can serve as neutral financial infrastructure. If block producers can selectively exclude transactions, the network becomes a permissioned system in practice, regardless of its technical design.

For stablecoin payments and cross-border transfers, censorship resistance ensures that transactions settle regardless of the sender's jurisdiction or the political climate. Bitcoin's Layer 2 solutions like Spark inherit Bitcoin's base-layer censorship resistance while enabling faster and cheaper transactions. Because Spark transactions ultimately settle to Bitcoin's proof-of-work chain, they benefit from the same permissionless mining model that makes Bitcoin censorship resistant at the protocol level.

The tension between regulatory compliance and censorship resistance remains one of the most important open questions in blockchain design. Understanding censorship attacks is essential for evaluating the security guarantees of any blockchain network.

Risks and Considerations

  • Mining and staking centralization increase censorship risk: if a small number of entities control most block production, coordinated censorship becomes feasible without needing a formal agreement
  • Infrastructure concentration (relays, builders, RPC providers) creates chokepoints where censorship can be applied outside the consensus protocol itself
  • Regulatory pressure may increase over time as governments develop more sophisticated approaches to blockchain compliance, potentially requiring validators in specific jurisdictions to filter transactions
  • Tainting attacks can weaponize censorship mechanisms against innocent users, creating collateral damage beyond the censor's intended targets
  • Protocol-level mitigations like inclusion lists add complexity and may introduce new attack surfaces, requiring careful design and testing before deployment

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.