Worked example · 2022-20

OFAC-compliance builder censorship of Tornado Cash transactions — Ethereum — 2022–2025 (ongoing)

Loss: structural — ongoing censorship of Ethereum transactions interacting with OFAC-sanctioned addresses (primarily Tornado Cash contract addresses) by major Ethereum block builders. Through 2022–2025, approximately 30-40% of Ethereum blocks were produced by OFAC-compliant builders that excluded Tornado Cash-linked transactions, causing measurable inclusion delays for censored transactions. The loss is measured in delayed or excluded transactions rather than in direct dollar extraction — but the censorship represents a structural T14.005 surface where the block-construction layer systematically excludes specific transaction classes, reducing Ethereum's censorship-resistance guarantees.
OAK Techniques observed: OAK-T14.005 (Builder Censorship MEV Extraction) — primary in the OFAC-compliance censorship sub-pattern. Ethereum block builders — the entities that construct execution-payload blocks under PBS — deliberately exclude transactions that interact with OFAC-sanctioned addresses (Tornado Cash contract addresses) from their block proposals. The censorship is builder-level: the builder decides what to include in the block, and the MEV-Boost relay delivers the builder's pre-filtered block to the proposer. The result is a bifurcated builder landscape where censored transactions experience longer inclusion delays (waiting for a non-censoring builder's slot) but are not permanently excluded. OAK-T14.002 (MEV-Boost Relay Attack — structurally adjacent; relay-level censorship compounds the builder-level censorship when OFAC-compliant relays further filter blocks or refuse to deliver blocks containing censored transactions).
Attribution: unattributed No individual builder operator is "the attacker" — the censorship is a systemic property of the PBS architecture where major builders (Flashbots Builder, and others operating under U.S. regulatory jurisdiction) comply with OFAC sanctions by filtering sanctioned addresses from their block templates. The builders are acting within their legal obligations, not as malicious actors. The T14.005 classification captures the structural surface — the PBS architecture enables builder-level censorship regardless of the builder's motivation (profit-driven or compliance-driven).
Key teaching point: Builder-level censorship under PBS is a structural T14.005 surface regardless of the builder's motivation — profit-driven MEV censorship and regulatory-compliance censorship share the same infrastructure-layer mechanism (the builder's control over block-content selection) and produce the same defender-relevant outcome (transactions are excluded from blocks that would otherwise include them). The Tornado Cash / OFAC-compliance case is the most extensively measured and quantitatively documented instance of builder-level censorship — it demonstrates that the PBS architecture's concentration of block-construction power in a small number of builders creates a censorship surface even when the builders are acting in good-faith compliance with legal obligations.

Summary

Following OFAC's August 2022 addition of Tornado Cash to the SDN (Specially Designated Nationals) list, several major Ethereum block builders began censoring transactions that interact with Tornado Cash contract addresses. The builders — operating under U.S. regulatory jurisdiction — excluded Tornado Cash-linked transactions from their block templates to comply with sanctions regulations.

The censorship operated at the builder layer:

Builder constructs block template. A builder (e.g., Flashbots Builder) constructs an execution-payload block. During block-content selection, the builder filters out any transaction that interacts with an OFAC-sanctioned address (Tornado Cash contract addresses).
Builder submits block to relay. The builder submits the pre-filtered block to a MEV-Boost relay. The relay delivers the block to the proposer (validator) for the current slot.
Proposer signs the block. The proposer signs and proposes the block, which may not contain Tornado Cash-linked transactions that would have been included by a non-censoring builder.
Censored transactions wait. Censored transactions remain in the mempool and must wait for a slot assigned to a non-censoring builder before they can be included in a block.

The result is a measurable inclusion-delay penalty for transactions interacting with Tornado Cash: transactions that would be included within 1-2 blocks under an uncensored builder may wait 3-6 blocks (or more, depending on the non-censoring builder's slot share) before inclusion. The transactions are not permanently excluded — a non-censoring builder (BeaverBuild, Titan, Rsync, and others that do not apply OFAC-compliance filtering) will eventually include them — but the inclusion delay is material and systematic.

Empirical measurement (Wahrstatter et al., 2023) documented:

Through 2022–2025, approximately 30-40% of Ethereum blocks were produced by OFAC-compliant relays/builders.
Tornado Cash-linked transactions experienced a median inclusion delay of 2-3x the baseline for comparable-fee transactions.
The censored transaction pool's inclusion rate tracked the non-censoring builder share — when non-censoring builders had a higher slot share, inclusion was faster; when they had a lower share, inclusion was slower.

The censorship is structural, not incidental: it persists because the PBS architecture concentrates block-construction power in a small number of builders, and when those builders apply content-based filtering, the filtered transaction class experiences systematic exclusion.

Timeline (UTC)

When	Event	OAK ref
2022-08	OFAC adds Tornado Cash to the SDN list; major builders (Flashbots Builder) begin filtering Tornado Cash-linked transactions	T14.005 (censor trigger)
2022-09	Ethereum transitions to PoS (the Merge); MEV-Boost / PBS architecture becomes the dominant block-production pipeline; builder concentration emerges	T14.005 surface embedded in architecture
2022-10 – 2023	OFAC-compliant builder share fluctuates; non-censoring builders (BeaverBuild, Titan, Rsync) gain share; censorship.pics and mevwatch.info launch to track builder/relay censorship rates	T14.005 surface measured
2023	Wahrstatter et al. publish empirical measurement of Ethereum transaction censorship under OFAC-compliance builder policies; document median 2-3x inclusion delay for censored transactions	T14.005 quantified
2023–2025	OFAC-compliant builder share stabilises around 30-40%; non-censoring builder share provides a censorship-resistance floor; transactions are delayed but not permanently excluded	T14.005 surface persistent
2024–2025	Ethereum protocol-layer mitigation research: inclusion lists (EIP-7547), encrypted mempools, ePBS developments — all targeting the structural T14.005 surface at the protocol layer	T14.005 mitigation pipeline
2025	Inclusion lists remain pre-deployment; builder censorship persists as a structural surface; the non-censoring builder share is the operational censorship-resistance metric	T14.005 surface ongoing

What defenders observed

The builder-concentration dynamic is the load-bearing structural feature. A small number of builders (Flashbots Builder, BeaverBuild, Titan, Rsync) construct the majority of Ethereum blocks. When one of these builders applies content-based filtering, the censored transaction class's inclusion probability is reduced by that builder's slot share. The builder-concentration metric (top-1, top-3, top-5 builder share) is the structural T14.005 signal — a builder above a configurable concentration threshold has the capacity to censor at economically meaningful scale.
The censorship is measurable at the per-transaction level. By comparing a transaction's mempool observation time against its on-chain inclusion time (accounting for the transaction's priority fee and the slot's builder identity), researchers can identify transactions that were excluded from specific builders' blocks despite paying competitive fees. The per-transaction inclusion-delay metric, stratified by builder, is the load-bearing T14.005 forensic artefact.
The non-censoring builder share is the operational censorship-resistance metric. As long as at least one major builder does not censor, censored transactions are delayed rather than permanently excluded. The non-censoring builder share determines the expected inclusion delay for censored transactions. When non-censoring builders held >60% slot share, inclusion delays were 1-2 blocks; when they held <40%, delays were 3-6+ blocks. The non-censoring builder share is the metric that defenders (and users of censored protocols) should monitor.
Profit-driven T14.005 and compliance-driven T14.005 share the same infrastructure layer. The builder's motivation differs (profit maximisation vs. regulatory compliance), but the mechanism (builder excludes transactions at the block-content selection layer) and the outcome (transactions are delayed or excluded from blocks) are identical at the infrastructure layer. A defender monitoring for T14.005 builder censorship should detect both sub-patterns using the same per-builder transaction-inclusion audit methodology — the motivation is not observable at the block-content layer, only the exclusion pattern.
Protocol-layer mitigation (inclusion lists) is the structural solution. Inclusion lists (EIP-7547) require the proposer (validator) to specify a list of transactions that must be included in the block, constraining the builder's ability to censor. If a builder's block excludes a transaction that is in the inclusion list, the block is invalid. Inclusion lists move the censorship-resistance guarantee from the builder layer (where it depends on the non-censoring builder share) to the protocol layer (where it is enforced by consensus). Encrypted mempools are a complementary mitigation: if the builder cannot observe transaction content before inclusion, it cannot censor based on content (though it can still censor based on submitter address).

What this example tells contributors writing future Technique pages

T14.005 is a PBS-architecture structural surface, not an operator-malfeasance class. The OFAC-compliance builder censorship case demonstrates that T14.005 is not about "bad builders" — it is about a protocol architecture that gives builders content-level control over blocks without protocol-level constraints on that control. The builders applying OFAC-compliance filtering are acting within their legal obligations; the structural vulnerability is that the PBS architecture permits content-based filtering at all. Future T14.005 contributions should preserve the distinction between the structural surface (builder has unfettered block-content selection power) and the operator motivation (profit-driven exclusion vs. compliance-driven exclusion).
The OFAC-compliance case is the most extensively measured T14.005 instance. The Wahrstatter et al. (2023) empirical measurement provides per-builder inclusion-rate data, per-transaction inclusion-delay distributions, and builder-concentration metrics — the quantitative foundation that future T14.005 detection tooling should build on. The OFAC-compliance case is the calibration anchor for T14.005 detection: the methodology that detected compliance-driven censorship (per-builder inclusion audit, per-transaction inclusion-delay monitoring) applies identically to profit-driven censorship.
The non-censoring builder share is the operational metric that users and protocols should monitor. Protocols whose transactions are likely to be censored by OFAC-compliant builders (privacy-protocol interactions, mixer-adjacent transactions, sanctioned-address interactions) should price the inclusion-delay into their user-facing UX and should monitor the non-censoring builder share as a forward-looking indicator of expected confirmation times.
The distinction between delay and permanent exclusion is operationally critical. The OFAC-compliance censorship case produces delay, not permanent exclusion, because non-censoring builders exist and eventually include the censored transactions. A builder landscape where all major builders censor (100% OFAC-compliant builder share) would produce permanent exclusion — transactions would be stuck in the mempool indefinitely. The distinction matters for defender risk assessment: a protocol whose transactions are delayed by 3-6 blocks faces a UX cost (longer confirmation times); a protocol whose transactions are permanently excluded faces an existential cost (the protocol is unusable on Ethereum). The non-censoring builder share is the metric that distinguishes these two regimes.

Public references

[wahrstatter2023censorship] — Wahrstatter et al., empirical measurement of Ethereum transaction censorship under OFAC-compliance builder policies (2023); canonical quantitative T14.005 anchor.
[daian2019flashboys] — Daian et al., "Flash Boys 2.0" (2019): foundational MEV characterisation including the builder/proposer/relay architecture.
censorship.pics and mevwatch.info — community-run builder-censorship dashboards measuring OFAC-compliance inclusion rates per builder and per relay.
EIP-7547 (inclusion lists) — Ethereum protocol-layer mitigation targeting the structural T14.005 surface.
Flashbots / MEV-Boost ecosystem documentation — PBS architecture specification, builder-censorship design consideration, and relay-transparency mechanisms.
[zhou2023sok] — academic taxonomy covering MEV extraction, PBS architecture, and builder-level manipulation surfaces.

Discussion

The OFAC-compliance Tornado Cash builder censorship case is OAK's canonical quantitative anchor for T14.005. It is the most extensively measured and publicly documented instance of builder-level censorship, providing per-builder inclusion-rate data, per-transaction inclusion-delay distributions, and builder-concentration metrics that establish the quantitative baseline for the class.

The case demonstrates that T14.005 is a structural property of the PBS architecture, not an operator-malfeasance class. The builders applying OFAC-compliance filtering are complying with legal obligations (U.S. sanctions regulations); the structural vulnerability is that the PBS architecture gives builders unfettered content-level control over blocks without protocol-level constraints. The same infrastructure (builder block-content selection) that enables compliance-driven censorship also enables profit-driven censorship (excluding rival searchers' transactions, protecting allied searchers' sandwiches). Protocol-layer mitigations (inclusion lists, encrypted mempools) address both motivation classes by constraining the builder's content-selection power at the protocol layer.

The structural lesson for defenders is: monitor per-builder transaction-inclusion patterns as a first-class security metric. The per-builder inclusion audit that detects OFAC-compliance censorship (comparing a builder's included-transaction set against the global mempool at comparable fee levels) is the same methodology that would detect profit-driven censorship (a builder that consistently excludes transactions from specific searcher addresses while including others at the same fee level). Builder-concentration metrics, per-transaction inclusion-delay distributions, and builder-allied-searcher correlation analysis are the load-bearing T14.005 detection primitives, irrespective of the builder's motivation.

For OAK's broader coverage, the OFAC-compliance builder censorship case provides the quantitative dimension to T14.005 that the existing examples/2025-01-mev-boost-relay-censorship.md provides at the relay-censorship (T14.002) layer. The two cases together establish the full PBS censorship surface: builder-level (T14.005, the block-content selection layer) and relay-level (T14.002, the block-delivery layer). Defenders evaluating PBS-related censorship risk should assess both layers independently — a non-censoring builder delivering through a censoring relay still produces censorship; a non-censoring relay delivering from a censoring builder also produces censorship. Only the combination of non-censoring builder + non-censoring relay + non-censoring proposer guarantees censorship-free block production.