Accountable Transaction Inclusion Lists: Enhancing Ethereum’s Censorship Resistance Patrick Spiesberger # Karlsruhe Institute of Technology, Germany
Hannes Hartenstein # Karlsruhe Institute of Technology, Germany
arXiv:2607.22040v1 [cs.DC] 24 Jul 2026
Abstract In Ethereum, transaction inclusion is rarely in question; what matters is the delay until inclusion. Currently, block builders could exercise censorship across consecutive blocks, threatening time-critical applications, such as on-chain auctions. To mitigate this risk, existing proposals such as FOCIL, scheduled for deployment in late 2026, assign a committee to list transactions for mandatory inclusion. However, no committee member is held accountable for the actual inclusion of the transactions: an adversary can bribe the entire committee to omit any transaction for less than 2 e per block under current conditions. We argue that accountability, i.e., requiring all exclusion decisions to be publicly disclosed and verifiably complete, with violations attributable to a specific party, substantially raises censorship costs. To this end, we propose Fair Forward Inclusion Lists (FairFIL) as an accountable censorship resistance mechanism for Ethereum. In FairFIL, every builder must publish all transactions the builder chooses to censor, subject to a protocol-anchored policy; a committee verifies the completeness and validity of this disclosure. The subsequent builder must include these transactions, forfeiting the full block reward upon any omission. Therefore, under FairFIL, extending censorship beyond a single slot requires an assembler to forfeit a full block reward. We show that compliance is rational for all participants within our behavior model. Our empirical evaluation on Ethereum mainnet indicates that multi-block censorship costs one order of magnitude more than under existing proposals, while leaving the builder’s MEV extraction freedom largely intact. Initial measurements further suggest that the mempool consistency FairFIL requires is met in practice. 2012 ACM Subject Classification Computer systems organization → Reliability Keywords and phrases Ethereum, Blockchain, Censorship Resistance, Inclusion Lists, Fairness Acknowledgements This work was funded by the KASTEL Security Research Labs.
1
Introduction
Ethereum [6], as of mid 2026, is the largest general-purpose smart-contract platform by market capitalization, hosting a wide range of applications that depend on transaction inclusion with low and predictable latency. Ethereum operates on a time-slotted model [12]: in each 12 s slot, a single leader (in Ethereum terminology the proposer) is selected at random to assemble a block, while the remaining participants (validators) attest to its validity. During the slot, the proposer has short-lived but unilateral control over which transactions are included in the block and in what order [20, 29]. Correspondingly, any transaction can be excluded at will by the proposer. For some transactions, inclusion within a handful of slots is sufficient. However, a broad class of transactions is time-critical: each additional slot of inclusion latency can diminish the value delivered to the user or application, or more broadly undermine Ethereum’s attractiveness as a reliable platform. Examples include auctions, decentralized finance, and commit-and-reveal protocols. In auctions, a bid submitted shortly before the auction closes may be suppressed after the deadline [18, 39]. In decentralized finance, a stop-loss transaction submitted when a trigger price is reached can be censored; each additional delay allows the asset price to move further against the user’s intent [9, 26].
2
Accountable Transaction Inclusion Lists
In commit-and-reveal schemes, a reveal transaction must be submitted within a bounded window after committing; if censored, the protocol cannot distinguish the outcome from an intentional non-reveal, and the participant may be penalized despite having acted in time. For such applications, the essential question is not whether a transaction will eventually be included in the blockchain, but how quickly the transaction affects the application. We follow the established usage in the Ethereum literature [7, 37] and use the term “censorship” for additional inclusion latency – the exclusion of a transaction from one or more consecutive blocks – rather than for permanent exclusion from the blockchain [18]. As long as control over inclusion decisions rotates frequently among independent parties, no single party can delay a transaction beyond a limited timeframe. Concerns arise when one party controls block construction over extended periods, a scenario facilitated by Ethereum’s Proposer–Builder Separation (PBS) [22, 10]. Under PBS, proposers delegate block construction to specialized builders to capture Maximal Extractable Value (MEV), i.e., the additional revenue obtained by strategically including, excluding, or reordering transactions within or across blocks [20]. Empirical evidence shows that two builders assembled more than 80 % of all blocks in 2024 and 2025 [40, 2], and nearly all proposers rely on them [32]. A dominant builder could, in principle, impose censorship over many consecutive slots, thereby undermining the reliability of the network. Our measurements, as described below, underline the relevance in practice: in September 2025, an average of 8.3 transactions per block were censored despite being eligible for inclusion under the intended tip-based reference ordering [8]. To mitigate transaction censorship, prior work proposes mechanisms that distribute inclusion control across a committee of κ participants per slot [27, 34, 36, 19]. The common idea is to split one party’s exclusive control into shares across κ parties, such that a single honest member suffices to force the inclusion of a transaction. However, as we show later, an adversary can bribe the entire committee of any of these mechanisms at a cost of only a few euros per slot under current conditions. We attribute this low cost of censorship to the fact that no individual committee member is held accountable: no member’s exclusions are publicly attributable, verifiable, or subject to protocol-enforced penalties. In this paper, we therefore address the following research question: Research question. Does accountability for exclusion decisions substantially increase the cost of censoring a transaction? Contribution and Rationale. The idea of accountability in censorship-resistance mechanisms and an initial sketch of FairFIL were first introduced in [33]. This paper builds on that foundation and makes three main contributions. First, we formalize accountability for censorship resistance in Ethereum. We prove that accountability can substantially increase the cost of sustained censorship: under accountable inclusion enforcement, a censoring builder forfeits the entire block reward, increasing censorship costs by roughly one order of magnitude compared to prior approaches. Second, we present Fair Forward Inclusion Lists (FairFIL), an accountable censorship resistance mechanism, and prove that under a fully rational participant model, FairFIL enforces block invalidation under sustained censorship. Third, we implement FairFIL and empirically evaluate the mechanism on Ethereum mainnet, quantify the cost of censorship and provide first evidence for practical deployability. FairFIL is designed to be explicitly MEV-friendly, preserving most of the builders’ flexibility for MEV extraction. Two considerations motivate this choice of an “MEV-friendly design”. First, MEV constitutes a substantial share of proposer revenue [21]. Curtailing MEV-extraction freedom risks undermining Ethereum’s long-term viability. Though difficult to quantify, we regard this risk as significant, as does prior work [5]. Second, over 90 % of validators [22, 32]
P. Spiesberger and H. Hartenstein
voluntarily adopted MEV-Boost [15], despite censorship and centralization risks [22, 40], demonstrating that validators will deviate from protocol intentions when compliance reduces revenue. FairFIL trades only a small share of the block assembler’s MEV-extraction freedom in exchange for inclusion guarantees: any transaction may be censored for one slot but must be included thereafter, keeping assembler constraints low while guaranteeing timely inclusion for the transaction sender. Paper structure. Section 2 introduces the system model, defines transaction censorship, and states the participant and adversary model. Section 3 surveys prior censorship resistance mechanisms and identifies the absence of accountability as their main limitation. Section 4 presents the FairFIL protocol. Section 5 empirically evaluates FairFIL on Ethereum mainnet, formalizes accountability as four properties satisfied by FairFIL, and quantifies the per-slot cost of sustained censorship compared to prior mechanisms. Section 6 discusses assumptions and deployment considerations regarding MEV; Section 7 concludes.
2
Foundations and Design Space
2.1
System Model and Transaction Censorship
We consider an abstracted Ethereum model in which the blockchain is extended in discrete time slots. For each slot s, a committee Vs ⊂ V of validators is pseudo-randomly selected from the active validator set V , while a single proposer vsP ∈ Vs is responsible for assembling the block at the beginning of slot s [12]. We refer to the party that actually constructs the block – whether the proposer itself or a delegated builder under PBS [10] – as the block assembler βs . Table 3 summarizes the symbols and abbreviations used throughout this paper. Transactions. A transaction τ is a signed user statement [12] specifying an intent and an execution cost gas(τ ) determined upon execution. For every unit of gas consumed, the user τ pays a voluntary per-gas tip ftip, gas – intended to incentivize faster inclusion – to the block τ assembler βs , and a mandatory per-gas base fee fbase, gas that is received by no party [8]. Accordingly, the total per-transaction tip paid to block assembler βs for including τ is τ τ τ τ ftip, tx := ftip, gas · gas(τ ), and the total per-transaction base fee is fbase, tx := fbase, gas · gas(τ ). Mempool. Transactions are disseminated through Ethereum’s peer-to-peer (P2P) layer and stored, at each node, in a local buffer called the mempool. We write Poolns for the mempool view of a node n at slot s; in particular, Poolβs s is the block assembler’s view. For the theoretical analysis, we assume all validators share an identical mempool view, consistent with prior analyses of censorship resistance mechanism designs [36]. In practice, mempools are not perfectly consistent; we revisit this assumption empirically in Section 5.2 and find that the near-perfect consistency observed appears to be sufficient for FairFIL operation. Block construction and validity. At the beginning of slot s, the block assembler selects a set of transactions from Poolβs s , possibly augmented with transactions received via a private communication channel (Exclusive Order Flow, XOF) [20]. Subsequently, the assembler orders and executes these transactions and publishes the resulting block Bs . A block is protocol-valid if the execution on top of the state induced by block Bs−1 respects Ethereum’s execution rules [38]; in particular, the cumulative gas consumed by Bs must not exceed the per-slot gas limit gmax (Bs ). A block is accepted once a majority of Vs attests to its validity; due to Ethereum’s proposer boost, slightly less than a majority suffices in practice [30].
3
4
Accountable Transaction Inclusion Lists
Transaction Censorship. In this work, we restrict the notion of censorship to a specific operational instance: the exclusion of a transaction from the block currently being assembled. Censorship in this sense denotes additional inclusion latency, not permanent exclusion from the blockchain. We neither consider self-censorship (users refraining from submitting transactions) nor censorship at Ethereum’s P2P layer. To decide which transactions should have been included, we adopt a deterministic reference ordering. Transactions in the mempool τ Poolβs s are sorted in descending order of their per-gas tip ftip, gas , with the transaction hash as a tie-breaker. Iterating through this sequence, we admit every transaction whose execution preserves block validity; we call the resulting sequence the Fair Ordering 1 of the mempool. ▶ Definition 1 (Transaction censorship). A transaction τ is censored from block Bs if τ was propagated before the start of slot s via Ethereum’s P2P layer and its inclusion in Bs under the Fair Ordering would preserve block validity, yet transaction τ is excluded from block Bs . The condition “propagated before the start of slot s” is not precisely observable in a decentralized system. In practice, we operationalize this condition as the initial propagation at least 3 s before the start of the slot to account for network propagation delays. Table 1 illustrates Definition 1 on a mempool Poolβs s = {τ1 , . . . , τ5 }, augmented with a privately submitted transaction τprivate , against a block gas limit of gmax = 100 gas. The candidate sequence obtained by sorting Pools by per-gas tip in descending order is [τ1 , τ2 , τ3 , τ4 , τ5 ]. Iterating through this sequence and admitting each transaction whose execution still fits into gmax yields the Fair Ordering [τ1 , τ2 , τ4 , τ5 ] with cumulative gas 50. Transaction τ3 is dropped because including {τ1 , τ2 , τ3 } would exceed gmax . By Definition 1, any transaction in the Fair Ordering not included in Bs is censored. In our example, this applies to τ2 , as well as to τ4 , which is displaced by the privately submitted τprivate . τ τ5 τ2 τ3 τprivate τ4 τ1
τ Tip ftip, gas 2 8 7 20 5 10
gas(τ ) 10 10 90 70 10 20
Includable? Yes Yes No Yes Yes Yes
∈ Bs ? ✓ × × ✓ × ✓
Censored? No Yes No – Yes No
Table 1 Set of transactions available to the current block assembler for block construction (gmax = 100), resulting in block Bs = [τ5 , τprivate , τ1 ]. While this selection may appear arbitrary, it reflects the assembler’s MEV extraction strategy, which encompasses both the censorship of transactions and the inclusion of private transactions, with the objective of maximizing revenue.
We further classify censored transactions by how long their inclusion is delayed. ▶ Definition 2 (n-slot censorship). Let s be the earliest slot in which transaction τ is includable. For n ∈ N+ , τ experiences n-slot censorship if it is censored from blocks Bs , . . . , Bs+n−1 and included in block Bs+n . The case n = 0 corresponds to the absence of censorship for τ .
2.2
Behavior Model and Censorship Resistance Mechanisms
We apply the Byzantine, Altruistic, Rational (BAR) model by Aiyer et al. [1] to characterize validator and block assembler behavior, following prior work such as [32]. An altruistic 1
This use of “fair” differs from receive-time-based notions of order fairness such as the Aequitas family [24].
P. Spiesberger and H. Hartenstein
participant follows the protocol’s intent regardless of payoff. We assume their absence, as protocols should be robust even in the worst plausible case, and revisit this assumption in Section 6.2. In what follows, all validators and block assemblers are modeled as rational participants: a rational participant deviates from the protocol whenever deviation yields a strictly higher personal payoff than compliance, and may cooperate with other rational participants. Such a deviation need not violate the protocol; it may instead exploit degrees of freedom the protocol permits, contrary to its intent. We treat censorship as a deviation from the Ethereum protocol [25] and later extend this to deviations from censorship-resistance protocols. When compliance and deviation yield identical payoffs, we assume compliance: deviating offers no financial gain, while ‘unfair’ behavior could undermine Ethereum’s longterm viability and thereby reduce future validator revenue. However, we assume that any strictly positive revenue gain suffices to induce deviation. Adversary A is not profit-driven and aims to censor transactions: A can communicate directly with all participants [36] and may bribe rational participants to deviate, subject to a per-slot bribing budget M. All bribes are paid on-chain via a bribing smart contract [31]; out-of-band payments (e.g., bank transfers) are outside our model. Each bribe therefore incurs a fixed overhead cbribe for adversary A, covering fund transfer and on-chain verification – in addition to the bribe amount itself. Budget restriction. In Ethereum, censorship resistance is fundamentally an economic property [18]. As long as block assemblers may choose to withhold a block, any sufficiently wealthy adversary can censor transactions by compensating the block assembler βs for the forgone block reward R(Bs ), defined as the sum of transaction tips and extracted MEV. Providing censorship resistance against arbitrarily wealthy adversaries would require substantial structural changes to Ethereum and lies outside the scope of this paper. Accordingly, we assume that an adversary cannot bribe a block assembler to an extent that prevents the publication of a block. Under this assumption, the adversary’s per-slot budget is bounded by the block reward R(Bs ), since any larger budget would enable the adversary to prevent block publication in every slot, thereby violating Ethereum’s liveness property and halting chain progression. We further assume that the adversary cannot bribe the slot committee Vs to accept an invalid block or reject a protocol-valid one. Such attacks would require bribing a majority of the committee, which comprises approximately 30 000 validators in 2025 [23]. We argue that the required budget significantly exceeds the block reward R(Bs ). Based on this adversary model, we define censorship resistance as follows: ▶ Definition 3 ((M, σ)-censorship resistance). A protocol is (M, σ)-censorship-resistant if, for any transaction τ , an adversary with per-slot budget M cannot prevent τ from being included for more than σ consecutive slots under rational behavior of all other participants. We write Cτ = [Cτs , Cτs+1 , . . . ] for the per-slot cost sequence incurred by A to censor τ , where each entry Cτs+i denotes the cost in the respective slot s + i. The summation of costs up to the n-th element therefore corresponds to the cost of n-slot censorship of τ . Ethereum baseline. We establish the censorship resistance of plain Ethereum as of early τ 2026. Informally, outbidding transaction τ ’s per-transaction tip ftip, tx by any ϵ > 0 makes accepting the bribe more profitable than including τ , thereby censoring τ for one slot; the attack can be repeated in each slot. This yields Lemma 4; the proof is given in Appendix C.
5
6
Accountable Transaction Inclusion Lists
τ ▶ Lemma 4 (Ethereum baseline). Ethereum is ftip, tx + cbribe , 0 -censorship-resistant. The τ per-slot cost of excluding transaction τ is CτEth := ftip, tx + cbribe + ϵ for each slot, with ϵ > 0. In absolute terms, a budget of 0.10 e per slot is sufficient to censor the median transaction, where transactions are ranked by total tips, observed between September and December 2025. The required budget is predominantly driven by the bribe overhead cbribe . While the per-slot cost of censorship is financially bounded by the block reward, the objective of a censorship resistance mechanism is to maximize the cost an adversary must incur to censor a target transaction. We consider inclusion list mechanisms that achieve this by designating a set of required transactions Treq whose inclusion is protocol-enforced. Accordingly, we regard the transaction set Treq as an obligation imposed on a specified party. ▶ Definition 5 (Inclusion List-Based Censorship Resistance Mechanism, IL-CR). An inclusion list-based censorship resistance mechanism Πn designates, for each slot s, a set Treq of transactions and requires that every transaction in Treq is included no later than block Bs+n . Such a mechanism is called accountable if the construction of Treq and its enforcement are publicly verifiable, so that any deviation can be detected and penalized. We distinguish two classes of IL-CR mechanisms: a constructing mechanism assigns construction of Treq to a committee without content constraints, and is therefore non-accountable. In contrast, a verifying mechanism defines a protocol-anchored construction policy against which a committee verifies compliance – any deviation is detectable, regardless of who performed the construction. A verifying mechanism is accountable if every policy violation can be attributed to a specific party and the protocol specifies a corresponding consequence. The significance of this distinction follows from the rationality model. In constructing mechanisms, each committee member independently contributes a partial list – a subset of transactions selected at the member’s discretion – from which Treq is assembled as the aggregate. No member faces any penalty for omitting transaction τ from their partial list; any bribe exceeding the per-transaction tip therefore suffices to induce omission. Further, without a policy constraint, members may insert privately negotiated transactions, which can displace legitimate mempool transactions, enable advanced MEV strategies, and undermine external verifiability. Under the rationality assumption, this is the predicted outcome in practice: an outsourcing of Treq construction to specialized builders, analogous to PBS, thus becomes plausible. In verifying mechanisms with accountability, by contrast, any deviation exposes the constructing party to a financial penalty independent of transaction fees – such as forfeiting the full block reward R(Bs ) – making omission far more costly than any per-transaction tip. We demonstrate in this paper that FairFIL, as an accountable verifying mechanism, raises the per-slot cost of sustained censorship by roughly one order of magnitude relative to the constructing mechanisms surveyed in the following Section 3.
3
Related Work
We consider four prior censorship resistance mechanism proposals: FIL [27], FOCIL [34], MCP [19], and AUCIL [36], where FIL, FOCIL, and AUCIL are inclusion list-based censorship resistance mechanisms. We further classify MCP as an IL-CR mechanism despite structural differences, which we discuss in detail below. The FIL approach represents the most basic instance of an IL-CR mechanism, where Treq is constructed by a single party (κ = 1). In contrast, the other mechanisms distribute the construction of Treq across a committee of size κ > 1 per slot. For each mechanism, we describe the design and derive the resulting
P. Spiesberger and H. Hartenstein
per-slot censorship cost, as detailed in Appendix F. To the best of our knowledge, no existing mechanism provides accountability for transaction exclusion. Forward Inclusion Lists (FIL) [27] (Neuder et al.) is a Π1 mechanism that enforces transaction inclusion in a forward manner: the inclusion list (Treq ) is constructed by the current block assembler and published alongside block Bs , while binding obligations apply to the subsequent block assembler βs+1 , who must include all listed transactions in block Bs+1 . Since FIL does not constrain the construction of Treq , the assembler of Bs retains full freedom over its contents, and omissions are not verifiable. Tsao et al. [35] introduce a first step towards accountability by adding a validity check that ensures listed transactions are includable in the next block, but the construction of obligation Treq remains unconstrained. Since the block assembler receives no reward tied to any specific transaction in Treq , bribing the assembler to omit a transaction from the list incurs only a negligible additional cost. The dominant censorship cost is that of excluding transaction τ from both block Bs and Bs+1 (see Lemma 4). A tighter characterization of per-slot censorship costs under FIL is provided in Appendix F.1. FairFIL strengthens FIL’s design by introducing accountability through a protocol-defined and verifiable construction of Treq , while leveraging the block reward as an intrinsic enforcement mechanism. Fork-Choice Enforced Inclusion Lists (FOCIL) [34] (Thiery et al.), scheduled for deployment on Ethereum in 2026 [13], distributes the construction of Treq across a committee of κ = 16 validators per slot. Each committee member independently selects transactions from its local mempool view and broadcasts a partial inclusion list during slot s. The block assembler βs+1 is required to include all transactions appearing in any partial list, subject to block validity and capacity constraints. In contrast to FIL, transactions propagated within slot s (in particular up to three seconds before the start of slot s+1) are subject to an inclusion obligation for block assembler βs+1 , which classifies FOCIL as a Π0 mechanism. FOCIL relies on a one-of-κ-honest assumption: a single honest committee member suffices to enforce inclusion of a transaction τ in Treq , implying that an adversary must compromise all κ members to censor τ . However, as in FIL, committee members receive no reward for specific transactions they include; any positive bribe is therefore sufficient to induce omission from an individual member’s partial list. Consequently, censorship resistance scales with committee size but remains vulnerable in a purely rational setting. We show in Appendix F.2 that the resulting per-slot bribery cost across the entire committee is below 2 e for a median-tip transaction in late 2025 under current Ethereum conditions (see Section 5.4). Multiple Concurrent Proposers (MCP) [19] (Garimidi et al.) departs from the inclusionlist paradigm of FIL and FOCIL by introducing κ concurrent block assemblers (we assume κ = 16), each constructing an independent partial block. These κ partial blocks are concatenated into a single block (Π0 ), forming an obligation Treq , without the possibility for a single party to include additional transactions afterwards. As in FOCIL, a transaction is included in Treq if at least one proposer includes it in its partial block, again relying on a one-of-κ-honest assumption. In contrast to FIL and FOCIL, proposers receive direct rewards for transactions included in their partial blocks that are ultimately incorporated τ into the aggregated block. Each proposer retains at most the per-transaction tip ftip, tx for transactions in its own partial block, not considering MEV extraction. Consequently, omitting a transaction τ induces an opportunity cost equal to the forgone tip. As a result, the required per-member bribe increases by approximately the transaction tip relative to FOCIL, which is around 0.01 e at the median-tip transaction in late 2025, and is therefore only marginally higher than in FOCIL.
7
Accountable Transaction Inclusion Lists
Auction-Based Inclusion Lists (AUCIL) [36] (Wadhwa et al.) is a Π0 mechanism that combines committee-based construction with an explicit auction for aggregating partial inclusion lists. In the first phase, a committee of size κ = 32 constructs partial input lists. Each committee member is assigned a subset of transactions via a shared allocation mechanism, such that honest inclusion of the assigned transactions forms a correlated equilibrium. While inclusion of the assigned transactions is a rational strategy given transaction tips, compliance is not verified. In the second phase, each committee member aggregates the received partial lists and submits a bid proportional to the number of included lists, inducing competition over the final Treq . The block proposer is required to select the aggregate with the highest bid and include the corresponding transaction set in its block. This design incentivizes inclusion of committee contributions, since omitting lists reduces bid strength and thus expected reward. Nevertheless, AUCIL does not provide enforceable accountability for transaction exclusion. Appendix F.4 shows that even under this mechanism, which we consider the most effective among mechanisms based solely on transaction fees, a transaction can be censored at an expected cost of approximately 3.30 e per slot under current Ethereum conditions. Comparison. All four mechanisms share the same structural limitation: the absence of accountability in transaction selection keeps the per-slot cost of censorship low, with costs primarily determined by transaction tips and committee size. We summarize censorship costs over one block, two blocks, and ten blocks (two minutes) for each mechanism in Table 2. By enabling verifiability of transaction censorship and attribution of censorship to a specific party, misbehavior can be penalized, for instance through block invalidation and the associated loss of revenue. With FairFIL, we present a mechanism for detecting transaction censorship, attributing it to a single party, and enabling penalization. This approach leads, as indicated in Table 2, to significantly higher costs for sustained censorship in practice. Mechanism
Committee
Baseline Prior Work FIL [27] FOCIL [34] MCP [19] AUCIL∗ [36] FairFIL Suppression
— (constructing) 1 16 16 32 (verifying) ≈ 30 000
Attack
8
Invalidation
∗∗
≈ 30 000
Censorship Costs (cumulated) 1 slot 2 slots 10 slots ≈ 0.10 e ≈ 0.20 e ≈1e
Proof
≈ 0.11 e ≤ 1.54 e ≤ 1.60 e ≤ 3.30 e
≈ 0.22 e ≤ 3.08 e ≤ 3.20 e ≤ 6.60 e
≈ 1.10 e ≤ 15.40 e ≤ 16 e ≤ 33 e
App. F.1 App. F.2 App. F.3 App. F.4
≈ 0.10 e
≈ 50.34 e
≈ 402 e
Sec. 5.3
≈ 0.10 e
≈ 28.30 e
≈ 141 e
Sec. 5.3
App. C
Table 2 Costs of censoring a median-tip transaction under the mechanisms proposed and surveyed in this paper. All values are based on empirical measurements from Sep. to Dec. 2025 (Section 5.4). Suppression and invalidation are the two ways in which censorship in FairFIL remains feasible at the stated cost; we describe both in detail in Section 5.3. ∗ For AUCIL, Wadhwa et al. [36] provide a tighter bound; in practice, bribes may be cheaper. ∗∗ Invalidating a block can be significantly more expensive due to MEV extraction.
4
Fair Forward Inclusion Lists
We present FairFIL, an accountable Π1 censorship resistance mechanism. Block assembler βs retains full authority over the construction of block Bs and MEV extraction, but must publish every excluded transaction in a list FairFILs alongside the block. A committee of validators
P. Spiesberger and H. Hartenstein
verifies that FairFILs is complete with respect to their mempool view; if a majority finds a discrepancy, block Bs is rejected and the assembler forfeits the full block reward R(Bs ). The subsequent assembler βs+1 must include every transaction listed in FairFILs in block Bs+1 ; any omission forfeits block reward R(Bs+1 ). We first describe how βs constructs FairFILs , then how validators verify its correctness and enforcement. Informally, FairFILs is correct if it contains exactly those transactions censored from Bs that remain includable in Bs+1 . We formalize and prove these requirements via four accountability properties in Section 5.3.
4.1
FairFIL Construction
Algorithm 1 details how block assembler βs produces block Bs and FairFILs . At a high level, βs performs two tasks: fulfilling the inclusion obligation from FairFILs−1 , and publishing a complete disclosure of all transactions excluded from block Bs . Enforcing FairFIL (lines 1–3). FairFILs−1 is a hard constraint on block Bs : every listed transaction must appear in Bs . Block assembler βs integrates the sequence into the blockconstruction strategy (line 1); lines 2–3 verify that this constraint is satisfied. Any violation causes Bs to be rejected (see Section 4.2), forfeiting the full block reward R(Bs ). Constructing FairFIL (lines 4–24). The central challenge is to construct an inclusion list FairFILs that is complete (covering every censored transaction), executable (each listed transaction must remain valid against the post-state of block Bs ), and verifiable (validators must be able to independently reconstruct the same transaction set to check for undisclosed exclusions). Such an inclusion list is constructed in four steps. First, block assembler βs considers all mempool transactions seen before the start of slot s (line 4).2 Second, these transactions are sorted according to Fair Ordering (line 5), using the per-gas tip as primary key and the transaction hash as tie-breaker. Third, non-censored transactions – those already contained in Bs as well as those not includable in Bs under Fair Ordering – are discarded (lines 9–17). Fourth, to ensure that the resulting list remains executable for the subsequent block assembler, the censored transactions are executed on the post-Bs state (lines 18–24). Each transaction is applied in order, with the state updated after each successful execution. Since block assembler βs assembles block Bs , the post-Bs state is available at construction time (line 1). Any transaction whose execution would violate protocol validity is discarded.
4.2
FairFIL Verification
We use the validator set Vs of slot s as the committee responsible for verifying FairFILs . Algorithm 2 refines the verification procedure performed by a validator v ′ ∈ Vs . A validator casts a negative vote for block Bs if any of the following checks fails. Block acceptance requires a majority of validator votes. Check 1: Enforcement of FairFILs−1 (lines 1–3). Every transaction from FairFILs−1 must appear in block Bs . Since the committee of slot s−1 verified includability (Check 2), any missing transaction is unambiguous evidence of non-compliance by block assembler βs . 2
Without a cutoff, βs would need to emulate every transaction in the mempool, including those persisting for months (e.g., spam or long-pending underpriced transactions). The specified 603 s window – fifty slots (600 s) plus a 3 s propagation margin (Section 5.2) – limits this to a manageable recent window.
9
10
Accountable Transaction Inclusion Lists
Algorithm 1 Construction of block Bs and FairFILs by block assembler βs .
Input: Previous block Bs−1 , previous FairFILs−1 , local mempool Poolβs s Output: Block Bs , FairFILs /* Block construction with FairFILs−1 forced in (lines 2–3). /* Note: Assembler βs is not required to follow the ordering of FairFILs−1 . β 1 Bs ← assembleBlock (optional: Pools s ∪ XOF, mandatory: FairFILs−1 ) 2 foreach τ ∈ FairFILs−1 do 3 assert(τ ∈ Bs )
*/ */
/* Construct a transaction set according to Fair Ordering. */ βs 4 FairOrdering ← {τ ∈ Pools | first_seen(τ ) ≥ SLOT_START − 603 s} τ 5 FairOrdering ← sort(FairOrdering, prim: ftip, gas , sec: tx hash, order: desc.) 6 Censored ← [ ] 7 state ← state(Bs−1 || FairFILs−1 ) // appending FairFILs−1 on state of Bs−1 . 8 GasUsed ← gas(FairFILs−1 ) 9 foreach τ ∈ FairOrdering do 10 if GasUsed + 21000 > gmax (Bs ) then 11 break // Minimum gas consumption is 21000 gas [38]; no further transaction fits. 12 13 14 15 16 17
state ′ ← execute(τ on state) if state ′ is valid then state ← state ′ GasUsed ← GasUsed + gas(τ ) if τ ∈ / Bs then append τ to Censored
/* Determine FairFILs by verifying includability in block Bs+1 . FairFILs ← [ ] 19 state ← state(Bs ) 20 foreach τ ∈ Censored do 21 state ′ ← execute(τ on state) 22 if state ′ is valid then 23 state ← state ′ 24 append τ to FairFILs
*/
18
25
return Bs , FairFILs
Check 2: Includability of FairFILs (lines 4–8). FairFILs must comply with Fair Ordering: transactions are sorted in descending per-gas tip order (hash as tie-breaker), and executing them sequentially on the state induced by block Bs must preserve protocol validity of block Bs+1 . The validator emulates this execution and rejects Bs if the resulting state is invalid. A fixed ordering is essential: otherwise, βs could reorder preceding transactions to manipulate the state such that a censored target appears non-includable – a claim validators could only refute by enumerating all permutations. Check 3: Bounding unknown transactions (lines 9–17). FairFILs may contain transactions unknown to a validator, either due to mempool inconsistencies or because the block assembler βs deliberately injects non-propagated (XOF) transactions. We show in Section 5.2
P. Spiesberger and H. Hartenstein
11
Algorithm 2 Verification of FairFILs by validator v ′ ∈ Vs . ′
Input: Bs−1 , Bs , FairFILs−1 , FairFILs , local mempool Poolvs Output: Votev′ ∈ {FairFILs valid, Bs invalid} /* Check 1: Verifying Inclusion of all previous-FairFIL transactions in Bs 1 foreach τ ∈ FairFILs−1 do 2 if τ ∈ / Bs then 3 return Votev′ : Bs invalid /* Check 2: Verifying self-consistency of FairFILs if FairFILs is not sorted correctly then 5 return Votev′ : Bs invalid
*/
*/
4
state ′ ← execute(FairFILs on state(Bs )) ′ 7 if state is not valid then 8 return Votev′ : Bs invalid 6
9
/* Check 3: Bounding unknown transactions; Constructing extended mempool UnknownCount ← 0; UnknownGas ← 0 ′
*/
′
ExtendedPoolvs ← Poolvs 11 foreach τ ∈ FairFILs do ′ 12 if τ ∈ / Poolvs then 13 UnknownCount += 1; 14 UnknownGas += gas(τ );
10
′
′
15
ExtendedPoolvs ← ExtendedPoolvs ∪ {τ }
16
if UnknownCount > threshold(Poolvs ).count or
′
′
17
18
UnknownGas > threshold(Poolvs ).gas then return Votev′ : Bs invalid /* Check 4: Check FairFILs correctness by constructing a censorship-free block */ FairBlocks ← [ ] ′
19
20
LocalFairOrdering ← {τ ∈ ExtendedPoolvs | τ ∈ FairFILs ∨ 3 s ≤ SLOT_START − first_seen(τ ) ≤ 600 s} τ LocalFairOrdering ← sort(LocalFairOrdering, prim: ftip, gas , sec: tx hash, order: desc.)
state ← state(Bs−1 || FairFILs−1 ) // appending FairFILs−1 on state of Bs−1 . GasUsed ← gas(FairFILs−1 ) 23 foreach τ ∈ LocalFairOrdering do 24 if GasUsed + 21000 > gmax (Bs ) then 25 break
21
22
26 27 28 29 30
state ′ ← execute(τ on state) if state ′ is valid then state ← state ′ GasUsed ← GasUsed + gas(τ ) append τ to FairBlocks
foreach τ ∈ FairBlocks do 32 if τ ∈ / FairFILs ∧ τ ∈ / Bs then 33 return Votev′ : Bs invalid
31
34
return Votev′ : FairFILs valid
12
Accountable Transaction Inclusion Lists
that minor mempool inconsistencies can occur, particularly at home-staking validators; highly optimized builders, operating multiple nodes, are expected to maintain a complete mempool view. Injected XOF poses two problems. First, any XOF transaction in FairFILs must be included in block Bs+1 , allowing block assembler βs to extract MEV across two slots and depriving βs+1 of both block space and the opportunity to extract this MEV itself – a dynamic βs can exploit strategically. Second, a central objective of accountability is that actions within FairFIL remain verifiable for users; injected XOF undermines this, as such transactions appear in FairFILs without prior public visibility and can displace legitimate mempool transactions, as demonstrated in Table 1. Since validators cannot distinguish injected XOF from mempool inconsistencies, we define a private, per-validator threshold on the count and cumulative gas of unknown transactions in FairFILs ; exceeding the threshold causes Bs to be rejected. We specify the threshold in Section 5.2 and argue that the size required to absorb mempool inconsistencies is too small for βs to consume substantial block space or extract meaningful MEV. Unknown transactions within the threshold bounds are added to an extended mempool to preserve dependency chains between known and unknown transactions (line 15). Check 4: Accountability (lines 18–33). To verify that βs accounted for every exclusion, the validator applies Fair Ordering to the extended mempool and constructs a local ‘censorshipfree’ reference block FairBlocks . Every transaction in FairBlocks must appear either in block Bs (included) or in FairFILs (censored by βs ). Any transaction absent from both reveals an undisclosed exclusion and causes the validator to vote against Bs .
5
Analysis of FairFIL
In this section, we first demonstrate deployability by evaluating FairFIL on Ethereum mainnet (Section 5.1) and validate the key assumption of consistent mempools empirically (Section 5.2). Then, we prove that non-compliance with FairFIL causes block invalidation, thereby establishing (M, 1)-censorship resistance, where M is approximately equal to the block reward (Section 5.3). Section 5.4 quantifies censorship costs across all mechanisms.
5.1
Empirical Evaluation
We implement FairFIL and emulate its operation on 214 600 Ethereum mainnet blocks from September 2025, measuring the sizes of the resulting per-slot inclusion lists and the number of censored transactions forced into the subsequent block. To identify censored transactions, we reconstruct a censorship-free reference block for each slot and compare it to the actual Ethereum mainnet block Bs , then construct FairFILs according to Algorithm 1. Method. We use transactions from Flashbots’ Mempool Dumpster [16], a public archive of publicly propagated transactions collected by multiple geographically distributed nodes. For each block Bs , we extract every transaction first observed between 3 s and 600 s before the start of slot s and sequence them according to Fair Ordering. We execute this sequence using a modified version [4] of Foundry’s Anvil [17], adapted to replay a specified transaction sequence against a given historical state. We skip transactions that are not validly includable, as they are not censored in block Bs . The historical state corresponds to the post-state of block Bs−1 and was obtained from a self-operated Ethereum execution-layer node [28].
P. Spiesberger and H. Hartenstein
13
Size of FairFIL
Results. While most blocks are censorship-free, we observe an average of 8.3 censored transactions per block across all observed blocks, amounting to 1.78 million transactions censored by at least one slot during September 2025. Of the 214 600 blocks examined, 81 411 blocks (38 %) yielded a non-empty FairFILs ; averaged over all blocks, a FairFILs contains 7.3 transactions. Figure 1 shows the sizes of FairFILs , grouped by block assembler. Each non-empty FairFILs consumed a median of 63 209 gas in the subsequent block (95th percentile (P95): 6 057 234 gas), corresponding to 0.1 % of the block’s gas budget (P95: 13.3 %). Inclusion of the transactions in FairFILs succeeded in every case, as we formally prove in Lemma 8. We validated robustness by repeating the analysis with the mempool of our own Ethereum node and obtained nearly identical results. Of all transactions censored in slot s, 87.4 % were still includable in block Bs+1 and enforced by FairFILs ; the remaining 12.6 % were no longer includable. For 49.1 % of these non-includable transactions, the provided base fee fell below block Bs+1 ’s base fee. Since base fees rise by at most 12.5 % between two consecutive blocks [8], this non-includability can be prevented by accounting for this worst-case increase upfront in the user’s base-fee bid. A further 50.6 % had been replaced by the user, and the remaining 0.3 % were prevented by other user-initiated state changes. Constructing the FairFILs takes at most 0.388 s per slot in our unoptimized, single-threaded implementation on an AMD EPYC 4564P. This is well below the 4 s attestation deadline, indicating that construction cost is not a limiting factor for the timeliness requirements imposed by Ethereum’s current slot anatomy. Median Mean
100 40 10
Overall median: 0.0 Overall mean: 7.3
1 0
t r r ind ar ) er+ ) n ) .org th ) rNe ) ose ) su ) ilde uil9d7) G=e6211 ethe4rm152) yncb7u47) B=e2483 Bui=ld1696 Pro=p1417 Tit9a1595 Build7e0541 Qua1s1097 b r e 8 s 2 N (n= v 9 (n (n (n (n (n= (n= (n= @r (n= bea (n=
r z er ) r.xy ilde ) Oth1279 ild8e) iobnu=504 u = B ( (n The =80 bob (n
Block Builderper block between blocks 23 264 600 and Figure 1 Size of FairFIL (in number of transactions) 23 479 200 (September 2025), grouped by block assembler. Note the logarithmic y-axis and the number n of blocks proposed by each assembler during the observation period. “Proposer” reflects block assemblers that disclose no identifying information. Block assemblers with fewer than 500 proposed blocks during the observation period are aggregated into “Other”.
5.2
Mempool Consistency
Both the operation and the analysis of FairFIL’s censorship-resistance properties assume that all participants share a sufficiently consistent mempool view. We now revisit this assumption using the September 2025 mempool dataset of the Decentralized Systems Lab at Yale University [11], a data source distinct from the one used in Section 5.1 to guard against source-specific artifacts. In particular, we need to provide evidence that block assemblers can observe every transaction the majority of validators deems relevant under Fair Ordering, and that this majority observes those transactions within the required time window. We show that both hold sufficiently well for FairFIL: block assemblers can be expected to observe all transactions propagated through Ethereum’s P2P network in a timely manner, and in every block, a vast majority of validators would have voted correctly on FairFIL compliance.
14
Accountable Transaction Inclusion Lists
Measurement setup. The dataset provided in [11] contains mempool observations from three nodes geographically distributed across the United States and Germany. We combine this dataset with mempool data from our own Ethereum node, located in Karlsruhe (Germany). Each node logs the first-observation timestamp of a transaction received through Ethereum’s P2P layer. For every transaction contained in the censorship-free blocks (cf. Section 5.1), we take the earliest first-observation timestamp across all four nodes as the transaction’s propagation origin and then measure how many of the remaining nodes observed the transaction within the subsequent 3 s. In this analysis, we do not consider transactions that were not includable in the next possible block, since spam transactions (e.g., severely underpriced ones) would otherwise distort the measurement. The window of three seconds is motivated by prior measurements showing that block assemblers typically begin block construction about 3 s before slot start. Overall, the measurement covers n = 19 609 591 transactions from September 2025. Results. In 96.12 % of all blocks, all four monitors observed every transaction that should appear in a censorship-free block. Moreover, for every block, at least two of the four nodes observed all such transactions. When deviations occurred, they were typically minimal: for each individual node, about 2 % of blocks were missing at most a single required transaction. For the remaining 1.88 % of blocks, closer inspection suggests that the deviations are primarily caused by temporary disruptions at individual nodes, since missed transactions typically occur in bursts across multiple consecutive blocks. Propagation latency across the four nodes, defined as the time between the first observation at any node and the first observation at the last receiving node, was below 0.468 s for 95 % of transactions. Figure 3 in Appendix B shows the resulting per-node consistency distribution. Two quantitative observations follow. ▶ Observation 6 (Single-node coverage). A single reachable node observes at least 90 % of the public transactions that Fair Ordering requires for inclusion in block Bs , within 3 s of first observation by any of the monitoring nodes. ▶ Observation 7 (Multi-node coverage). A block assembler that merges the mempool views of three independent nodes observes every public transaction that Fair Ordering requires for inclusion in block Bs ; using two nodes already covers at least 99.79 % of these transactions. Interpretation. The data suggest that this level of consistency is sufficient for FairFIL. These results do not imply that mempool consensus is trivial. Instead, they provide evidence that the transaction set relevant to FairFIL per slot is likely observable by both a wellprovisioned builder and the validator majority within the required time window, without requiring agreement on temporal ordering. Under enshrined PBS [10], expected in mid-2026, proposers obtain protocol-level access to a specialized builder market in which builders operate as highly optimized infrastructure rather than as individual home servers. Under these conditions, a rational builder can be expected to operate multiple geographically distributed nodes and, by Observation 7, not to miss any transaction that has been known to a majority of nodes for at least 3 s. Regarding enforcement, the same does not hold for validators running a single node, so FairFIL includes an adaptive, validator-local XOF threshold (cf. Algorithm 2, Check 3) to mitigate occasional false votes due to incomplete mempool views. The threshold should be unknown to the block assembler and could be designed to self-adjust: rising on repeated disagreement with the majority, falling otherwise. Empirically, a majority of validators observes all FairFIL-relevant transactions in all cases (Observation 7). Our evaluation of the adaptive threshold shows that it remains equal to zero for most validators and close to zero for the remainder across all blocks.
P. Spiesberger and H. Hartenstein
5.3
Analyzing FairFIL’s Censorship Resistance
We introduce four properties that jointly characterize an accountable mechanism and imply censorship resistance against all protocol-deviating attacks. We prove that FairFIL satisfies each property under the assumption of a bribing budget M ≤ min(R(Bs ), R(Bs+1 )): any violation of an accountability property invalidates a block either at construction (rejecting block Bs ) or at enforcement time (rejecting block Bs+1 ). Property 1 ensures that the obligation to include the set of required transactions Treq imposed by FairFIL can be fulfilled, so failing to include Treq is unambiguous non-compliance. Property 2 requires every censored transaction to appear in Treq ; Property 3 restricts Treq to publicly observed transactions. Property 4 requires that the obligated assembler has no rational incentive to deviate from the obligation. Enforcement rests on majority voting of Vs on Checks 1–4 (Algorithm 2); reversing this verdict requires bribing a majority of Vs at a cost exceeding the full block reward R(Bs ). Throughout, we assume the majority of validators votes correctly. ▶ Property 1 (Includability). For each transaction τ ∈ Treq , the block assembler in slot s + n can include τ in block Bs+n at the position prescribed by Πn , while preserving block validity. A foundational requirement of accountability is the distinction between deliberate noncompliance and circumstances that prevent compliance. Property 1 establishes this distinction by admitting only obligations that the corresponding block assembler can fulfill. Without this property, the assembler could populate Treq with transactions that consume list capacity but cannot be included in the enforcement block, thereby preventing inclusion of the target transaction. Prior work [36] refers to this property as “unconditional”. ▶ Lemma 8. FairFIL satisfies Property 1: every transaction in FairFILs is includable in block Bs+1 at the position prescribed by FairFILs without violating the validity of Bs+1 . Any transaction failing this condition would cause block Bs to be rejected. Proof. By Check 2 of Algorithm 2, the includability of FairFILs requires that executing the entire transaction sequence of FairFILs on top of Bs ’s induced state yields a valid state. Since every operation in Ethereum is deterministic [6], all validators compute the same state and apply the same FairFILs , so the execution outcome is identical across validators. Because transactions in a sequential execution do not retroactively invalidate earlier transactions – each transaction’s validity depends only on the state induced by its predecessors – every prefix of FairFILs executes validly on top of Bs ’s induced state. In particular, the prefix ending in τ executes without violating validity. A majority of validators in Vs has verified this condition and accepted the block; otherwise Bs is rejected. Therefore, βs+1 can include this prefix at least at the beginning of Bs+1 without violating the validity of the protocol. ◀ ▶ Property 2 (Accountable listing). Let τ be a transaction observed by a majority of committee members by a specific point in time. Following Fair Ordering: if τ is includable in block Bs+n , then τ ∈ Treq , unless including τ would displace a higher-tipped transaction τ ′ . An enforceable obligation does not establish accountability if the content of the obligation cannot be verified. Property 2 extends accountability to the construction of Treq : from a consistent mempool view, any party can determine which transactions Fair Ordering mandates, thereby making any omission attributable to the corresponding assembler. ▶ Lemma 9. FairFIL satisfies Property 2: every transaction τ that (i) is observed at least 3 s before the start of slot s by a majority of Vs , (ii) is includable in both blocks Bs and Bs+1 ,
15
16
Accountable Transaction Inclusion Lists ′
τ τ and (iii) would not displace any transaction τ ′ with ftip, gas > ftip, gas , is included in either block Bs or FairFILs . Any omission causes block Bs to be rejected.
/ Bs ∪ FairFILs . Proof. Assume, for contradiction, that τ satisfies conditions (i)–(iii) but τ ∈ Let W ⊆ Vs denote the set of validators that observe τ at least 3 s before the start of slot s; by (i), |W | > |V2s | . Consider any validator v ∈ W executing Check 4 of Algorithm 2. Since τ ∈ Poolvs ⊆ ExtendedPoolvs (Check 3), τ is contained in the local Fair Ordering reconstructed by v. By (iii), no higher-tipped transaction displaces τ , so the iteration over LocalFairOrdering reaches τ ; by (ii), executing τ yields a valid state, so τ is admitted into FairBlocks . Since τ ∈ FairBlocks but τ ∈ / Bs ∪FairFILs , validator v detects undisclosed transaction censorship and votes against Bs . This argument applies to every validator in W , so a majority of Vs , since |W | > |V2s | , rejects Bs , and block assembler βs forfeits the entire block reward R(Bs ). Compensating this loss would require a bribe exceeding R(Bs ) ≥ M, contradicting the budget restriction and thus the assumption τ ∈ / Bs ∪ FairFILs . ◀ ▶ Property 3 (Majority observability). The obligation Treq must contain only transactions observed by a majority of committee members. While Property 2 prevents omission of eligible transactions, a rational assembler may also exploit the obligation by injecting own transactions that were not publicly broadcast beforehand. This undermines accountability, since the construction of Treq is no longer publicly verifiable, and may displace censored transactions. Table 1 illustrates the consequence: placing τprivate in Treq leaves insufficient capacity for the censored τ4 . Property 3 rules out such injections by restricting Treq to transactions observed by a majority of Vs . ▶ Lemma 10. Under Ethereum’s empirical mempool consistency (Section 5.2), FairFIL satisfies Property 3: every transaction τ contained in FairFILs is observed by a majority of Vs ; otherwise, a majority of Vs rejects block Bs . Proof. By Section 5.2, a majority of validators set the XOF threshold in Check 3 of Algorithm 2 to zero; we assume this throughout. Suppose, for contradiction, that some transaction τ ∈ FairFILs is not observed by a majority of Vs . If all validators share the same mempool view, then τ ∈ / Poolvs for every validator v ∈ Vs . Check 3 therefore marks τ as unknown at every validator, and with threshold zero, every v ∈ Vs rejects block Bs . If mempools are heterogeneous, then there exists a majority W ⊆ Vs with |W | > |Vs |/2 such that τ ∈ / Poolvs for every v ∈ W . For each v ∈ W , Check 3 marks τ as unknown, and with threshold zero, v rejects Bs . Hence a majority of Vs rejects Bs . In either case, block assembler βs forfeits the full block reward R(Bs ) ≥ M. Compensating this loss would require a bribe exceeding R(Bs ), contradicting the budget bound. ◀ ▶ Property 4 (Rational builder compliance). The block assembler required to include transaction set Treq in block Bs does so if the assembler behaves rationally. Properties 1–3 make the correctness of transaction set Treq publicly verifiable; accountability, however, requires that this obligation is also enforced. If non-compliance were the rational choice for the obligated block assembler, the assembler would deviate under the rationality model, and the censorship resistance mechanism would fail at enforcement. Compliance with Treq must therefore constitute the rational choice for the obligated assembler. ▶ Lemma 11. FairFIL satisfies Property 4: a rational (or altruistic) block assembler βs+1 includes every transaction τ ∈ FairFILs in block Bs+1 . Any omission of a listed transaction from Bs+1 causes block Bs+1 to be rejected.
P. Spiesberger and H. Hartenstein
Proof. Assume, for contradiction, that a rational block assembler βs+1 does not include some transaction τ ∈ FairFILs in block Bs+1 . By Lemma 8, the omission of τ is a deliberate choice by βs+1 , not a consequence of infeasibility. At slot s+1, every validator v ∈ Vs+1 runs Check 1 of Algorithm 2, which verifies that every transaction in FairFILs appears in block Bs+1 . Since, by assumption, τ ∈ / Bs+1 , Check 1 fails for every v ∈ Vs+1 ; the block is rejected and βs+1 forfeits the entire block reward R(Bs+1 ). Compensating this loss would require a bribe exceeding R(Bs+1 ) ≥ M, contradicting the budget restriction. Any lower bribe would contradict the rationality assumption of βs+1 . ◀ The preceding lemmas establish that any protocol-deviating censorship attempt – whether by omitting a required transaction from FairFILs , injecting unauthorized transactions into FairFILs , or failing to enforce the resulting inclusion obligation – causes block rejection at the cost of R(Bs ) (construction failure) or R(Bs+1 ) (enforcement failure). ▶ Lemma 12. If censorship of transaction τ for more than one slot requires a deviation from FairFIL, then FairFIL is min(R(Bs ), R(Bs+1 )) + cbribe , 1 -censorship-resistant. Equivalently, by deviating from FairFIL, two-slot censorship of transaction τ requires invalidating at least one of the blocks Bs or Bs+1 . The proof is given in Appendix D. Let us now focus on protocol-compliant censoring, i.e., attacks that comply with FairFIL but try to suppress a transaction by other means. In a transaction suppression attack, adversary A acts as an ordinary user and propagates high-tip filler transactions through the network to displace τ below the gas-limit cutoff of the Fair Ordering. We show that, for nearly all transactions, this attack is more expensive than block invalidation. Intuition. Acting as an ordinary user, adversary A propagates transactions through the network such that they appear in regular mempools, where FairFIL treats them equivalently to any other transaction. By propagating a filler transaction τ ′ ranked strictly above τ under Fair Ordering – for simplicity, we assume a single τ ′ suffices and disregard the per-transaction gas cap [3] – A displaces transaction τ below the block’s gas limit gmax (Bs ). Transaction τ is consequently not considered censored and therefore not included in FairFILs ; block assembler βs+1 is thus not obligated to include τ in block Bs+1 , allowing τ to be censored at low cost in Bs+1 . The attack is rule-conforming: FairFIL is verified and enforced as specified. In the following, we derive the (M, σ)-censorship resistance that FairFIL achieves against this attack. Formalization. We write τ ′ ≻ τ if transaction τ ′ ranks strictly above transaction τ under τ′ τ τ′ τ ′ Fair Ordering, that is, if ftip, gas > ftip, gas , or if ftip, gas = ftip, gas and hash(τ ) < hash(τ ). Let Gabove (τ, s) be the cumulative gas of all mempool transactions ranked above transaction τ at slot s, and define the residual gas capacity ∆(τ, s) above τ as the largest amount of additional gas that can be inserted above τ in Fair Ordering while τ still fits within block Bs : ∆(τ, s) = max 0, gmax (Bs ) − Gabove (τ, s) − gas(τ ) . To suppress τ , adversary A must inject filler gas strictly exceeding ∆(τ, s) in transactions τ τ′ τ satisfying τ ′ ≻ τ , at a per-gas cost of at least f ∗ (τ ) := ftip, gas + fbase, gas . Matching ftip, gas rather than strictly exceeding it suffices, since A can outrank τ via the hash tie-breaker. ▶ Lemma 13 (Suppression cost). FairFIL is at most f ∗ (τ ) · ∆(τ, s), 1 -censorship-resistant for any transaction τ , propagated before slot s.
17
18
Accountable Transaction Inclusion Lists
Proof Sketch. An adversary who wants to exclude transaction τ for more than a single slot must first prevent τ from qualifying as censored in slot s – otherwise, βs+1 would be obligated to include τ via FairFILs . This requires injecting a publicly broadcast filler transaction τ ′ whose gas usage exceeds the residual gas capacity of block Bs , at a per-gas cost of at least the total per-gas transaction fee of τ , so that τ no longer fits under Fair Ordering and is not classified as censored. With no inclusion obligation in Bs+1 , the adversary can then exclude τ from Bs+1 at the Ethereum baseline cost CτEth . The full proof is given in Appendix E. ◀ Unlike prior mechanisms, the per-slot cost of censorship under FairFIL is not uniform, but can vary across slots. We derive this fact as follows. At slot s, no inclusion obligation applies to transaction τ , so censoring τ from block Bs costs only the Ethereum baseline CτEth . To extend censorship beyond a single slot, A must either prevent τ from entering FairFILs via the suppression attack or invalidate one of the affected blocks. For the transaction suppression attack, A propagates a filler transaction τ ′ in the same slot as τ , w.l.o.g. slot s, such that τ ′ is included by block assembler βs in block Bs . The block Bs is thereby fully utilized, leaving τ neither included nor classified as censored, and thus excluded from FairFILs . Block assembler βs+1 is therefore not obligated to include τ in block Bs+1 , allowing adversary A to achieve censorship of Bs+1 by paying CτEth . Under this payment, βs+1 is then required to include τ in FairFILs+1 , so A must again prevent inclusion of τ in FairFILs+1 . This coincides with the displacement required for FairFILs and is necessary in every slot in which τ is to be censored for at least two blocks. Thus, the first and last slot in which τ is censored are comparatively cheap, while all intermediate slots require repeated displacement from the preceding FairFIL. The per-slot cost is therefore Cτ = CτEth , f ∗ (τ ) · ∆(τ, s), f ∗ (τ ) · ∆(τ, s + 1), . . . , CτEth . We show in Section 5.4 that, in late 2025, most Ethereum transactions already pay tips sufficient for suppression to cost nearly twice as much as block invalidation; even the mandatory base fee alone exceeds the block invalidation cost. For block invalidation, once a block Bs is invalidated, the subsequent block assembler βs+1 carries no inclusion obligation, so τ can be censored from block Bs+1 at Ethereum baseline cost CτEth . However, the censored transaction must then appear in FairFILs+1 , requiring another block invalidation to sustain censorship in block Bs+2 . This yields an alternating cost pattern between baseline censorship costs and block invalidation. The resulting per-slot cost pattern therefore takes one of two forms, or any combination of the underlined parts, Cτ =
CτEth , R(Bs+1 ) + ϵ + cbribe , . . .
or
Cτ =
R(Bs ) + ϵ + cbribe , CτEth , . . . ,
depending on whether adversary A invalidates Bs+1 (enforcement failure) or Bs (construction failure). Together, these results determine the (M, 1)-censorship resistance of FairFIL.
5.4
Cost of Censorship
We now instantiate the bounds of Lemmas 12 and 13 with empirical Ethereum data to estimate the actual costs of censorship under FairFIL. Table 2 in Section 3 summarizes all results, including surveyed prior mechanisms with the instantiations described below. Empirical Baseline Parameters. To determine the median transaction parameters, we use data from 194 million transactions in blocks 23 264 566–24 136 052 (Sep.–Dec. 2025). Figure 2 shows costs for transaction tips, transaction fees, and block tips at a reference price of 2500 e per Ether, separated into transactions propagated publicly and all transactions
All 0.0118 0.2338
Public 0.0092 0.0952
(a) Transaction tip
Median Mean
Median Mean
1000 100 10
All 0.0614 0.3839
Public 0.0472 0.1968
(b) Transaction fee
All 28.11 52.08
Public 9.09 12.37
(c) Block tip
Number of Blocks
100 10 1 0.1 0.01 0.001
19
in EUR
Median Mean
100 10 1 0.1 0.01 0.001
in EUR
in EUR
P. Spiesberger and H. Hartenstein
140,000 120,000 100,000 80,000 60,000 40,000 20,000 0
Median = 0.441 Mean = 0.406
0.0
0.2
0.4
0.6
0.8
1.0
Private Transaction Fraction
(d) % of XOF per block
Figure 2 Historical transaction and block data (n = 194 051 211 transactions in blocks 23 264 566– τ 24 136 052, Sep.–Dec. 2025) from the Ethereum mainnet. (a) the transaction tip (ftip, tx ) paid to the τ τ assembler (in e); (b) the total transaction fee (ftip, tx + fbase, tx ) paid by the user (in e); (c) the block reward from tips (in e); (d) the per-block fraction of transactions that had not been observed in our mempool dataset [11]. We use a constant exchange rate of 2500 e per Ether.
within the block, as well as the per-block fraction of transactions not observed in our mempool dataset. A public transaction in this period consumes a median of 40 400 gas, τ pays a median per-transaction tip of ftip, tx ≈ 0.01 e to the block assembler, and incurs a total fee of approximately 0.05 e paid by the user. A block assembler collects a median of Rpub (Bs ) ≈ 9.09 e in tips per block from public transactions. At the median, the included public transactions require approximately 7.9 × 106 gas, far below the block gas limit of 45 × 106 gas to 60 × 106 gas in this period (45 × 106 gas in September 2025). Private transactions (≈ 44 % of the median block’s transactions) raise the assembler’s revenue by a factor of 3.1, yielding a median block reward of R(Bs ) ≈ 28.11 e. Based on these data and corresponding to our bribing contract implementation, we set cbribe = 0.08 e (≈ 85 000 gas at base fees)3 and ϵ = 0.01 e. The chosen deviation incentive ϵ is small in absolute terms and, in our view, only meaningful as an incentive for actors that accumulate bribes across many slots, such as operators of many validators [14]. We nevertheless adopt this conservative value to ensure that the protocol resists any short-term rational deviations. Quantifying Censorship Costs. To censor a transaction τ , adversary A must either invalidate a block (Lemma 12) or suppress the transaction (Lemma 13). Empirically, invalidating a block results in a loss of R(Bs ) ≈ 28.11 e; accepting a bribe is therefore the rational decision for a payment of ≈ 28.20 e. In practice, this value is likely higher, since a block assembler typically extracts profitable MEV beyond the tips. To determine the cost of displacing τ from the residual gas capacity in Fair Ordering, we consider τ at the lowest rank under Fair Ordering and quantify the cost of suppressing such a transaction. Empirically, the adversary needs a median of ≈ 37 100 000 gas across all observed blocks to suppress τ . These are e tip-less transactions; at f ∗ (τ ) ≈ 400.038 400 gas , filling this capacity costs approximately 34.9 e. The same calculation for a transaction with a median tip yields 43 000 000 gas and a cost of 50.24 e. Suppression is therefore, in most cases, more expensive than block invalidation. The corresponding costs for n-slot censorship, along with a comparison to prior proposals, are reported in Table 2. Note that whereas prior proposals prevent censorship in the earliest possible slot, censoring a transaction under FairFIL remains cheap in the first
3
We do not implement a fully trustless bribing setup; instead, we rely on the correct operation of an oracle. The reported 85 000 gas correspond to the average per-participant cost of bribing 16 participants, with significant variation depending on the number of participants. The average cost per bribe increases for fewer than 16 participants and decreases for larger sets of participants.
20
Accountable Transaction Inclusion Lists
slot, with substantially higher costs arising at alternating slots thereafter. For example, to censor a transaction for two minutes (ten slots), Ethereum’s upcoming censorship resistance mechanism [13], FOCIL, requires ten times the per-slot bribery cost (total median: 15.40 e), whereas FairFIL requires five block invalidations interleaved with five baseline Ethereum censorship bribes (total median: 141 e).
6
Discussion
6.1
On Fair Ordering and Π1 Mechanisms
FairFIL uses a tip-based reference ordering over publicly observed transactions rather than a receive-time-based fairness notion such as the Aequitas family [24]. Imposing such an ordering on transactions – together with preventing private communication channels – would arguably come closer to the ideal of a fair smart-contract platform. In Ethereum, however, the effects of such constraints on MEV extraction and participant behavior remain, to the best of our knowledge, insufficiently understood. This uncertainty matters because private transactions play a major role in practice. In our measurement period from September to December 2025, they consumed 2.86× as much gas as public transactions. Consistent with prior work [22, 40], this indicates extensive MEV extraction and suggests that private transactions may displace public ones when blocks are fully utilized. These observations motivate our choice of a Π1 mechanism, although FairFIL could also be instantiated as a Π0 mechanism with minor timing adjustments. A Π0 mechanism would constrain the current block assembler with respect to all transactions includable in the current slot. Table 1 illustrates the tension by example: enforcing the Fair Ordering over public transactions in full would leave insufficient capacity for the privately submitted transaction τprivate . Relaxing to Π1 does not fully eliminate this concern, as a large FairFILs may still burden the next assembler. Empirically, however, this obligation is much smaller than what a Π0 mechanism would impose on the current block. Even at the 95th percentile, the inclusion obligation induced by FairFILs occupies only about one seventh of the subsequent block’s gas capacity, whereas a Π0 design would consume roughly half of the current block’s capacity. Given the gas-consumption skew toward private transactions, an accountable Π0 mechanism would therefore already constrain MEV extraction – an effect that warrants further study. We therefore argue that FairFIL’s guarantee – either time-bounded transaction inclusion or censorship costs at the level of one invalidated block – meaningfully improves network reliability while remaining compatible with Ethereum’s current incentive model and slot anatomy.
6.2
Absence of Altruism
Our behavior model assumes the absence of altruistic participants. However, prior work [32] has shown their existence and estimates their prevalence in early 2025 to be at most 1.55 % of validators. Relative to the current state of Ethereum, this implies that in roughly every 67th block, an adversarial bribe fails, even if accepting the bribe would be the rational decision for the block assembler. In particular, in an uncongested network, this yields an effective censorship delay of 13.4 minutes, which we consider insufficient for time-critical applications. For construction-based mechanisms (cf. Section 3), this further implies that in committees of size κ = 128 under a one-of-κ-honest assumption, it is likely that at least one altruistic validator is present. However, at such scales, the influence of an individual committee member becomes small, and even then inclusion of a censored transaction cannot be guaranteed. As a result, users have no guarantee that their transaction will either be included or that
P. Spiesberger and H. Hartenstein
exclusion requires a high-priced bribe by an adversary. Like AUCIL, FairFIL does not rely on altruistic behavior, but instead assumes predominantly rational participants while maximizing the bribe required for successful censorship.
7
Conclusion
Accountability for exclusion decisions – requiring every block assembler to publicly disclose all censored transactions in a verifiable and attributable manner – can substantially raise the cost of censoring a transaction in Ethereum. We established this claim through three contributions. First, we formalized accountability via four properties whose joint satisfaction anchors censorship costs to the full block reward, rather than to the per-transaction tip or committee size as in prior approaches. Empirically, this yields an order-of-magnitude increase relative to prior work such as FOCIL, Ethereum’s upcoming censorship resistance mechanism. Second, we presented FairFIL as an accountable Π1 mechanism and proved that, under a fully rational participant model, a deviation from FairFIL either causes block invalidation or incurs costs of comparable magnitude. Further, FairFIL requires no changes to Ethereum’s existing incentive model. Third, we implemented FairFIL and empirically evaluated it on 214 600 Ethereum mainnet blocks: mempool consistency across validators appears to suffice for FairFIL operation, two-slot censorship costs rise from 3.08 e (FOCIL) to 28.30 e (FairFIL), and the median inclusion obligation imposed on the subsequent block remains small, leaving the assembler’s MEV-extraction freedom largely intact.
21
22
Accountable Transaction Inclusion Lists
References 1
2
3 4
5
6
7 8
9
10
11 12 13 14 15 16 17 18
19
Amitanand S. Aiyer, Lorenzo Alvisi, Allen Clement, Mike Dahlin, Jean-Philippe Martin, and Carl Porth. BAR Fault Tolerance for Cooperative Services. In Proceedings of the 20th ACM Symposium on Operating Systems Principles (SOSP), SOSP ’05, pages 45–58, New York, NY, USA, 2005. ACM. doi:10.1145/1095810.1095816. Maryam Bahrani, Pranav Garimidi, and Tim Roughgarden. Centralization in Block-Building and Proposer-Builder Separation. In Financial Cryptography and Data Security (FC 2024), pages 331–349. Springer, 2025. doi:10.1007/978-3-031-78676-1_19. Tim Beiko. EIP-7825: Transaction Gas Limit Cap. Ethereum Improvement Proposal, 2024. Accessed: 2026-05-09. URL: https://eips.ethereum.org/EIPS/eip-7825. Nils Henrik Beyer, Patrick Spiesberger, and Foundry. Foundry’s Anvil, adapted for MCP and FairFIL. https://github.com/kit-dsn/foundry_fairfil, 2026. GitHub repository. Accessed: 2026-05-09. Pedro Braga, Georgios Chionas, Piotr Krysta, Stefanos Leonardos, Georgios Piliouras, and Carmine Ventre. MEV Sharing with Dynamic Extraction Rates. In Proceedings of the Workshop on Decentralized Finance and Security, page 1–10, New York, NY, USA, 2024. Association for Computing Machinery. doi:10.1145/3689931.3694910. Vitalik Buterin. Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform. White paper. Accessed: 2026-05-09, 2014. URL: https://ethereum.org/content/ whitepaper/whitepaper-pdf/Ethereum_Whitepaper_-_Buterin_2014.pdf. Vitalik Buterin. The Problem of Censorship, 2015. Accessed: 2026-05-09. URL: https: //blog.ethereum.org/2015/06/06/the-problem-of-censorship. Vitalik Buterin, Eric Conner, Rick Dudley, Matthew Slipper, Ian Norden, and Abdelhamid Bakhta. EIP-1559: Fee Market Change for ETH 1.0 Chain. Ethereum Improvement Proposal, 2019. Accessed: 2026-05-09. URL: https://eips.ethereum.org/EIPS/eip-1559. Philip Daian, Steven Goldfeder, Tyler Kell, Yunqi Li, Xueyuan Zhao, Iddo Bentov, Lorenz Breidenbach, and Ari Juels. Flash Boys 2.0: Frontrunning in Decentralized Exchanges, and Miner Extractable Value, and Consensus Instability. In Proceedings of the 2020 IEEE Symposium on Security and Privacy (SP), pages 910–927. IEEE, 2020. doi:10.1109/SP40000. 2020.00040. Francesco D’Amato, Barnabé Monnot, Michael Neuder, Potuz, Justin Traglia, and Terence Tsao. EIP-7732: Enshrined Proposer-Builder Separation. Ethereum Improvement Proposal (Draft), 2024. Accessed: 2026-05-09. URL: https://eips.ethereum.org/EIPS/eip-7732. Decentralized Systems Lab, Yale University. Mempool Guru, 2026. Accessed: 2026-05-09. URL: https://mempool.guru/. Ethereum.org. Ethereum Consensus Layer Specifications, 2025. Accessed: 2026-05-09. URL: https://github.com/ethereum/consensus-specs. Ethereum.org. Hegota Upgrade EIP Proposal Timelines, 2025. Accessed: 2026-05-09. URL: https://blog.ethereum.org/2025/12/22/hegota-timeline. Ethereum.org. Staking as a Service, 2025. Accessed: 2026-05-09. URL: https://ethereum. org/en/staking/saas/. Flashbots. MEV-Boost, 2022. Accessed: 2026-05-09. URL: https://github.com/flashbots/ mev-boost. Flashbots. Mempool Dumpster, 2025. Accessed: 2026-05-09. URL: https://github.com/ flashbots/mempool-dumpster. Foundry. Anvil – Ethereum Development Node. Accessed: 2026-05-09. URL: https://book. getfoundry.sh/anvil/. Elijah Fox, Mallesh M. Pai, and Max Resnick. Censorship Resistance in On-Chain Auctions. In 5th Conference on Advances in Financial Technologies (AFT 2023). Schloss Dagstuhl – Leibniz-Zentrum für Informatik, 2023. doi:10.4230/LIPIcs.AFT.2023.19. Pranav Garimidi, Joachim Neu, and Max Resnick. Multiple Concurrent Proposers: Why and How. 2025. arXiv:2509.23984.
P. Spiesberger and H. Hartenstein
20
21
22
23
24
25 26
27 28 29 30
31
32 33
34
35
36
37
Vincent Gramlich, Dennis Jelito, and Johannes Sedlmeir. Maximal Extractable Value: Current Understanding, Categorization, and Open Research Questions. Electronic Markets, page 49, 2024. doi:10.1007/s12525-024-00727-x. Barbara Guidi and Andrea Michienzi. Linking MEV Attacks to Further Maximise Attackers’ Gains: Evidence from the Ethereum Blockchain. Blockchain: Research and Applications, 2025. doi:10.1016/j.bcra.2025.100340. Lioba Heimbach, Lucianna Kiffer, Christof Ferreira Torres, and Roger Wattenhofer. Ethereum’s Proposer-Builder Separation: Promises and Realities. In Proceedings of the 2023 ACM Internet Measurement Conference (IMC), pages 406–420. ACM, 2023. doi:10.1145/3618257.3624824. Lioba Heimbach, Yann Vonlanthen, Juan Villacis, Lucianna Kiffer, and Roger Wattenhofer. Deanonymizing Ethereum Validators: The P2P Network Has a Privacy Issue. In 34th USENIX Security Symposium, Seattle, WA, USA, 2025. Mahimna Kelkar, Fan Zhang, Steven Goldfeder, and Ari Juels. Order-Fairness for Byzantine Consensus. In Advances in Cryptology – CRYPTO 2020, page 451–480. Springer-Verlag, 2020. doi:10.1007/978-3-030-56877-1_16. Aya Miyaguchi and Vitalik Buterin. The Ethereum Foundation’s Vision. Accessed: 2026-05-09. URL: https://blog.ethereum.org/2025/04/28/ef-vision. Matthias Nadler, Katrin Schuler, and Fabian Schär. Blockchain Price Oracles: Accuracy and Violation Recovery. Journal of Corporate Finance, 2026. doi:10.1016/j.jcorpfin.2025. 102908. Michael Neuder and Terence Tsao. EIP-7547: Inclusion Lists. Ethereum Improvement Proposal (Stagnant), 2024. Accessed: 2026-05-09. URL: https://eips.ethereum.org/EIPS/eip-7547. Paradigm. Reth: A Modular, Contributor-Friendly Implementation of the Ethereum Protocol, 2026. Accessed: 2026-05-09. URL: https://github.com/paradigmxyz/reth. Fred B. Schneider. Implementing Fault-Tolerant Services Using the State Machine Approach: A Tutorial. ACM Computing Surveys, pages 299–319, 1990. doi:10.1145/98163.98167. Caspar Schwarz-Schilling and Francesco D’Amato. Proposer Boost Considerations. Ethereum Notes, 2024. Accessed: 2026-05-09. URL: https://notes.ethereum.org/@casparschwa/ H1T0k7b85. Bence Soóki-Tóth, István András Seres, Kamilla Kara, Ábel Nagy, Balázs Pejó, and Gergely Biczók. Bribers, Bribers on The Chain, Is Resisting All in Vain? Trustless Consensus Manipulation Through Bribing Contracts. Cryptology ePrint Archive, Paper 2025/1719, 2025. URL: https://eprint.iacr.org/2025/1719. Patrick Spiesberger, Nils Henrik Beyer, and Hannes Hartenstein. Why Ethereum Needs Fairness Mechanisms That Do Not Depend on Participant Altruism, 2026. arXiv:2603.05666. Patrick Spiesberger, Jan Droll, and Hannes Hartenstein. A Policy-Based Mitigation of Transaction Exclusion in Ethereum (Work in Progress). In Proceedings of the 30th ACM Symposium on Access Control Models and Technologies (SACMAT), pages 127–132, Stony Brook, NY, USA, 2025. ACM. doi:10.1145/3734436.3734458. Thomas Thiery, Francesco D’Amato, Julian Ma, Barnabé Monnot, Terence Tsao, Jacob Kaufmann, and Jihoon Song. EIP-7805: Fork-Choice Enforced Inclusion Lists (FOCIL), 2024. Accessed: 2026-05-09. URL: https://eips.ethereum.org/EIPS/eip-7805. Terence Tsao. Spec’ing Out Forward Inclusion-List with Dedicated Gas Limits, 2023. Accessed: 2026-05-09. URL: https://ethresear.ch/t/ specing-out-forward-inclusion-list-w-dedicated-gas-limits/. Sarisht Wadhwa, Julian Ma, Thomas Thiery, Barnabé Monnot, Luca Zanolini, Fan Zhang, and Kartik Nayak. AUCIL: An Inclusion List Design for Rational Parties. Cryptology ePrint Archive, Paper 2025/194, 2025. URL: https://eprint.iacr.org/2025/194. Anton Wahrstätter, Jens Ernstberger, Aviv Yaish, Liyi Zhou, Kaihua Qin, Taro Tsuchiya, Sebastian Steinhorst, Davor Svetinovic, Nicolas Christin, Mikolaj Barczentewicz, and Arthur Gervais. Blockchain Censorship. In Proceedings of the ACM Web Conference 2024 (WWW), pages 1632–1643, Singapore, 2024. ACM. doi:10.1145/3589334.3645431.
23
24
Accountable Transaction Inclusion Lists
38
Gavin Wood. Ethereum: A Secure Decentralised Generalised Transaction Ledger. Ethereum Yellow Paper, Shanghai revision. Accessed: 2026-05-09, 2025. URL: https://ethereum. github.io/yellowpaper/paper.pdf.
39
Fei Wu, Thomas Thiery, Stefanos Leonardos, and Carmine Ventre. Strategic Bidding Wars in On-Chain Auctions. IEEE International Conference on Blockchain and Cryptocurrency (ICBC), 2024:503–511, 2024. doi:10.1109/ICBC59979.2024.10634354.
40
Sen Yang, Kartik Nayak, and Fan Zhang. Decentralization of Ethereum’s Builder Market. In Proceedings of the 2025 IEEE Symposium on Security and Privacy (SP), pages 1512–1530. IEEE, 2025. doi:10.1109/SP61157.2025.00157.
A
Notation and Abbreviations
Symbol / Abbreviation Meaning Entities and sets validator set; slot-s committee V , Vs vsP proposer of slot s (vsP ∈ Vs ) βs block assembler of slot s Bs block produced in slot s by βs state(Bs ) execution state after executing Bs mempool view of node n at slot s Pooln s ExtendedPoolvs validator v’s extended mempool (Algorithm 2, Check 3) Transactions and fees τ transaction gas(τ ) gas consumption of τ τ per-gas tip of τ , paid to block assembler βs ftip, gas τ τ τ ftip, per-transaction tip, ftip, tx tx := ftip, gas · gas(τ ) τ fbase, gas per-gas base fee of τ (burned) τ τ τ per-transaction base fee, fbase, fbase, tx := fbase, gas · gas(τ ) tx cbribe on-chain bribing-contract overhead (cost) ϵ protocol deviation incentive (cost) Block and reward quantities gmax (Bs ) gas limit of block Bs R(Bs ) total block reward of Bs (transaction tips + MEV) Rpub (Bs ) tip revenue from public transactions in Bs ∆(τ, s) residual gas capacity above τ at slot s Censorship (Resistance) notions CτEth current per-slot cost of excluding τ A adversary aiming to censor τ M adversary’s per-slot bribing budget (M, σ)-CR censorship resistance notion (Definition 3) Πn CR mechanism for n-slot censorship mitigation (Definition 5) κ committee size of a Πn mechanism Treq transactions required by Πn in a specified block FairFILs inclusion list / FairFIL of slot s FairBlocks local censorship-free block of a validator Table 3 Symbols and abbreviations used throughout this paper.
P. Spiesberger and H. Hartenstein
B
25
Mempool Consistency
Transactions Observed Across the Censorship-Free Blocks (%)
Figure 3 reports per-node mempool consistency relative to the censorship-free blocks constructed in Section 5.1. To measure mempool consistency, we proceed as follows. For every censorship-free block, we consider the set of transactions contained therein and record the earliest first-observation timestamp of each transaction across all monitors. We then determine, for each monitor, the fraction of these transactions observed within 3 s of that timestamp. Each data point on the vertical axis therefore corresponds to a single censorship-free block and quantifies the share of the required transaction set that was timely available at the respective monitor. The horizontal axis distinguishes the three publicly available monitors of [11] in Dallas (US), Frankfurt am Main (GER), and Oregon (US). In the median, every monitor observes all transactions required to reconstruct a censorship-free block. Deviations occur but are confined to a small share of blocks and remain quantitatively small; we characterize their magnitude via the 1st and 2nd percentile of the per-node distribution. For instance, for Frankfurt am Main, P2 = 98.55 % indicates that in 98 % of the observed censorship-free blocks, no more than 1.45 % of required transactions were missing within the three-second time window. The lower P1 of 89.36 % is likely caused by a short-lived monitoring outage, as the missed transactions cluster across several consecutive blocks. Dallas and Oregon exhibit the same pattern at slightly higher percentile values.
100 99
P2: 99.01%
98
P1: 98.18%
P2: 99.09% P2: 98.55%
P1: 98.39%
97 95
Median Mean P1 P2
89
Dallas
P1: 89.36%
Frankfurt
Oregon
Monitor
Figure 3 Per-node mempool consistency during September 2025 at the three monitors of [11]. The vertical axis shows, per censorship-free block, the fraction of required transactions observed within 3 s of their earliest first-observation across all monitors.
C
Proof of Lemma 4 (Ethereum baseline)
τ Proof. Let M := ftip, tx + cbribe . Lemma 4 consists of two claims, which we prove in turn. First, we show that an adversary with per-slot budget M + ϵ can exclude transaction τ from every block, establishing the per-slot exclusion cost CτEth . Second, we show that no adversary with per-slot budget M can delay τ even by a single slot, establishing (M, 0)-censorship resistance.
26
Accountable Transaction Inclusion Lists
Per-slot budget M + ϵ suffices to censor τ in every slot. Adversary A bribes the block assembler βs through the bribing contract [31] to exclude τ from block Bs . Of the τ budget M + ϵ = ftip, tx + cbribe + ϵ, the contract consumes the overhead cbribe , leaving τ a bribe of ftip, tx + ϵ paid to βs upon observed exclusion of τ from Bs . By including τ , τ βs would earn the per-transaction tip ftip, tx ; by excluding τ and accepting the bribe, βs τ earns ftip, tx + ϵ, which strictly exceeds the inclusion payoff for any ϵ > 0. A rational block assembler therefore excludes τ . A can repeat this attack in every slot at the same τ per-slot cost CτEth = ftip, tx + cbribe + ϵ, so τ is never included. Budget M does not suffice to delay τ even by a single slot. Assume, for contradiction, that an adversary with per-slot budget M can cause τ to be excluded from Bs . Then the τ bribe paid to βs is at most M − cbribe = ftip, tx . Accepting this bribe yields βs exactly τ the same payoff as including τ and earning the tip ftip, tx . By Section 2.2, in case of indifference, a rational βs follows the protocol and includes τ in Bs , contradicting the assumed exclusion. Hence no adversary with per-slot budget M can delay τ for any slot. Therefore, Ethereum in its current state is (M, 0)-censorship-resistant. ◀
D
Proof of Lemma 12 (Protocol-deviation cost)
Proof. Let M := min R(Bs ), R(Bs+1 ) + cbribe and, without loss of generality, assume R(Bs+1 ) ≤ R(Bs ) so that M = R(Bs+1 ) + cbribe . We further assume the condition of Lemma 12: two-slot censorship of τ requires a deviation from FairFIL (i.e., suppression is infeasible within the considered budget). We further assume for all proofs that CτEth ≤ M. Enumeration of deviation strategies. For two-slot censorship, transaction τ must be censored from both Bs and Bs+1 . Under the assumption, this requires one of the following protocol deviations: Strategy (a): Construction failure. Adversary A bribes block assembler βs to construct a non-compliant FairFILs that omits τ (Property 2). A majority of Vs rejects Bs (Lemma 9); βs forfeits the full block reward R(Bs ). Strategy (b): Enforcement failure. Adversary A bribes βs+1 to omit τ ∈ FairFILs from Bs+1 (Property 4). A majority of Vs+1 rejects Bs+1 (Lemma 11); βs+1 forfeits R(Bs+1 ). Budget M + ϵ suffices to censor τ for two slots. With R(Bs+1 ) ≤ R(Bs ), adversary A uses Strategy (b): 1. In slot s, A bribes βs at the Ethereum baseline cost CτEth (Lemma 4) to exclude τ from Bs . As τ remains includable in Bs+1 under Fair Ordering, τ enters FairFILs by Lemma 9. The slot-s expenditure is CτEth ≤ M. 2. In slot s + 1, A bribes βs+1 through the bribing contract to omit τ ∈ FairFILs from Bs+1 , resulting in a loss of block reward R(Bs+1 ). The bribe must compensate the forfeiture of R(Bs+1 ) and strictly exceed it by some ϵ > 0 to make omission strictly preferable for a rational βs+1 (Section 2.2); the contract additionally consumes the overhead cbribe . The slot-s+1 expenditure is therefore R(Bs+1 ) + cbribe + ϵ = M + ϵ. The per-slot peak expenditure for two-slot censorship is M + ϵ. By Property 4, Bs+1 is rejected, and no obligations apply to the subsequent block assembler βs+2 . The resulting delay is σ ≥ 2. Thus, FairFIL is at most (M, 1)-censorship-resistant. The case R(Bs ) ≤ R(Bs+1 ) is argumentatively identical, requiring an attack via Strategy (a) and the payment of the baseline cost in slot s + 1.
P. Spiesberger and H. Hartenstein
Budget M does not suffice to censor τ for two slots. Assume adversary A has per-slot budget M and attempts Strategy (b). Of the budget, the bribing contract consumes the overhead cbribe , leaving at most R(Bs+1 ) payable to βs+1 . By accepting, βs+1 forfeits R(Bs+1 ), yielding the same net payoff as honest compliance. By the rationality model of Section 2.2, in case of indifference βs+1 follows the protocol and includes τ in Bs+1 . For Strategy (a), the analogous bribe to βs falls strictly short of the higher loss R(Bs ) ≥ R(Bs+1 ), so βs strictly prefers compliance. Hence no deviation occurs within budget M, and by the assumption, two-slot censorship is infeasible. Therefore, FairFIL is (M, 1)-censorship-resistant. ◀
E
Proof of Lemma 13 (Suppression cost)
Proof. Let M := f ∗ (τ ) · ∆(τ, s). We assume that under Ethereum’s transaction fee mechanism [8], blocks are typically not fully utilized – by design, the average target fullness is approximately half of the gas limit [8]. Consequently, an adversary populating residual gas capacity above τ in Fair Ordering must contribute gas that would otherwise remain unused, so ∆(τ, s) is large relative to the gas of a single transaction. Based on our observations in Section 5.1, we therefore assume throughout that CτEth < f ∗ (τ ) · ∆(τ, s) = M. Budget M + ϵ suffices to censor τ for two slots. Adversary A proceeds as follows: A propagates a filler transaction τ ′ through the P2P layer such that τ ′ ≻ τ under Fair Ordering and the gas usage of τ ′ strictly exceeds ∆(τ, s). The parameter ϵ is required to cover the residual gas cost needed to strictly exceed ∆(τ, s). We simplify the block capacity optimization problem and assume that ϵ is sufficiently large such that replacing τ ′ with a lower-tip transaction would not increase total revenue through higher gas usage. Accordingly, the rational block assembler βs includes τ ′ in Bs to capture its tip, yielding an adversarial expenditure strictly greater than f ∗ (τ ) · ∆(τ, s) = M, where τ τ′ ′ f ∗ (τ ) = ftip, gas + fbase, gas is the per-gas cost required to outrank τ . Including τ in Bs exhausts the available gas capacity above τ in the Fair Ordering: τ is no longer includable in Bs , and by Definition 1, τ ∈ / FairFILs . Since τ ∈ / FairFILs , block assembler βs+1 has no obligation to include τ in Bs+1 . The baseline bribe in slot s + 1 is therefore sufficient to ensure that τ is also not included in Bs+1 . Since CτEth < M + ϵ, this per-slot budget suffices for adversary A to censor τ for two slots. Budget M does not suffice for two-slot censorship via suppression. Assume, for contradiction, that an adversary with budget M achieves two-slot censorship solely via the transaction suppression attack. For τ ∈ / Bs+1 to hold without violating the enforcement of FairFIL, we require τ ∈ / FairFILs ; otherwise Lemma 11 implies τ ∈ Bs+1 . For τ ∈ / FairFILs , the cumulative gas of transactions ranking strictly above τ in the Fair Ordering must exceed ∆(τ, s), i.e., the remaining gas capacity after including τ under Fair Ordering in the block. With budget M = f ∗ (τ ) · ∆(τ, s), the adversary can exactly fill the available gas capacity above τ in Bs , making τ just feasible for inclusion. By the definition of ∆(τ, s), this already exhausts transactions ranking above τ , implying that τ becomes the next transaction to be considered under Fair Ordering. Consequently, given budget M, τ is either included directly in Bs or, by Lemmas 8 and 9, appears in FairFILs and is therefore included in Bs+1 . Accordingly, given budget M, adversary A cannot use the transaction suppression attack to achieve two-slot censorship, contradicting the assumption. ◀
27
28
Accountable Transaction Inclusion Lists
F
Censorship under Prior Censorship Resistance Mechanisms
The following four lemmas bound the censorship resistance of FIL, FOCIL, MCP, and AUCIL, surveyed in Section 3. The proofs share a common structure: for each mechanism, we describe an adversary A with the per-slot bribing budget M that prevents the inclusion of an arbitrary target transaction τ for an unbounded number of consecutive slots. By Definition 3, this establishes that the mechanism is not (M, 0)-censorship-resistant for the selected bribing budget. We do not claim the stated budgets are tight; lower budgets may suffice.
F.1
Forward Inclusion Lists (FIL)
▶ Lemma 14. With FIL [27], an adversary with per-slot budget M = CτEth + ϵ prevents the inclusion of transaction τ for an unbounded number of consecutive slots. Proof. We exhibit adversary AFIL with per-slot budget M = CτEth + ϵ. In each slot s, AFIL bribes the block assembler βs through a single bribing-contract call to (i) exclude τ from Bs τ and (ii) omit τ from Treq . For (i), Lemma 4 establishes that CτEth = ftip, tx + cbribe + ϵ suffices to make a rational βs exclude τ from Bs . For (ii), FIL provides no per-transaction reward for listing in Treq [27], so βs is indifferent between listing and omitting τ ; an additional margin of ϵ makes omission strictly preferable. Since both deviations are settled through the same bribing-contract call, only one overhead cbribe applies, and the total per-slot cost τ Eth amounts to M = ftip, + ϵ. After the attack, τ ∈ / Bs and τ ∈ / Treq , so tx + cbribe + 2ϵ = Cτ no obligation to include τ in block Bs+1 arises. Hence, AFIL can repeat the attack in every subsequent slot at the same per-slot cost, and τ is never included. ◀
F.2
Fork-Choice Enforced Inclusion Lists (FOCIL)
▶ Lemma 15. With FOCIL [34], an adversary with per-slot budget M = κ (ϵ + cbribe ) + CτEth prevents the inclusion of transaction τ for an unbounded number of consecutive slots. Proof. We exhibit adversary AFOCIL with per-slot budget M = κ (ϵ + cbribe ) + CτEth . In each slot s, AFOCIL targets the inclusion committee VsFocil of κ includers and the block assembler βs . For each of the κ includers, AFOCIL pays a bribe of ϵ together with the contract overhead cbribe to omit τ from the includer’s partial inclusion list. Since FOCIL provides no per-transaction reward to includers [34], the includer is indifferent between listing and omitting τ , and the margin ϵ tips the balance toward omission. The total committee cost is κ (ϵ + cbribe ). Once τ is omitted from all κ partial lists, the aggregate Treq does not contain τ , and βs is not obligated to include τ in Bs . However, a rational block assembler βs τ would still include τ voluntarily to capture the transaction’s tips ftip, tx . AFOCIL therefore Eth additionally bribes βs at the Ethereum baseline cost Cτ (Lemma 4) to exclude τ from Bs , yielding the stated total per-slot cost M. Since FOCIL imposes no obligation on subsequent slots, AFOCIL can repeat the attack against the subsequently selected committee in every subsequent slot at the same per-slot cost, so τ is never included. ◀
F.3
Multiple Concurrent Proposers (MCP)
▶ Lemma 16. With MCP [19], an adversary with per-slot budget M = κ · CτEth prevents the inclusion of transaction τ for an unbounded number of consecutive slots. Proof. We exhibit adversary AMCP with per-slot budget M = κ · CτEth . MCP replaces the single block assembler with κ concurrent proposers, each producing an independent partial
P. Spiesberger and H. Hartenstein
block. AMCP targets each of these κ proposers individually, considering the worst case in which every concurrent proposer attempts to include τ in its partial block. Including τ yields τ the per-transaction tip ftip, tx to the proposer [19]. AMCP compensates each proposer for τ the forgone tip ftip, tx , adds the margin ϵ to make exclusion strictly preferable, and pays τ the contract overhead cbribe , totaling CτEth = ftip, tx + ϵ + cbribe per proposer. Across all κ proposers, the per-slot cost amounts to M = κ · CτEth . Since MCP imposes no obligation propagating beyond the current slot, AMCP can repeat the attack against the subsequently selected set of κ proposers in every subsequent slot at the same per-slot cost, so τ is never included. ◀
F.4
Auction-Based Inclusion Lists (AUCIL)
▶ Lemma 17. With AUCIL [36], an adversary with per-slot budget M = (κ + 1) · CτEth prevents the inclusion of transaction τ for an unbounded number of consecutive slots. Proof. We exhibit adversary AAUCIL with per-slot budget M = (κ + 1) · CτEth . AUCIL combines a constructing committee of κ includers with a separate block assembler βs that produces Bs in the same slot, and rewards each includer for the transactions it contributes [36]. AAUCIL adopts the strategy of AMCP (Lemma 16) against the κ committee members: each includer is bribed at cost CτEth to omit τ from its partial inclusion list, totaling κ·CτEth . Once τ is omitted from all κ partial lists, the aggregate Treq does not contain τ , removing the protocol obligation on βs . Unlike MCP, however, AUCIL retains a separate block assembler that τ produces Bs alongside the committee, and a rational βs would still include τ to capture ftip, tx . Eth AAUCIL therefore additionally bribes βs at the Ethereum baseline cost Cτ (Lemma 4) to exclude τ from Bs , yielding the stated total per-slot cost M = κ · CτEth + CτEth = (κ + 1) CτEth . Wadhwa et al. [36] provide a tighter bound on the censorship resistance of AUCIL. Since AUCIL imposes no obligation propagating beyond the current slot, AAUCIL can repeat the attack against the subsequently selected committee and assembler in every subsequent slot at the same per-slot cost, so τ is never included. ◀
29