Is an L2 Really as Safe as Ethereum? — What a Rollup Inherits, and What It Does Not

A Look Across 129 Rollups at Once

Ethereum struggled with the high cost of processing a single transaction as its bottleneck, and rollups are a design that emerged to lighten that load. A rollup is a ledger that executes transactions outside of Ethereum and posts a summary of those transaction data and execution results back to Ethereum. Ethereum does not handle the computations; it acts as a bulletin board where the summaries of executed transactions and state changes are pinned (arXiv:2510.00164). The underlying ledger like Ethereum is called L1 (Layer 1), and a ledger built a layer on top of it is called L2 (Layer 2), with rollups being the representative L2 design.

A 2025 survey (preprint) took a snapshot of 129 L2 projects at a single point in time. Among them, about 86% allowed upgrades to be applied immediately without giving users time to withdraw. An upgrade means what we saw in "What Is a Smart Contract"—swapping out the code that dictates the tasks of a smart contract, which is a program placed on the ledger. Since the rules of a rollup are written in that code, an upgrade means changing the rules. In about 50%, someone held the authority to freeze withdrawals. Looking at the list of incidents collected by the same survey from 2022 to 2025, the reported incidents were concentrated on cases where a single entity that receives transactions, bundles them in order, and posts them either stopped working or omitted someone's transaction (arXiv:2512.12732).

These numbers do not align with a sentence we often hear: "Rollups sit on top of Ethereum, so they inherit Ethereum's security." This article examines what "inherit" in that sentence actually points to.

Rollups have indeed relieved congestion on Ethereum. In an estimate from a preprint using daily data, during the period before the Ethereum rules changed with Dencun, every 10 percentage point increase in L2 adoption rate lowered the L1 median base fee by about 11%. The authors add that in the period after Dencun where adoption exceeded 85%, this estimate becomes a value that only holds true within that specific range (DOI: 10.2139/ssrn.5887562, preprint). This article does not evaluate specific rollups, nor does it cover market prices, outlooks, or actionable attack procedures. All figures presented here are values observed by those papers at those respective points in time.

Inheriting — "That Data Was There"

Rollups execute transactions on their own network and periodically post those transactions to Ethereum along with a state root. A state root is a summary that compresses the entire state of a rollup—all records inside the rollup, including whose balance is how much—into a single value. A smart contract on Ethereum determines whether the posted state root is final. Finality here refers to finality as described in "Consensus Without Trust", a state where once something is recorded, it can be considered immutable. The contract uses one of two methods: leaving the state root open to challenges, or verifying an accompanying validity proof (arXiv:2404.16150). We will examine each of these two methods one by one in later sections.

The conventional wisdom stems from this. Because the final judgment is made by a smart contract on Ethereum, you cannot breach the rollup unless you breach Ethereum.

If you break down the tasks that a rollup actually hands over to Ethereum, there are only two. Posting the data, and settling the final state based on those posts. The computation itself is done outside (arXiv:2406.02316).

Data availability is the property that anyone can actually obtain the posted transaction data. This property is the root of the rest. You must be able to obtain the data so that a third party can recalculate the rollup's state from the beginning. You have to recalculate it to know whether the uploaded state root is wrong, and you have to know it is wrong to raise an objection. The path to creating a proof that my share is within that state and withdrawing it directly also begins with the data.

Imagine that a bundle of receipts and a summary sheet of their totals are posted together on a bulletin board. Anyone passing by can verify that the receipts are attached. Whether the total is correct can only be known if someone adds up the receipts one by one, or if a proof that the total is correct is attached alongside them. If the receipts are not attached, no one can audit the math. In this article, the bundle of receipts is the transaction data, and the summary sheet is the state root.

The receipt side is precisely what Ethereum reliably gives to a rollup. Once data is included in an Ethereum block, that data was there. This property is inherited. Whether the total is correct is a subsequent question.

When You Save on Costs, You Let Go of Those Guarantees First

The cost of posting data to Ethereum makes up a large share of a rollup's expenses. That is why many L2 designs depart from this baseline form of rollups and take data off Ethereum. One approach is to post only the hash of a bundled batch of transactions instead of the whole batch. As we saw in "What Is a Blockchain", a hash condenses any writing, no matter how long, into a single short value of fixed length. This uses far less Ethereum space, but it creates a need for a separate party to turn that hash back into the original batch (arXiv:2503.05451). A Data Availability Committee (DAC) is a group of a few nodes that agree to restore the hash posted on Ethereum back to the original transaction batch. Nodes are computers that keep and run copies of the ledger ("What Is a Blockchain").

Placing trust in a DAC conflicts with the goal of building an L2 that relies for security solely on L1 (arXiv:2208.02999). To reduce this trust, that preprint proposes a committee protocol that uses financial incentives to deter nodes from refusing to provide requested data. The authors analyze this protocol through a game featuring an adversary capable of suborning and bribing participants, and conclude that under reasonable assumptions about the adversary, it guarantees security with the highest possible probability (arXiv:2208.02999). Once you take data outside, keeping guard over it becomes a matter of incentives and games all over again.

Some designs use an entirely external Data Availability layer (AltDA). Moving data publication off Ethereum allows for processing more data, but it comes at the cost of introducing a new consensus-critical integration layer. Consensus-critical means that if that layer goes wrong, the answer of the entire rollup goes wrong. One preprint lists four things that happen when that layer fails to uphold its duties. The L2 halts, honest nodes read the rollup state differently from one another, invalid state claims emerge, and the bridge moving assets between the rollup and Ethereum is attacked. The authors conclude that safety is not determined by the data layer or the bridge alone, and that integration on the L2 side must maintain verification all the way through (arXiv:2606.03010).

Cost pressures operate inside Ethereum as well. The rollup data-only space (blob) has a fixed posting cost per block, so you pay the same amount regardless of how full it is. Therefore, for rollups that receive transactions infrequently, the delay cost of waiting until the space is completely filled becomes too high, causing them to choose regular block space where costs are more flexible (arXiv:2310.01155).

What Ethereum guarantees is only that "this data was there," and "this state is correct" is not included in that guarantee. The more a design tries to save on costs, the more it ends up letting go of even that first guarantee.

What Is Not Inherited — "This State Is Correct"

An optimistic rollup is a rollup that assumes a posted state is correct until someone steps up to claim it is wrong. The "optimistic" in the name refers to this assumption. A challenge is the procedure of refuting an incorrect state claim on top of Ethereum, also called a fraud proof. It is an interactive procedure that narrows down the point where the two sides' claims diverge, step by step, down to a single computation to decide the winner (arXiv:2210.16610). To guarantee that the challenger's transaction gets included on Ethereum, a generous time window is left open during which a challenge can be made. This is the challenge period (arXiv:2502.20334).

A challenge is not handled automatically by the protocol. Someone must continuously run alongside the rollup, find a discrepancy, put up collateral, send multiple transactions, and have those transactions included on Ethereum within the period. It takes people, capital, and time.

A 2024 preprint takes direct aim at this very spot. It notes that the security of optimistic rollups has been argued "informally," and that those arguments rest on the assumption that certain nodes will inspect the transaction data posted to Ethereum and sound an alarm if they find an error. The authors write that all systems deployed up to that point lacked proper incentive mechanisms to ensure those nodes did their jobs faithfully, relying instead on loose incentive arguments (arXiv:2402.07241).

Formal models point in the same direction. A preprint builds a model of optimistic rollups to show that participants' incentives do not align with expected behavior, which can undermine the security of existing optimistic rollups (arXiv:2312.01549). Another preprint, which generalizes this structure into a "posting game," calls a participant who checks a posted claim and challenges it if it is wrong a validator. It shares only the name with the proof-of-stake validator in "Is Blockchain Really Decentralized". This validator is rewarded only when it challenges an incorrect posting and wins, and receives nothing for the effort of confirming a correct posting. The authors find all equilibria—states where no participant can gain anything by changing their strategy alone ("The Right to Write a Line in the Ledger")—calculate the system loss for each equilibrium, and propose design directions to reduce those losses (arXiv:2407.21413).

The most uncomfortable result comes from optimistic designs in general. A preprint formalizes optimistic mechanisms—which assume everyone will behave well, spanning not just L2s, but also proof-of-stake L1s, cross-chain bridges, and data availability layers—into a single simple game and characterizes all of their equilibria. The authors' conclusion is this: If participants are all rational, such protocols cannot be perfectly secure, and to secure them, designers must introduce a trust assumption that there are altruistic participants. The authors review mitigations such as redistribution among participants or designs relying on succinct proofs (DOI: 10.2139/ssrn.4499357, preprint).

The heavy-weight conclusion of this preprint does not stand alone. The model showing that incentives diverge from expected behavior (arXiv:2312.01549), the system losses at each equilibrium (arXiv:2407.21413), and the observation that there are no incentive mechanisms to guarantee faithful validation (arXiv:2402.07241) all point in the same direction from different angles. It is safer to read this direction than the details of individual theorems.

There is nothing left to win, even if you win, and censorship can block you

In an optimistic rollup, the party that submits the state is called the proposer, and the proposer puts up a stake. If a challenge succeeds, part of that stake goes to the winning validator as a reward. A 2025 preprint models this dispute game and reveals a structural vulnerability. A validator may fail to get a proper profit even after winning a dispute. When competition among validators intensifies due to increased rewards or more participation, a malicious proposer can use a mechanism like an auction to take the value back and greatly reduce their own net loss. The authors conclude that under the design at that time, the competitive pressure among validators might fall short of stopping malicious behavior, and they propose holding the rewards in escrow instead of paying them out immediately and a commit-reveal scheme as countermeasures (arXiv:2504.05094). The intuition that increasing rewards will make validators work harder does not hold up in this model.

Next is censorship. If the transaction of the challenging side fails to land on Ethereum within the time limit, the challenge is useless. A preprint models an economic censorship attack where an attacker bribes the Ethereum block proposer to block the transaction of the defender—that is, the honest side making the challenge. This proposer is the validator whose turn it is to assemble the next part of Ethereum ("Is Blockchain Really Decentralized"), and is different from the rollup proposer in the previous paragraph. At each step, the attacker chooses one of two options: pay a bribe and censor the defender to chew up remaining time, or let this transaction through and save money for the next censorship. The authors calculate the length of the challenge period required to guarantee the defender's victory as a function of the required number of protocol moves and the budgets of both sides (arXiv:2502.20334).

The length of the challenge period is a value that determines security, and that length depends on the budgets available to both sides and the required number of procedures. According to the same study, around 2025, major optimistic rollups set this period to roughly one week. The main purpose was to prepare for censorship strong enough to undermine the security of Ethereum itself, and what other forms, like censorship bought with bribes, mean for security was not well understood (arXiv:2502.20334). That one week is a safety margin bought at the cost of delayed withdrawals.

There are also attempts to change the cost structure of the dispute itself. A fraud proof algorithm published in a journal is designed so that the resources an honest participant must mobilize to defeat an adversary grow only logarithmically—that is, very slowly—relative to the money the adversary ultimately loses. Therefore, there is no need to demand a large stake to prevent a Sybil attack where fake identities are created in bulk ("What Is a Blockchain"), and one can join a dispute without pooling resources together. The authors summarize it as follows: the entire dispute ends in at most 2 to 5 challenge periods, and the only way to break consensus is to censor the honest side for longer than one challenge period (DOI: 10.1145/3734698).

Even with an algorithm that lowers dispute costs this much, the last remaining attack vector is censorship.

A State Where Nothing Happens

A rollup where no challenges have ever occurred is indistinguishable on the surface from one where everyone was honest. From the outside, it is impossible to tell whether it is quiet because no one is watching, or because someone watched and found nothing wrong.

The study that pointed out the lack of incentives earlier targets precisely this spot. The authors propose a protocol that makes watchtowers—nodes that watch rollups and sound an alarm if they spot an error—continually produce proofs that they actually verified the L2's claims, and rewards them in return. Under the assumption that watchtowers act rationally and are weakly independent of one another, the authors' result is that this mechanism is provably secure (arXiv:2402.07241). The fact that a new device like this had to be proposed means that rollups at that point lacked proof that those who watched had truly watched.

Accountability is the ability to point out and prove who broke the rules, and has been cited as a major economic argument supporting proof-of-stake security. One preprint defines this property for rollups and presents an attack showing that existing designs lack accountability. It then introduces a rollup design equipped with accountability and proves its security (arXiv:2210.15017).

The Sequencer—A Single Authority That Decides the Order

The sequencer is the entity in a rollup that receives user transactions, determines their order, bundles them together, and posts them to Ethereum (arXiv:2511.22317). As of 2023, rollups were entrusting this job to a single centralized sequencer (arXiv:2310.03616). As "Is Blockchain Really Decentralized" showed, the position that decides the order is inherently a lucrative power, known as MEV—the profit that can be extracted by inserting, removing, or reordering transactions that will go into the next block. In a rollup, the sequencer holds that position.

A systematic review paper (a preprint) on decentralized sequencer research puts it this way: rollups relying on a centralized sequencer to determine transaction order undermines the decentralization principles of blockchain. Therefore, decentralized sequencers are needed, but designing such systems is tricky (arXiv:2310.03616). The risks left open by a centralized sequencer include censorship, transaction manipulation, and tampering (arXiv:2511.22317). If a sequencer fails to build rollup blocks or post new state roots to Ethereum, users may be unable to access their assets on the rollup (arXiv:2503.23986). It aligns with this dependency that the incidents reported in the first section's survey were concentrated on sequencer liveness and inclusion—that is, whether the sequencer keeps running and whether it includes my transactions (arXiv:2512.12732).

Eliminating the centralized sequencer also comes with a cost. A preprint that implemented a fully decentralized sequencer had to design an incentive scheme to pay servers that followed the rules, along with a fraud proof mechanism to catch rule violations, accompanied by a proof that the implementation is correct (arXiv:2406.02316). Another approach is to protect the sequencer by putting it inside a Trusted Execution Environment (TEE)—a protected enclave isolated within the chip. However, the attestation process—which proves from the outside that the designated code is running inside the TEE—introduces another layer of centralization. The same preprint reports that by making this verification process decentralized, it increased the integrity of the sequencer on a rollup testnet without breaking compatibility with existing architectures (arXiv:2511.22317). When shifting to decentralization, the trusted party moves, and separate safeguards must be attached to each place it moves to.

Can You Get Out — Forced Inclusion and the Escape Hatch

The designs for when the sequencer leaves out my transaction are two. Forced inclusion is a channel where a user pushes a transaction directly into the Ethereum-side contract, and makes the rollup process that transaction within a set time. The escape hatch is a path where, if the sequencer stops altogether, the user withdraws assets directly from Ethereum without going through the sequencer (arXiv:2503.23986).

One escape hatch design (preprint) combines a mechanism that opens over time, a short proof showing that my share is inside the state root (a Merkle proof), and a newly devised contract. The core difficulty was enabling the assets held by a smart contract to be found and taken out within the L2 state root (arXiv:2503.23986). One preprint models a forced transaction queue, a secure blocklist, and an upgrade feature in a specification language to find the pitfalls of existing designs, and presents an improved model whose correctness is verified by model checking. The same paper worries about the centralized control of L2, and writes that as of 2024, "L2s are exposed to multisig attacks, and that can lead to the total loss of user funds" (arXiv:2406.16219). Multisig is a method, as seen in "Where Are My Coins?", where multiple keys are set up and a designated number of them must sign together for funds to move.

The numbers in the first section answer how widely these safety devices are actually deployed. Projects that can be upgraded immediately without any grace period for withdrawal were about 86%, and projects with proposer control that can freeze withdrawals were about 50%. The same survey analyzes that as much as whether forced inclusion exists, whether it can actually be used is also a risk factor, and reads it through the framework that operator discretion and information asymmetry bring risk back in (arXiv:2512.12732).

There is also research that views the upgrade process itself as a vulnerable spot. According to a 2022 preprint, the optimistic rollups of that time tightly bound the Ethereum-side judge that adjudicates disputes to a single specific L2 program. The authors argue that this structure increases the risk of concentrated failure on a single implementation, bloats the code that must be trusted—making auditing difficult—and that the process of changing rules through frequent and opaque upgrade procedures widens the room for attack (arXiv:2212.05219).

"What Is a Smart Contract?" summarized that in a contract written to be modifiable, whoever holds the keys to modify becomes a new place that must be trusted, and if it is left unmodifiable, there is no way to patch a crack. Rollups sit on the same scale. Remove the upgrade keys, and bugs cannot be fixed; leave them, and those keys become the ultimate place of trust. What changes is where on the scale each project stands.

What Validity Proofs Change and What They Do Not

Another branch does not wait for objections. A validity proof is a proof that the state has been correctly updated, generated mathematically alongside a state root, and contracts on Ethereum verify this proof (arXiv:2404.16150). A roll-up that turns this proof into a zero-knowledge proof—a proof showing that something is true without revealing the information itself—is a zk-roll-up as seen in "Zero-Knowledge Proofs: Proving the Truth Without Reveals the Data", which processes transactions off the main chain and leaves proof on the main chain that the transaction data and their execution are correct. The data goes up as is, and the proof attaches right beside it. The prover is the party that generates this proof.

What changes is clear. The room for dispute games from the previous sections—whether someone will appear to object, whether rewards will be properly received, whether censorship will occur—shrinks dramatically. That preprint formalizing the limits of optimistic design also points to designs relying on succinct proofs as a mitigation (DOI: 10.2139/ssrn.4499357, preprint).

Three things do not change either.

First, data availability remains rooted as before. Even with a validity proof, without the data to recalculate the state, users cannot prove their share and withdraw it. The unified structure analyzed by the AltDA verification framework from earlier also included validity proof-family roll-ups (Avail-ZKsync) (arXiv:2606.03010).

Second, generating proofs is expensive, creating centralization pressure. The computational burden of generating validity proofs is a challenge for both performance and decentralization, and the solution as of 2025 is to leave computation to centralized infrastructure, which limits both the scalability and decentralization of roll-ups. However, the same preprint presents experimental results showing that even when proof generation is split among multiple community provers with modest hardware, performance comparable to—and sometimes better than—traditional centralized deployment is achieved (arXiv:2501.03126). A preprint modeling the cost of proof infrastructure notes as a constraint that finality is reached only after multi-stage proofs are all completed and the results are posted to Ethereum (arXiv:2509.16581).

Third is the most important. That a proof is correct and that the object proven is correct are different things. A zkEVM is an executor that rewrites Ethereum's execution rules so they can be proven with zero-knowledge proofs. According to a preprint, if there is a subtle implementation bug such as miscalculating gas, a value assigned at each computation step, a valid proof ends up attesting to a semantically incorrect state, and the cryptographic guarantees are quietly neutralized. The same study proposes a framework for automatically generating verification models from zkEVM code, and reports a bug detection rate of over 90% in a newly created source-level zkEVM verification benchmark (arXiv:2607.19795). What a proof system proves is only that the computation described by the circuit—the bundle of mathematical expressions rewriting the computation to be proven—was actually executed. Whether that circuit correctly transcribes Ethereum's rules lies outside the proof.

New avenues of attack targeting provers also emerge. A preprint analyzes a pricing misalignment vulnerability in the roll-up fee schedule. By crafting and submitting transactions that maximize proof computation relative to the assigned gas, proof generation can effectively be brought to a halt, delaying finality by several hours, with the observed increase in finalization delay being approximately 94-fold. The authors also present mitigations to prevent this (arXiv:2509.17126). This means that fee schedules even dictate who reaches finality and when.

Roll-ups using zero-knowledge proofs trade the human question of "who will object?" for the engineering questions of "is this circuit correct, and is the prover alive?" The questions do not disappear; their category changes.

"To inherit" needs an object

The short list of things rollups automatically inherit from Ethereum is just that—short. Above all, the data recorded on Ethereum is there. The rest is work someone has to do every single time.

That is why "Is this L2 as secure as Ethereum?" cannot be answered in one line. What can be answered is a list.

① Where is the data? Is it on Ethereum, an external data availability layer, or a committee? Stepping outside creates a new consensus-threshold layer, and if those duties lapse, you get an L2 halt, discrepancies between nodes, invalid state claims, and bridge attacks (arXiv:2606.03010).

② Who points out an incorrect state, and why do they do that job? Systems deployed as of 2024 left only incentive arguments in this spot without proper incentive mechanisms (arXiv:2402.07241), and formal models say those incentives diverge from expected behavior (arXiv:2312.01549; arXiv:2407.21413). Even a victory where you win nothing is possible (arXiv:2504.05094).

③ What happens if that pointing-out is blocked? The length of the dispute period is a function of the censorship budget (arXiv:2502.20334), and even in algorithms that drastically lower dispute costs, the final attack slot is censorship (DOI: 10.1145/3734698).

④ If the sequencer stops, can I get out? Escape hatches can be designed (arXiv:2503.23986) and forced-inclusion queues can also be formally verified (arXiv:2406.16219). The remaining question is whether they are actually deployed and usable (arXiv:2512.12732).

⑤ Who can change today's rules tomorrow? Upgrade privileges are both a tool to fix bugs and the ultimate place of trust (arXiv:2512.12732; arXiv:2212.05219).

Moving to validity proofs greatly shrinks ② and ③. Instead, ①, ④, and ⑤ remain as they are, and two more items appear. Did the circuit correctly translate Ethereum's rules (arXiv:2607.19795), and is the prover alive and can no one make them stop (arXiv:2509.17126)?

There is no reason to tilt toward cynicism. For each item, paths to fix it are being proposed and verified. Examples include an algorithm that lowers dispute costs logarithmically (DOI: 10.1145/3734698), a protocol that forces verifiers to prove honesty (arXiv:2402.07241), formally verified escape hatches and forced-inclusion queues (arXiv:2406.16219; arXiv:2503.23986), and a framework that reported a bug detection rate of over 90% in a zkEVM verification benchmark (arXiv:2607.19795). Only when problems are explicitly written down can we find a way to fix them.

There is no reason to tilt toward optimism either. None of the preceding improvements mean "this item no longer needs to be asked about." Improvements only shift the position on the scale; they cannot eliminate the scale itself. Regarding blockchain in general, a journal article demonstrated through mathematical proof that trying to simultaneously maximize decentralization, security, and scalability creates internal contradictions (DOI: 10.3390/app15010019).

The verb "to inherit" needs an object.

The property that the data is there is inherited. The property that the window to point out wrongs is on Ethereum is also inherited. However, the property that someone will actually use that window is not inherited. That property must be built anew by people, capital, and time every single time, and whether it is being built does not show on the surface on calm days when nothing is happening.

What Ethereum does for a rollup does not go as far as guaranteeing that the rollup is correct. It goes as far as setting aside a place to expose it when it is not correct. Setting aside a place and having someone stand in that place are different things. The first is inherited, and the second is not.

Source Papers

• "Ethical Risk Analysis of L2 Rollups" (2025) — arXiv:2512.12732 (preprint) — 129 L2BEAT snapshots + 2022–2025 incident catalog. Roughly 86% instant upgradeability, about 50% proposer control enabling withdrawal freezing, and incidents concentrated in sequencer uptime and transaction inclusion.
• "Calyx: Privacy-Preserving Multi-Token Optimistic-Rollup Protocol" (2025) — arXiv:2510.00164 (preprint) — A rollup skeleton that uses Ethereum as a bulletin board rather than a calculator.
• "Do Layer-2s Decongest Ethereum?" (2025) — DOI: 10.2139/ssrn.5887562 (preprint) — A 10 percentage point increase in L2 adoption lowers the L1 median base fee by roughly 11%, with local estimation for the >85% range.
• "A Rollup Comparison Framework" (2024) — arXiv:2404.16150 (preprint) — State root posting and finality determination structure, the axes of rollup comparison.
• "Fast and Secure Decentralized Optimistic Rollups Using Setchain" (2024) — arXiv:2406.02316 (preprint) — The list of tasks rollups delegate to L1, implementing a fully decentralized sequencer.
• "A Decentralized Sequencer and Data Availability Committee for Rollups Using Set Consensus" (2025) — arXiv:2503.05451 (preprint) — A design that posts only hashes and the committee it necessitates.
• "Cryptoeconomic Security for Data Availability Committees" (2022) — arXiv:2208.02999 (preprint) — DAC trust clashes with the goal that "security relies solely on L1." A protocol incentivizing against data withholding.
• "Secure AltDA Integration for Ethereum L2s" (2026) — arXiv:2606.03010 (preprint) — External DA is a new consensus-threshold layer. Missing obligations lead to L2 halts, cross-node discrepancies, invalid state claims, and bridge attacks.
• "EIP-4844 Economics and Rollup Strategies" (2023) — arXiv:2310.01155 (preprint) — The latency costs generated by blob fixed costs and the choices of low-arrival-rate rollups.
• "Optimistic and Validity Rollups" (2022) — arXiv:2210.16610 (preprint) — Interactive binary search for fraud challenges, comparing optimistic and validity proof types.
• "Proof of Diligence: Cryptoeconomic Security for Rollups" (2024) — arXiv:2402.07241 (preprint) — Highlighting the absence of incentive mechanisms guaranteeing diligent execution, and a protocol having watchtowers prove their verification.
• "Incentive Non-Compatibility of Optimistic Rollups" (2023) — arXiv:2312.01549 (preprint) — Incentives are misaligned with expected behavior.
• "Games in Public Announcement" (2024) — arXiv:2407.21413 (preprint) — Verifiers are rewarded only when they successfully challenge an invalid announcement. All Nash equilibria and losses per equilibrium.
• "On the Security of Optimistic Blockchain Mechanisms" (2023) — DOI: 10.2139/ssrn.4499357 (preprint) — Perfect security is impossible if everyone is rational, requiring an assumption of altruistic participants.
• "Hollow Victory" (2025) — arXiv:2504.05094 (preprint) — Winning may yield no profit, and increasing rewards and participation can reduce malicious proposers' net losses.
• "Economic Censorship Games in Fraud Proofs" (2025) — arXiv:2502.20334 (preprint) — Bribery censorship games. Deriving the required dispute period as a function of move counts and both parties' budgets.
• "Dave: A Decentralized, Secure, and Lively Fraud-Proof Algorithm" (2026) — DOI: 10.1145/3734698 — Honest participants' resources grow only logarithmically. Disputes terminate within a maximum of 2 to 5 periods, with the remaining attack surface being censorship.
• "Accountable Safety for Rollups" (2022) — arXiv:2210.15017 (preprint) — Attacks demonstrating the lack of accountability in existing designs and alternative designs.
• "SoK: Decentralized Sequencers for Rollups" (2023) — arXiv:2310.03616 (preprint) — Dependence on a central sequencer undermines decentralization principles, yet designing decentralized sequencers is difficult.
• "Enhancing the Security of Rollup Sequencers using Decentrally Attested TEEs" (2025) — arXiv:2511.22317 (preprint) — The risks of central sequencers (censorship, manipulation, tampering) and the centralization TEE attestation reintroduces.
• "A Practical Rollup Escape Hatch Design" (2025) — arXiv:2503.23986 (preprint) — Loss of asset access upon sequencer failure, designing an escape hatch using triggers, Merkle proofs, and resolvers.
• "Towards a Formal Foundation for Blockchain Rollups" (2024) — arXiv:2406.16219 (preprint) — Formal modeling of forced transaction queues and upgrades. L2s are exposed to multisig attacks that can lead to total fund loss.
• "Specular" (2022) — arXiv:2212.05219 (preprint) — Monolithic dispute resolution breeding single-implementation risk, trust assumptions, and governance attack surfaces.
• "CrowdProve: Community Proving for ZK Rollups" (2025) — arXiv:2501.03126 (preprint) — Centralization pressure in proof generation and community prover decentralization experiments.
• "Towards Cost-Effective ZK-Rollups" (2025) — arXiv:2509.16581 (preprint) — The constraint that every proving step must land on-chain to achieve finality.
• "Towards Automated Formal Verification of zkEVMs" (2026) — arXiv:2607.19795 (preprint) — Implementation bugs cause valid proofs to attest to incorrect states. Automated synthesis achieves a detection rate exceeding 90%.
• "Unaligned Incentives: Pricing Attacks Against Blockchain Rollups" (2025) — arXiv:2509.17126 (preprint) — Attacks halting proof generation, with observed finalization delays increased roughly 94-fold.
• "The Blockchain Trilemma: A Formal Proof" (2024) — DOI: 10.3390/app15010019 — The internal contradiction of maximizing decentralization, security, and scalability simultaneously.