In the context of Ethereum's Proposer-Builder Separation (PBS) architecture, builder censorship occurs when a specialized block builder—an entity that constructs the most profitable block from the mempool—chooses to filter transactions based on their origin or destination. This is distinct from validator censorship, where the block proposer (validator) rejects a valid block. Common targets include transactions interacting with sanctioned smart contracts, such as privacy tools like Tornado Cash, or addresses on government blacklists. The builder's economic incentive to win the block auction by offering the highest bid to the proposer can be overridden by legal compliance requirements or the risk of sanctions against the builder's own operations.
Builder Censorship
What is Builder Censorship?
Builder censorship is a form of transaction-level censorship in proof-of-stake blockchains, where a block builder (or proposer-builder) intentionally excludes certain transactions from a block, often to comply with external regulations or sanctions.
The technical mechanism relies on the builder's control over the block construction process. Builders run sophisticated algorithms to extract Maximum Extractable Value (MEV) by ordering transactions. To censor, they simply omit specific transactions from their optimization process, preventing them from ever being included in their proposed block bundle. This creates a risk for network neutrality, as transactions can be silenced not by the protocol's consensus rules but by the discretionary actions of a few centralized building entities. The degree of censorship threat is directly linked to the centralization of the block building market, where a small number of dominant builders could effectively control transaction inclusion.
Protocol-level countermeasures are being actively researched and developed to mitigate builder censorship. Inclusion lists are a primary Ethereum roadmap proposal, allowing a block proposer to mandate the inclusion of specific, otherwise-censored transactions from the mempool, forcing the builder to add them to the block. Threshold Encryption schemes, such as the one proposed for MEV-Boost, aim to hide transaction details from builders until after they have committed to including them, removing their ability to discriminate based on content. These solutions seek to preserve credible neutrality and permissionless access—core tenets of decentralized blockchain networks—by reducing the discretionary power of intermediaries in the block production supply chain.
How Builder Censorship Works
Builder censorship is a form of transaction-level censorship where a block builder intentionally excludes or reorders transactions to comply with external mandates, such as government sanctions, rather than for economic gain.
In a proposer-builder separation (PBS) architecture, specialized actors called block builders assemble the contents of a block. Builder censorship occurs when a builder, often under legal or regulatory pressure, filters transactions from its mempool based on criteria like sender or recipient addresses. For example, a builder might refuse to include transactions interacting with a sanctioned smart contract or a specific wallet. This filtering happens before the block is proposed, making it a proactive form of censorship at the point of block construction.
The censorship mechanism typically involves a builder running a compliance node that screens incoming transactions against a denylist of addresses. Transactions from or to these addresses are either dropped entirely or deprioritized. This is distinct from validator censorship, where a validator refuses to propose a valid block. In builder censorship, the block is still proposed and validated, but its composition is artificially constrained. The economic pressure to win block auctions can incentivize builders to comply with such mandates to avoid legal risk, even if it reduces their potential maximal extractable value (MEV).
The primary concern with builder censorship is its potential to undermine blockchain neutrality and permissionlessness. If a dominant builder or cartel of builders enforces filtering, certain users may be effectively deplatformed from the base layer. Mitigations are an active area of research and development, including censorship-resistance mechanisms like inclusion lists, where validators can force the inclusion of specific transactions, and cryptographic techniques like threshold encryption that hide transaction details from builders until after the block is committed.
Key Characteristics of Builder Censorship
Builder censorship refers to the ability of a block builder to exclude or reorder transactions based on criteria other than fee priority, challenging the neutrality of a blockchain's transaction processing.
Transaction Exclusion
The most direct form of censorship, where a block builder deliberately omits valid transactions from a proposed block. This can target transactions from specific addresses (e.g., sanctioned entities), interacting with certain smart contracts (e.g., privacy tools like Tornado Cash), or containing specific data. It violates the permissionless principle by denying service based on content.
Transaction Reordering (Time-Bandit Attacks)
A sophisticated form of manipulation where a builder reorders transactions within a block to extract Maximal Extractable Value (MEV) or disadvantage certain users, without outright exclusion. For example, they might front-run a large trade. This distorts the fair first-come, first-served model implied by the mempool and can be economically damaging.
Relay-Level Filtering
Censorship can be enforced by the relay, an intermediary between searchers/builders and validators. Relays can filter transactions before builders even see them, acting as a centralized chokepoint. After the OFAC sanctions on Tornado Cash, some major relays began filtering sanctioned addresses, demonstrating this infrastructure-level risk.
Economic Incentives & Centralization
Builder censorship is often driven by economic incentives and centralization risks. Large, dominant builders (or builder pools) have the market share to impose their will without significant revenue loss. Furthermore, builders may comply with external legal pressures (e.g., regulatory sanctions) to avoid liability, prioritizing legal compliance over network neutrality.
Distinction from Validator Censorship
It is crucial to distinguish builder censorship from validator censorship. In Proposer-Builder Separation (PBS) designs, the validator (block proposer) merely accepts the highest-paying block from a builder. A validator rejecting a censored block is practicing resistance; the censorship originates with the builder. This separation complicates accountability and mitigation strategies.
Mitigation: Censorship Resistance
The ecosystem develops countermeasures to preserve neutrality:
- Permissionless Builder Entry: Low barriers to becoming a builder increase competition.
- CR Lists: Commit-Reveal schemes hide transaction content until the block is committed.
- Decentralized Relays: Reducing reliance on a few trusted relays.
- Enshrined PBS: Protocol-level design to enforce builder neutrality and reduce trusted components.
Motivations and Triggers for Censorship
Block builders may exclude or reorder transactions for various technical, financial, or regulatory reasons, impacting network neutrality.
Regulatory Compliance
Builders may be compelled by legal authorities to censor transactions from sanctioned addresses or entities. This is a primary vector for OFAC compliance, where builders filter transactions to or from addresses on the SDN List. This creates a conflict between decentralized network principles and jurisdictional law enforcement.
Maximal Extractable Value (MEV)
The pursuit of MEV is a major economic driver for transaction reordering and exclusion. Builders may censor transactions to:
- Front-run user trades by inserting their own.
- Back-run profitable transactions to capture arbitrage.
- Exclude transactions that would reduce the profitability of their own MEV bundles.
Technical Constraints & Failures
Censorship can occur unintentionally due to system limitations or bugs.
- Resource exhaustion: A builder's node may drop transactions if its mempool is full.
- Gateway filtering: Relays or builder software may have faulty logic that incorrectly filters valid transactions.
- Network latency: Slow propagation can cause transactions to be missed, effectively censoring them for a specific block.
Economic Pressure & Cartels
Dominant builders or builder cartels may collude to censor transactions for mutual benefit, creating a centralized point of control. This can be driven by:
- Exclusive order flow agreements with searchers or applications.
- Retaliation against protocols or users.
- Creating artificial scarcity to increase priority fee prices.
Protocol-Level Rules
Some blockchain protocols have built-in rules that mandate transaction exclusion. For example:
- Spam prevention: Networks may enforce minimum fees or computational limits, causing low-fee transactions to be ignored.
- Consensus faults: Transactions triggering certain smart contract vulnerabilities or consensus failures may be rejected by client software.
Relay Policies
In Proposer-Builder Separation (PBS) architectures, relays act as intermediaries. Their operational policies can be a source of censorship if they:
- Refuse to propagate blocks containing certain transactions.
- Impose additional filtering criteria on top of what builders submit.
- Experience downtime or selective connectivity issues.
Comparison: Builder vs. Validator Censorship
This table compares the two primary mechanisms for transaction censorship in a Proposer-Builder Separation (PBS) architecture, detailing their technical implementation, detection difficulty, and mitigation strategies.
| Feature | Builder Censorship | Validator Censorship |
|---|---|---|
Definition | Exclusion of transactions at the block builder level, before a block is proposed. | Rejection of a valid, builder-produced block at the validator (proposer) level. |
Primary Actor | Block Builder | Validator (Block Proposer) |
Stage in Block Production | During block construction | During block proposal and attestation |
Detection Difficulty | High - Opaque process within the builder. | Low - Publicly observable on-chain event. |
Common Mitigation | Permissionless block building, inclusion lists, MEV smoothing. | Proposer accountability (e.g., slashing), forced builder rotation. |
Primary Enforcement Vector | Builder's local mempool and orderflow agreements. | Validator's client software and governance policies. |
Impact on Chain Liveness | Indirect - Can delay but not permanently prevent inclusion. | Direct - Can cause an empty slot if no compliant block is found. |
Example Scenario | A builder excludes transactions from a sanctioned address per OFAC compliance. | A validator rejects a block because it contains transactions from a sanctioned address. |
Ecosystem Context and Protocols
Builder censorship refers to the ability of specialized block producers (builders) to exclude or reorder transactions based on their content or origin, a centralization risk in modern blockchain architectures like Proposer-Builder Separation (PBS).
Proposer-Builder Separation (PBS)
Proposer-Builder Separation (PBS) is a design pattern, most notably implemented in Ethereum's post-Merge architecture, that decouples the roles of block proposal and block construction. This creates a market where:
- Validators (Proposers) choose the most profitable block from competing builders.
- Builders compete to create the most valuable block bundle from the mempool. This separation introduces the risk that builders, not validators, become the primary censorship vector.
MEV-Boost & Centralization
MEV-Boost is an out-of-protocol implementation of PBS used by most Ethereum validators. It allows proposers to receive blocks from a competitive marketplace of builders. The centralization risk arises because:
- A small number of dominant builders (e.g., Flashbots, bloXroute) control a majority of block space.
- These builders can implement transaction filtering policies, such as complying with OFAC sanctions lists, effectively censoring transactions at the network layer.
- Proposers are economically incentivized to choose the highest-paying block, regardless of its censorship status.
Censorship Resistance Mechanisms
Protocols and communities deploy several countermeasures to mitigate builder censorship:
- Inclusion Lists: A cryptographically committed list of transactions that the next proposer must include, enforced at the consensus layer (e.g., Ethereum's PBS with inclusion lists).
- Builder Reputation Systems: Monitoring and slashing builders for consistent censorship.
- Decentralized Builder Networks: Efforts to lower barriers to entry for smaller, independent builders.
- Sufficient Decentralization: Ensuring no single builder controls >33% of block production to prevent finality delays.
The OFAC Compliance Example
A concrete example of builder censorship is compliance with the U.S. Office of Foreign Assets Control (OFAC) sanctions. Following the Tornado Cash sanctions in 2022:
- Major block builders began filtering out transactions interacting with sanctioned smart contract addresses.
- This led to a significant portion of Ethereum blocks being OFAC-compliant, meaning they excluded these transactions.
- The event sparked a major debate on the credible neutrality of Ethereum and the risks of regulatory capture at the infrastructure layer.
Enshrined PBS vs. Out-of-Protocol
A key architectural debate is where PBS logic should reside:
- Out-of-Protocol (MEV-Boost): Faster to implement but leads to centralization and opaque markets. Censorship is a market failure.
- Enshrined PBS (in-protocol): PBS logic built directly into the consensus protocol. Aims to be more transparent, programmable, and resistant to censorship through mechanisms like partial block auctions and proposer commitments. This is a long-term goal for Ethereum to address the systemic risks of the current builder market.
Related Concepts & Risks
Builder censorship is interconnected with other ecosystem risks:
- MEV (Maximal Extractable Value): The profit motive that drives the builder market; censorship can be a side effect of profit maximization.
- Relay Centralization: Builders submit blocks through trusted relays, which can also censor.
- Network-Level Censorship: If all major builders and relays collude, they can effectively blacklist addresses or transactions, breaking core blockchain properties.
- Validator Decentralization: The ultimate mitigation is a highly decentralized set of validators willing to propose non-censoring blocks, even at a profit sacrifice.
Security and Decentralization Implications
Builder censorship refers to the ability of block producers (builders) to selectively exclude or reorder transactions, challenging the permissionless and neutral nature of a blockchain. This section details its mechanisms, consequences, and countermeasures.
The MEV-Boost Relay as a Chokepoint
In Ethereum's post-merge architecture, builders construct blocks and submit them to validators via intermediaries called relays. A relay can censor transactions by refusing to forward blocks containing specific transactions (e.g., from OFAC-sanctioned addresses). This creates a centralized point of failure, as validators rely on a limited set of trusted relays for block proposals.
Threat to Credible Neutrality
A core tenet of public blockchains is credible neutrality—the protocol does not discriminate between users or transactions. Builder censorship directly violates this principle. If dominant relays enforce external regulatory lists, the network ceases to be a neutral settlement layer, potentially undermining its value proposition and trust model.
Enshrined Proposer-Builder Separation (PBS)
A long-term protocol-level solution is enshrined PBS, where the separation of block building and proposal roles is baked directly into the Ethereum consensus layer. This aims to:
- Remove the need for trusted relays.
- Use cryptographic commitments (like commit-reveal schemes) to prevent censorship.
- Allow validators to claim MEV rewards without relying on centralized intermediaries.
Sufficient Decentralization of Relays
A near-term mitigation strategy is ensuring no single relay dominates. If relay client software is easy to run and the relay set is diverse and geographically distributed, validators can choose from many options. A validator switching away from a censoring relay reduces its influence, creating economic pressure for neutrality.
Censorship Resistance via Inclusion Lists
An inclusion list is a protocol feature that allows a validator to specify a set of transactions that must be included in the next block if they are valid and have paid sufficient fees. This acts as a backstop, guaranteeing transaction inclusion even if all available builders attempt to censor them, preserving liveness.
The Builder Power Trilemma
Builders face a fundamental trade-off between three properties:
- Censorship Resistance: Not excluding valid transactions.
- MEV Capture: Maximizing extractable value for the validator.
- Block Profitability: Creating the most valuable block for the proposer. Optimizing for maximum MEV or profit can incentivize centralization and create conditions ripe for censorship, highlighting the need for careful protocol design.
Mitigation Strategies and Solutions
A set of technical and economic mechanisms designed to counteract the ability of block builders to exclude or reorder transactions based on content, source, or other non-economic criteria.
Proposer-Builder Separation (PBS)
A protocol-level architecture that formally separates the roles of block proposer (validator) and block builder. In PBS, builders compete in a marketplace to construct the most profitable block, which proposers then simply attest to. This design aims to prevent a single entity from controlling transaction inclusion and ordering by distributing power. Ethereum's PBS roadmap includes in-protocol PBS via ePBS as a long-term solution.
Commit-Reveal Schemes
A cryptographic technique where a builder commits to a block's content (via a hash) without revealing it, then reveals the full block after the commitment is accepted. This prevents proposers from stealing profitable block templates (the MEV theft problem) while allowing for a fair builder marketplace. It's a key component enabling a trustless PBS ecosystem by separating the selection of a builder from the viewing of their block.
Inclusion Lists
A mechanism that allows a block proposer to mandate the inclusion of specific transactions. The proposer provides a list of transactions that must be included in the next block if they are valid and have paid sufficient gas. This acts as a backstop against censorship, ensuring that even if all builders collude to censor a transaction, the proposer can force its inclusion. It's considered a practical near-term mitigation.
Decentralized Builder Networks
Networks like SUAVE (Single Unifying Auction for Value Expression) that aim to decentralize the block building process itself. Instead of relying on a few centralized builder entities, these protocols create a permissionless marketplace for searchers (who find MEV opportunities) and builders (who construct blocks). By distributing the construction role across many participants, they reduce the risk of coordinated censorship.
Censorship-Resistant Ordering Rules
Protocol rules that define a canonical transaction ordering independent of builder discretion. Examples include First-Come-First-Served (FCFS) in mempools or Timestamp-Based Ordering. Fair Sequencing Services (FSS) use cryptographic techniques like threshold encryption to create a neutral order before builders see transactions. These rules remove the builder's ability to reorder transactions for maximal extractable value (MEV) or censorship.
Economic Penalties & Enforcement
Slashing conditions or economic penalties within the consensus protocol to punish provable censorship. For example, a protocol could require builders to attest that they included all eligible transactions from the mempool, with slashing for false attestation. Enshrined PBS designs often include such cryptographic accountability. The challenge is defining "censorship" in a measurable, objective way that doesn't harm legitimate builder optimization.
Common Misconceptions About Builder Censorship
Builder censorship is a complex topic in Ethereum's post-Merge landscape, often misunderstood. This glossary clarifies key technical concepts and dispels frequent inaccuracies surrounding the roles of builders, proposers, and the mechanisms of MEV.
Builder censorship is the act where a block builder intentionally excludes or reorders transactions from the public mempool to prevent them from being included in a new block, often to comply with external regulations or internal policies. This is distinct from validator (proposer) censorship. The mechanism works within the proposer-builder separation (PBS) framework: specialized builders compete in a builder market to create the most profitable block, which is then sold to a validator for proposal. A censoring builder simply omits certain transactions from their block bid, and if a validator selects that bid, the censored transactions are excluded from the chain.
Frequently Asked Questions (FAQ)
Builder censorship refers to the ability of block producers to exclude or reorder transactions, raising concerns about network neutrality and decentralization. This section addresses common technical and operational questions.
Builder censorship is the act where a block builder (or proposer) intentionally excludes or reorders valid transactions from a block, typically for financial gain or to comply with external regulatory pressure. This is a significant concern in Proof-of-Stake (PoS) networks, especially with the rise of proposer-builder separation (PBS) architectures like those in Ethereum. In PBS, specialized builders construct blocks and sell them to proposers, creating a potential point of centralized control where a dominant builder could censor transactions from specific addresses or protocols, undermining the network's permissionless nature.
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.