Accountable Transaction Inclusion Lists: Enhancing Ethereum's Censorship Resistance

Hannes Hartenstein; Patrick Spiesberger

REVIEW 3 major objections 5 minor 47 references

Accountable Transaction Inclusion Lists: Enhancing Ethereum's Censorship Resistance

T0 review · 3 major / 5 minor · reviewed 2026-08-01 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗

Pith's one-line read FairFIL claims accountability can raise the cost of sustained Ethereum censorship by an order of magnitude, anchoring it to the full block reward instead of per-transaction tips.

desk verdict Solid empirical work and a genuinely new accountability framing, but the central cost claim collapses under PBS because the party that selects transactions is not the party that forfeits the block reward. read the letter →

arxiv 2607.22040 v1 pith:BNZHJM3Y submitted 2026-07-24 cs.DC

Patrick Spiesberger , Hannes Hartenstein This is my paper

classification cs.DC

keywords Ethereumcensorshipresistanceinclusionlistsaccountabilitytransactionexclusionproposer-builderseparationblockrewardmaximalextractablevalue

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper argues that existing Ethereum censorship-resistance mechanisms fail because no one is accountable for exclusion decisions: committee members can omit transactions at negligible personal cost. It proposes FairFIL, a protocol where every block builder must publicly publish a verifiably complete list of all transactions it chose to censor, and the next builder must include them or forfeit the entire block reward. Under a rational-participant model, this makes multi-block censorship roughly ten times more expensive than under current proposals, with two-slot censorship of a median-tip transaction costing about 28-50 EUR instead of ~3 EUR under FOCIL. The paper also reports that FairFIL lists would be small on Ethereum mainnet and that mempool consistency across validators appears sufficient for the mechanism to work.

What carries the argument

The central object is the FairFIL inclusion list itself, produced by a deterministic 'Fair Ordering' that sorts mempool transactions by descending per-gas tip (hash as tie-breaker) and admits them while block gas allows. The list is verified by four checks: enforcement of the previous list, self-consistency/includability, bounding of unknown transactions, and accountability via reconstructing a censorship-free reference block. The load-bearing lever is block-reward forfeiture: the party that assembles a block loses its entire reward if the list is incomplete or unenforced, which anchors censorship costs to R(Bs) rather than to per-transaction tips or committee size.

What would settle it

Observe a live proposer-builder-separation deployment where an external builder omits a FairFIL-listed transaction: if the block is rejected and the proposer (not the builder) forfeits the reward while the builder keeps its MEV profit, then the claimed order-of-magnitude cost increase does not hold for the actual censoring party.

Watch

Extended reading notes

Core claim

The central claim is that making exclusion decisions accountable — requiring every block assembler to publicly disclose all censored transactions in a way that is verifiable and attributable — substantially raises the cost of transaction censorship. FairFIL does this by forcing each builder to publish a fairness-ordered list of every transaction it omitted that was includable; a validator committee verifies completeness, and the next builder must include the list or lose the full block reward R(Bs). Any deviation triggers block rejection, so extending censorship beyond one slot requires either invalidating a block (forfeiting ~28 EUR at median) or flooding the network with high-tip filler tr

Load-bearing premise

The paper assumes that the party controlling block content — the block assembler — is also the party that forfeits the block reward when a block is rejected, but under today's Proposer-Builder Separation an external builder makes the inclusion decisions while the proposer would typically bear the penalty.

Editorial extensions

If this is right

If FairFIL is adopted, any transaction must be included within one slot unless an adversary pays at least the full block reward or floods the block with filler transactions.
Multi-block censorship costs become roughly an order of magnitude higher than under FOCIL, FIL, MCP, or AUCIL, changing the economics of time-critical applications like on-chain auctions.
The mechanism does not rely on altruistic validators, so its guarantees hold under the fully rational BAR model assumed by the authors.
Because most MEV-extraction freedom is preserved, the design is more likely to be compatible with the current incentive structure and validator adoption patterns.
The empirical result that 87.4% of censored transactions remain includable in the next block suggests that the obligation set is practical, and users can further protect themselves by bidding base fees that anticipate a 12.5% worst-case increase.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

A key untested implication is whether the penalty actually lands on the party making inclusion decisions under live Proposer-Builder Separation; if an external builder decides content but the proposer/validators bear the block-reward penalty, the order-of-magnitude cost increase could vanish in practice.
The proposed adaptive validator-local threshold for unknown transactions could be gamed: a builder might inject just below the threshold of XOF transactions to displace censored ones, so the threshold's calibration deserves direct attack testing.
The suppression attack cost scales with residual block gas capacity; a testable extension would be to measure how changing Ethereum's gas limit or per-transaction gas caps shifts the relative cost of suppression versus block invalidation.
The paper's finding that 50.6% of non-includable censored transactions were user-replaced suggests a user-side mitigation: replacing a transaction proactively can circumvent FairFIL's enforcement, which could be exploited by an adversary who can induce replacements.

Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

The core idea is worth taking seriously: make exclusion decisions public and punishable, and you anchor censorship costs to the block reward rather than to per-transaction tips. The formalization of the four accountability properties and the (M,1)-CR proof are real contributions, and the empirical evaluation on 214,600 mainnet blocks is substantial. The cost comparison against FIL/FOCIL/MCP/AUCIL is clearly laid out, and the data on mempool consistency, while limited, is a useful first step. This is not a throwaway paper.

The soft spots are, unfortunately, load-bearing. The PBS problem is the big one. The paper defines "block assembler βs" to include delegated builders, but then lets that entity forfeit R(Bs) when a block is rejected. Under live PBS, the external builder chooses which transactions go in, while the proposer is the one who loses the block reward (and faces slashing). The builder loses at most the tips and MEV that the rejected block would have delivered. So the rational builder's cost of censoring a transaction is not the full block reward—it is roughly the forgone tips plus any expected future builder revenue. Lemma 11 and Property 4 prove that a rational proposer would comply, not that the entity doing the censoring would. That is a direct hit to the order-of-magnitude claim.

Second, there is an internal inconsistency between Algorithm 1 and Check 4. Algorithm 1 builds FairFIL from transactions first seen in the last 603 seconds, but Check 4 only verifies transactions first seen 3–600 seconds before the slot. A transaction older than ten minutes or younger than three seconds can be censored without appearing in FairFIL, and no validator would catch it. That contradicts the abstract's "every transaction the builder chooses to censor." It is a gap that could be patched, but as written the mechanism does not enforce its headline promise.

Third, the mempool consistency argument jumps from four well-provisioned nodes to a majority of ~30,000 validators. Observation 7 says "two nodes cover 99.79%," but those two nodes are not sampled from the validator set. The adaptive XOF threshold is plausible but underspecified. This is a moderate concern, not a fatal one.

The paper is honest about building on the authors' own SACMAT sketch, and the self-citation does not bother me; the formal properties and mainnet evaluation go well beyond that sketch. The suppression-cost analysis (Lemma 13) is neat, though it too depends on the block assembler's identity.

Who should read this? Anyone working on Ethereum inclusion lists, PBS, or censorship resistance. It deserves a serious referee, but the referee should be told to press hard on the PBS question before the cost claims are accepted. My recommendation: send it to peer review, expect significant revision, and do not let the current version's central claim through without an explicit model of who bears the penalty under ePBS.

Referee Report

3 major / 5 minor

Summary. The paper proposes FairFIL, an accountable inclusion-list mechanism for Ethereum that requires the block assembler to publish all transactions it censors under a protocol-anchored 'Fair Ordering'; a validator committee verifies completeness, and the next assembler must include the listed transactions or forfeit the block reward. The authors formalize four accountability properties, prove that FairFIL achieves (M,1)-censorship resistance for M approximately equal to the block reward, and quantify censorship costs using mainnet data from September–December 2025. They conclude that multi-block censorship under FairFIL costs about an order of magnitude more than under FOCIL and other existing proposals.

Significance. If the central claim held, this would be a valuable contribution: the paper is clearly written, gives a useful decomposition of accountability into four properties, and is unusually strong empirically. It provides a public implementation, reproduces cost estimates for FIL/FOCIL/MCP/AUCIL from a common empirical base, and uses a second, independent mempool dataset to probe the key consistency assumption. The paper also adds a concrete rational-actor analysis of a censorship mechanism, including a suppression attack. However, the central security theorem relies on a model of block assembly that does not match live PBS, so the headline order-of-magnitude cost increase is not established for the setting the paper itself motivates.

major comments (3)

[§2.1, Lemma 11, Property 4] The paper defines βs as 'the party that actually constructs the block – whether the proposer itself or a delegated builder under PBS' (§2.1). Lemma 11 then concludes that a rational block assembler βs+1 includes every transaction in FairFILs because omitting one causes block Bs+1 to be rejected and βs+1 to 'forfeit the entire block reward R(Bs+1)' (§5.3). Under live PBS (EIP-7732 / MEV-Boost), the external builder selects the transactions, while the proposer is the party that loses the block reward if the block is rejected; the builder loses at most the expected payment from the proposer and any bond, neither of which is modeled or bounded by R(Bs+1). The proof therefore establishes compliance only for an integrated proposer/builder. Since §1 motivates the mechanism by builder centralization under PBS, the party that actually censors in practice is typically a delegated builder, and the
[§4.1 Algorithm 1 vs §4.2 Algorithm 2 Check 4] Algorithm 1 line 4 constructs the Fair Ordering from transactions satisfying first_seen(τ) ≥ SLOT_START − 603s. But Check 4 (Algorithm 2 line 19) builds the validator’s LocalFairOrdering from transactions satisfying 3s ≤ SLOT_START − first_seen(τ) ≤ 600s. These sets differ: transactions first seen within 0–3s of the slot and those first seen 600–603s before the slot are included in the builder’s obligation set but are excluded from the validators’ reference block. Consequently, a builder can censor such transactions and omit them from FairFILs without triggering the majority rejection on which Lemma 9 relies. The empirical evaluation in §5.1 also uses the 3s–600s window, so the protocol does not enforce the 'complete disclosure of all excluded transactions' that Section 4.1 describes. Algorithm 1, Algorithm 2, and Definition 1 must be aligned; the current 603s window / 600s-check inconsi
[§5.2, Lemma 10] Lemma 10’s proof states: 'By Section 5.2, a majority of validators set the XOF threshold in Check 3 of Algorithm 2 to zero; we assume this throughout.' This is an assumption about validator behavior, not a property proved from the protocol. Section 5.2’s own measurements show that individual honest nodes miss one or more FairFIL-relevant transactions in about 2–4% of blocks (e.g., Figure 3: Frankfurt P2 = 98.55%, P1 = 89.36%). With a hard threshold of zero, those validators would vote against valid blocks whenever they lack a transaction that the builder legitimately included in FairFILs, causing false invalidations and penalizing compliant builders. An adaptive per-validator threshold is mentioned but not specified, and no completeness or liveness analysis is provided for threshold values above zero. Property 3 is therefore not proven for the mechanism as specified, and the mechanism’s

minor comments (5)

[Fig. 1] The y-axis is logarithmic, yet the text reports 'Overall median: 0.0'. A log axis cannot display zero; the median should be reported in the caption or text, and the axis/scale should be described consistently.
[Table 2] The FairFIL row reports both 'Suppression' and 'Invalidation' as cumulative 1/2/10-slot costs. It would help to state explicitly which attack is being aggregated and how the alternating cheap/expensive slot pattern is reflected in the cumulative sums.
[§4.1, footnote 2] The 603s window is explained as 'fifty slots (600s) plus a 3s propagation margin'. This is confusing: if 3s is a propagation margin before slot start, it should exclude transactions appearing within 3s of the slot, not extend the window to 603s. The intended semantics should be stated precisely and consistently with Definition 1.
[§5.3, Lemma 13 proof sketch] The proof sketch says 'we assume a single filler transaction suffices and disregard the per-transaction gas cap'. This limitation is material to the cost formula and should appear in the lemma statement or main text, not only in the proof sketch.
[§5.4 footnote 3] The bribe overhead cbribe is estimated from 'the average per-participant cost of bribing 16 participants', but the number 85000 gas appears to be for a specific implementation. The text should clarify the dependence of cbribe on committee size and protocol mechanics, since the cost comparisons in Table 2 are sensitive to this parameter.

Circularity Check

0 steps flagged · score 2.0 of 10

No significant circularity: cost results follow from the protocol's specified penalty and external empirical data; self-citations are minor.

full rationale

The claimed derivation chain is not circular in the forbidden sense. FairFIL's per-slot censorship cost is the block reward R(Bs)/R(Bs+1) because the protocol itself specifies block rejection and forfeiture of that reward as the consequence for non-compliance (Section 4.2; Lemma 11). Thus the high cost is a designed penalty, not a parameter fitted to data and then relabeled as a prediction. The empirical comparison to prior mechanisms (Table 2) instantiates that penalty using externally measured median block rewards (approx. 28.11 EUR) and a separately stated bribe-overhead cbribe = 0.08 EUR; these are independent inputs, not outputs of the same calculation. The paper relies on the same authors' prior work [33] for the initial sketch of FairFIL and on [32] for the altruism prevalence estimate, but neither citation carries the proof of the central cost claim, which is re-derived from the protocol rules and mainnet data. A non-circular correctness gap exists: Section 2.1 defines 'block assembler beta_s' to include delegated builders under PBS, and Lemma 11 assumes that entity forfeits R(Bs+1); under live PBS the proposer, not the external builder, bears the on-chain penalty, so the cost result may not bind the actual censoring party. This is an assumption/validity concern, not a circular reduction. Overall, the central derivation is self-contained against external benchmarks, so the circularity score is low.

Assumptions & free parameters 4 free parameters · 7 assumptions · 2 invented entities

The protocol's guarantees rest on a rational-participant model, an on-chain-only bribery model, a majority-validator correctness assumption, and an assumed mempool consensus; the enforcement penalty is assumed to hit the block assembler even under PBS.

free parameters (4)

603s/600s inclusion window = 603s in Algorithm 1, 600s in Check 4
Chosen by the authors to bound mempool emulation; determines which transactions are protected and contradicts the 'all transactions' claim.
cbribe = 0.08 EUR (~85k gas)
Assumed overhead for an on-chain bribing contract; affects all cost comparisons and is not based on a deployed implementation.
epsilon (deviation incentive) = 0.01 EUR
Chosen to make bribes strictly preferred; small in absolute terms but enters every per-slot cost formula.
Validator XOF thresholds = 0 for most, close to 0 otherwise; adaptive and unspecified
Private per-validator thresholds on unknown transactions are critical for Check 3; no concrete algorithm is given, and the value materially changes which blocks are accepted.

assumptions (7)

domain assumption All validators and block assemblers are rational in the BAR model; no altruists exist.
Section 2.2: a participant deviates iff deviation yields strictly higher payoff; ties resolve to compliance. This is needed for all lemmas.
domain assumption Adversary per-slot budget M does not exceed min(R(Bs), R(Bs+1)) and cannot bribe a majority of the validator committee.
Section 2.2 'Budget restriction': larger budgets could halt chain liveness or buy committee majority, outside scope.
domain assumption Validators and block assemblers have a sufficiently consistent mempool view.
Section 5.2: proofs of Properties 2-4 rely on a majority of validators seeing the same Fair-FIL-relevant transactions; empirical evidence is from four specialized nodes.
domain assumption A majority of validators votes correctly on Checks 1-4.
Section 5.3: 'Throughout, we assume the majority of validators votes correctly.'
ad hoc to paper Block invalidation causes the block assembler to forfeit the full block reward, even under PBS.
Section 2.1 models proposer and delegated builder as a single 'block assembler'; under live PBS the proposer/validators, not the builder, absorb the rejection penalty.
ad hoc to paper The tip-descending Fair Ordering is protocol-anchored and all parties agree on it.
Definition 1 and Algorithm 1/2: censorship is defined relative to this reference ordering, which is not an existing Ethereum consensus rule.
domain assumption Bribes are paid only through an on-chain bribing contract with overhead cbribe; out-of-band payments are excluded.
Section 2.2: this makes bribery costs measurable but ignores real-world side payments.

invented entities (2)

FairFIL inclusion list (FairFILs)
purpose: Public, verifiable disclosure of all transactions the builder claims to censor, creating the accountability mechanism.
Protocol artifact specified in this paper; no external falsifiable prediction beyond the paper's own simulation and implementation.
Adaptive validator-local XOF threshold
purpose: Bounding unknown transactions in FairFIL to tolerate mempool inconsistency while preventing private-transaction injection.
Unspecified private threshold; no implementation or security analysis is provided.

how reviews work

0 comments

Cite this review

Pith. "Pith review of Accountable Transaction Inclusion Lists: Enhancing Ethereum's Censorship Resistance." pith.science (2026). https://pith.science/paper/BNZHJM3Y

@misc{pith2026260722040,
  author       = {Pith},
  title        = {Pith review of: Accountable Transaction Inclusion Lists: Enhancing Ethereum's Censorship Resistance},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/BNZHJM3Y}},
  note         = {Machine review of arXiv:2607.22040}
}

read the original 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 Euro 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.

Discussion (0). Sign in to comment.

Reference graph

Works this paper leans on

47 extracted references · 4 linked inside Pith

[1]

2014 , note =

Buterin, Vitalik , title =. 2014 , note =

2014
[2]

2025 , note =

Wood, Gavin , title =. 2025 , note =

2025
[3]

2019 , howpublished =

Buterin, Vitalik and Conner, Eric and Dudley, Rick and Slipper, Matthew and Norden, Ian and Bakhta, Abdelhamid , title =. 2019 , howpublished =

2019
[4]

2024 , howpublished =

Neuder, Michael and Tsao, Terence , title =. 2024 , howpublished =

2024
[5]

2024 , howpublished =

D'Amato, Francesco and Monnot, Barnab. 2024 , howpublished =

2024
[6]

2024 , howpublished =

Beiko, Tim , title =. 2024 , howpublished =

2024
[7]

Proceedings of the 2020

Daian, Philip and Goldfeder, Steven and Kell, Tyler and Li, Yunqi and Zhao, Xueyuan and Bentov, Iddo and Breidenbach, Lorenz and Juels, Ari , title =. Proceedings of the 2020. 2020 , pages =

2020
[8]

Electronic Markets , year =

Gramlich, Vincent and Jelito, Dennis and Sedlmeir, Johannes , title =. Electronic Markets , year =

Show all 47 references

[9]

Blockchain: Research and Applications , year =

Guidi, Barbara and Michienzi, Andrea , title =. Blockchain: Research and Applications , year =
[10]

Wahrst. Time to. 2023 , eprint =. doi:10.48550/arXiv.2305.16468 , note =

2023 doi arXiv
[11]

Proceedings of the 2023

Heimbach, Lioba and Kiffer, Lucianna and Ferreira Torres, Christof and Wattenhofer, Roger , title =. Proceedings of the 2023. 2023 , publisher =

2023
[12]

Proceedings of the 2025

Yang, Sen and Nayak, Kartik and Zhang, Fan , title =. Proceedings of the 2025. 2025 , pages =

2025
[13]

Financial

Bahrani, Maryam and Garimidi, Pranav and Roughgarden, Tim , title =. Financial. 2025 , publisher =

2025
[14]

Blockchain

Wahrst. Blockchain. Proceedings of the. 2024 , pages =

2024
[15]

2015 , url =

Buterin, Vitalik , title =. 2015 , url =

2015
[16]

2025 , howpublished =

Tornado. 2025 , howpublished =

2025
[17]

2001 , doi =

Jones, Derek , title =. 2001 , doi =

2001
[18]

2024 , url =

Thiery, Thomas and D'Amato, Francesco and Ma, Julian and Monnot, Barnab. 2024 , url =

2024
[19]

2025 , howpublished =

Wadhwa, Sarisht and Ma, Julian and Thiery, Thomas and Monnot, Barnab. 2025 , howpublished =

2025
[20]

2023 , url =

Tsao, Terence , title =. 2023 , url =

2023
[21]

2023 , howpublished =

Neuder, Michael and Buterin, Vitalik , title =. 2023 , howpublished =

2023
[22]

2025 , eprint =

Garimidi, Pranav and Neu, Joachim and Resnick, Max , title =. 2025 , eprint =

2025
[23]

2025 , eprint =

Stouka, Aikaterini-Panagiota and Ma, Julian and Thiery, Thomas , title =. 2025 , eprint =

2025
[24]

and Resnick, Max , title =

Fox, Elijah and Pai, Mallesh M. and Resnick, Max , title =. 5th. 2023 , publisher =

2023
[25]

Proceedings of the 2024

Wadhwa, Sarisht and Zanolini, Luca and D'Amato, Francesco and Asgaonkar, Aditya and Fang, Chengrui and Zhang, Fan and Nayak, Kartik , title =. Proceedings of the 2024. 2024 , pages =

2024
[26]

and Alvisi, Lorenzo and Clement, Allen and Dahlin, Mike and Martin, Jean-Philippe and Porth, Carl , title =

Aiyer, Amitanand S. and Alvisi, Lorenzo and Clement, Allen and Dahlin, Mike and Martin, Jean-Philippe and Porth, Carl , title =. Proceedings of the 20th. 2005 , pages =

2005
[27]

Bribers,

So. Bribers,. 2025 , howpublished =

2025
[28]

, title =

Schneider, Fred B. , title =. ACM Computing Surveys , pages =. 1990 , doi =

1990
[29]

Proceedings of the 30th

Spiesberger, Patrick and Droll, Jan and Hartenstein, Hannes , title =. Proceedings of the 30th. 2025 , pages =

2025
[31]

2026 , howpublished =

Nils Henrik Beyer and Patrick Spiesberger and Foundry , title =. 2026 , howpublished =

2026
[32]

Aya Miyaguchi and Vitalik Buterin , title =
[33]

2025 , url =

Staking as a. 2025 , url =

2025
[34]

2022 , howpublished =

2022
[35]

2025 , howpublished =

2025
[36]

International

Eskandari, Shayan and Moosavi, Seyedehmahsa and Clark, Jeremy , title =. International. 2019 , pages =

2019
[37]

and Gervais, Arthur , title =

Zhou, Liyi and Qin, Kaihua and Torres, Christof Ferreira and Le, Duc V. and Gervais, Arthur , title =. Proceedings of the 2021. 2021 , pages =

2021
[38]

Proceedings of the Workshop on Decentralized Finance and Security (

Yang, Sen and Zhang, Fan and Huang, Ken and Chen, Xi and Yang, Youwei and Zhu, Feng , title =. Proceedings of the Workshop on Decentralized Finance and Security (. 2024 , series =

2024
[39]

Heimbach, Lioba and Vonlanthen, Yann and Villacis, Juan and Kiffer, Lucianna and Wattenhofer, Roger , title =. 34th. 2025 , address =

2025
[40]

Proceedings of the 38th

Pavloff, Ulysse and Amoussou-Guenou, Yackolley and Tucci-Piergiovanni, Sara , title =. Proceedings of the 38th. 2023 , pages =

2023
[41]

2020 , isbn =

Kelkar, Mahimna and Zhang, Fan and Goldfeder, Steven and Juels, Ari , title =. 2020 , isbn =. doi:10.1007/978-3-030-56877-1_16 , booktitle =

2020 doi
[42]

2603.05666 , archivePrefix=

Patrick Spiesberger and Nils Henrik Beyer and Hannes Hartenstein , year=. 2603.05666 , archivePrefix=

arXiv
[43]

2024 , url =

Caspar Schwarz-Schilling and Francesco D'Amato , title =. 2024 , url =

2024
[44]

doi:10.1016/j.jcorpfin.2025.102908 , author =

Journal of Corporate Finance , year =. doi:10.1016/j.jcorpfin.2025.102908 , author =

2025
[45]

IEEE International Conference on Blockchain and Cryptocurrency (ICBC)

Fei Wu and Thomas Thiery and Stefanos Leonardos and Carmine Ventre. IEEE International Conference on Blockchain and Cryptocurrency (ICBC). 2024. doi:10.1109/ICBC59979.2024.10634354

2024
[46]

Felten and Akaki Mamageishvili and Benny Sudakov , year=

Ben Berger and Edward W. Felten and Akaki Mamageishvili and Benny Sudakov , year=. 2502.20334 , archivePrefix=

arXiv
[47]

2024 , isbn =

Braga, Pedro and Chionas, Georgios and Krysta, Piotr and Leonardos, Stefanos and Piliouras, Georgios and Ventre, Carmine , title =. 2024 , isbn =. doi:10.1145/3689931.3694910 , booktitle =

2024
[48]

Zhuolun Li and Evangelos Pournaras , year=. SoK:. 2411.09981 , archivePrefix=

arXiv

Pith tools

Reviewed August 1, 2026 · model on record in the stance chip above.

[1] [1]

2014 , note =

Buterin, Vitalik , title =. 2014 , note =

2014

[2] [2]

2025 , note =

Wood, Gavin , title =. 2025 , note =

2025

[3] [3]

2019 , howpublished =

Buterin, Vitalik and Conner, Eric and Dudley, Rick and Slipper, Matthew and Norden, Ian and Bakhta, Abdelhamid , title =. 2019 , howpublished =

2019

[4] [4]

2024 , howpublished =

Neuder, Michael and Tsao, Terence , title =. 2024 , howpublished =

2024

[5] [5]

2024 , howpublished =

D'Amato, Francesco and Monnot, Barnab. 2024 , howpublished =

2024

[6] [6]

2024 , howpublished =

Beiko, Tim , title =. 2024 , howpublished =

2024

[7] [7]

Proceedings of the 2020

Daian, Philip and Goldfeder, Steven and Kell, Tyler and Li, Yunqi and Zhao, Xueyuan and Bentov, Iddo and Breidenbach, Lorenz and Juels, Ari , title =. Proceedings of the 2020. 2020 , pages =

2020

[8] [8]

Electronic Markets , year =

Gramlich, Vincent and Jelito, Dennis and Sedlmeir, Johannes , title =. Electronic Markets , year =