Facet: An Ethereum Rollup Built for Hard Times

Abstract

We show that most Ethereum rollups, despite claiming to inherit the security of Layer 1, remain vulnerable to forced shutdowns via compromised admin keys. We illustrate how governments or well-funded adversaries could seize control of multisig keys to disable rollup functionality and lock user assets. To address these vulnerabilities we introduce Facet, an Optimism‐based sovereign rollup specifically engineered for “hard times.” Facet eliminates privileged Layer 1 contracts, uses a native token with a “proof-of-L1-blockspace” issuance mechanism, and adopts a permissionless (“based”) sequencing approach. These features eliminate single‐party upgrade controls, thus preserving censorship resistance on par with Ethereum Layer 1—even under extreme threats of government‐mandated shutdowns.

Condensed version

Translations: Chinese, Spanish, French

Introduction

Ethereum's Layer 2 (L2) ecosystem secures over $50 billion¹ in user assets through a simple promise: these systems inherit the security of Ethereum's Layer 1. Based on this principle, Vitalik Buterin introduced a key distinction in November 2024—while Layer 1 must be built to endure severe adversity ("hard times"), L2s can optimize for normal conditions ("good times") by relying on L1's security guarantees in a crisis.

However, can L2s really outsource their security to Layer 1? Not if they can be shut down by a small group of admins. In such a scenario, users would find themselves completely locked out of their assets—unable even to initiate withdrawals to L1.

This vulnerability poses an ecosystem-wide risk. Every major rollup today relies on the same centralized control structure through admin keys. A sufficiently powerful adversary—whether a government agency or well-funded attacker—could target these key holders to disable multiple rollups simultaneously, affecting billions in user assets.

Perhaps most concerning, this vulnerability persists even in rollups that achieve “Stage 2” decentralization—the industry's highest security standard. As we will show, preventing admin-driven shutdowns requires fundamental changes to rollup architecture that go well beyond Stage 2's requirements.

This paper introduces Facet, a new kind of rollup that challenges the traditional L2 security model. Instead of merely relying on Ethereum's security guarantees, Facet achieves independent Layer 1-level resilience. By eliminating privileged admin controls and embracing a fully sovereign design, Facet demonstrates how L2 systems can resist shutdown attempts even under extreme adversity. This approach represents a fundamental shift in rollup architecture, prioritizing censorship resistance over operational convenience.

Our results not only expose critical vulnerabilities in current L2 security assumptions but also provide a practical blueprint for building truly resilient scaling solutions that can match Ethereum's fundamental security guarantees.

A Hard Times Scenario

To demonstrate the limits of inheriting L1 security, let's examine how a crisis might actually unfold. Consider a scenario where the U.S. Securities and Exchange Commission (SEC) obtains a court order to shut down a prominent rollup entirely—no deposits, no withdrawals, no transactions².

Let's analyze OP Mainnet, which represents the most decentralized implementation of the widely-used OP Stack. The argument applies equally to other, less decentralized, rollups.

The path to shutting down a rollup lies in its admin keys—the private keys required to upgrade the rollup's L1 smart contracts. For OP Mainnet, these keys are those required to operate the SuperchainProxyAdminOwner multisig, which requires signatures from two nested multisigs:

• OpFoundationUpgradeSafe (5-of-7)
• SecurityCouncilMultisig (10-of-13)

The SEC would need to control 15 private keys to execute shutdown-related transactions³. This setup illustrates a fundamental dilemma: rollup multisigs must simultaneously protect users from outside attacks while also protecting users from the multisigs themselves. While disclosing signer identities improves transparency, it makes them easier targets. In OP's case, signers are publicly known and so a powerful state actor can likely find and compel each.

Moreover, the same individuals on OpFoundationUpgradeSafe also sit on a separate multisig (OpFoundationOperationsSafe) that, along with BaseMultisig1 (3-of-6), forms the signer set for the BaseAdminMultisig—responsible for upgrading all of Base’s L1 smart contracts. This means if the SEC wanted to attack both OP Mainnet and Base, it would only need to gather three additional signatures, giving it a total of 18 keys to disable nearly $20B⁴ in user assets across two major rollups.

Once the admin keys are compromised, how would the attack proceed? The path is straightforward.

Disabling The Sequencer

First, the SEC could disable the sequencer by calling setBatcherHash(address(0)) on the SystemConfig contract. This halts normal transaction processing, but OP Mainnet has a safeguard: users can bypass a disabled sequencer through "forced inclusion," submitting transactions directly to the OptimismPortal2 contract on L1.

When users call depositTransaction(), the portal emits a TransactionDeposited event that rollup nodes detect, incorporating these transactioons in the next rollup block. These deposit transactions appear at the start of each block before sequencer transactions, and sequencers on OP Stack rollups cannot prevent their inclusion.

This design ensures that a malfunctioning sequencer cannot outright censor user activity⁵.

Disabling Forced Inclusion

Unfortunately forced inclusion can also be disabled by the same admin keys now in the SEC’s control. The attacker need only upgrade OptimismPortal2 (via SuperchainProxyAdminOwner) and remove or disable depositTransaction(). Once that’s done, both the normal sequencer route and the forced-inclusion fallback are gone. The result is a total halt of all OP Mainnet transactions.

In 2024 Blast demonstrated this approach by blocking three addresses from using the Portal to force transactions in order to prevent them from withdrawing stolen funds.

Would Based Sequencing Help?

Some might suggest that "based sequencing"—where anyone can permissionlessly propose rollup blocks—could prevent this attack by eliminating the need for a centralized sequencer.

However, based sequencing alone does not solve the more general problem of admin-driven shutdowns. If an admin multisig can still upgrade the rollup’s critical L1 contracts to turn off permissionless block proposals, the result is the same.

For example, in Taiko—the leading based rollup by TVS—an admin multisig (TaikoAdmin) can upgrade the TaikoL1Contract through which all block proposals flow. It could simply disable the proposeBlock() function, halting all transaction processing. Thus, even a based rollup that lacks a single centralized sequencer can still be stopped by a hostile admin with upgrade power.

Does Stage 2 Help?

OP Mainnet, like most Ethereum rollups, is working toward "Stage 2 Decentralization"—the industry standard for maximum rollup security.

When OP Mainnet reaches its Stage 2 goal, will it better resist attacks via compromised admin keys? The requirements for Stage 2 actually do not add limits to admin control over user transactions. Admins can still halt transactions—they just need to provide 30 days notice, for example by queuing contract upgrades for 30 days before execution.

In their article introducing the Stages Framework, L2Beat described such a 30 day window as an “ample time frame.”⁶ But is it?

When rollup admins initiate a shutdown upgrade, user assets are affected in different ways:

1. EOA-held bridged assets can be withdrawn to the L1, provided their owners are aware of the shut down and capable of acting.
2. L2 native assets such as NFTs become valueless as they cannot be “withdrawn” to the L1 pre-shutdown or interacted with post-shutdown.
3. Bridged assets held by L2 contracts might or might not be withdrawable, depending on the contract logic.

Consider the example of a simple timelock contract:

This contract holds some ERC20 tokens in a 31-day timelock. However, should the rollup’s admin initiate a 30-day shutdown before you deploy the contract, then by the time you are eligible to withdraw at day 31 the rollup will have halted transaction processing. You can neither claim your tokens on the L2 nor move them back to the L1—they are locked forever.

This reveals a bizarre result: even at Stage 2, the highest level of decentralization, contracts cannot reliably enforce timelocks longer than 30 days. This is no corner case—longer timelocks are common in DAO treasuries, team vesting schedules, and asset escrow. Ironically, Stage 2's own rules rely on a timelock mechanism—yet the rollup cannot safely support timelocks beyond its 30-day window.

The timelock example illustrates a broader point: rollups need to support unbounded on-chain time horizons, just as L1 does. Stage 2 decentralization may mitigate some upgrade abuses through its forced withdrawal period, but this isn't enough. If we want to truly "scale Ethereum" while preserving its trust-minimized functionality, we need more than a 30-day safety window.

Potential Solutions

How can we build rollups that maintain their security guarantees even under extreme pressure? The root issue is the power of admin keys, suggesting two possible strategies:

1. Harden admin keys against attack by making them more distributed
2. Eliminate or drastically reduce admin key powers so no single group can halt the chain

There are three paths to pursuing these approaches:

“Stage 3” Decentralization

This approach entails creating a new, higher stage of decentralization, one that does limit admin power. Specifically “Stage 3” would harden admin keys against attacks by requiring they be held not by a multisig contract but by a DAO⁷.

Under this model, rather than having identifiable individuals controlling multisig wallets, upgrade authority would be distributed among governance token holders. An attacker wouldn't be able to simply coerce individual signers, but would instead need to acquire enough governance tokens to control governance outcomes (i.e., execute a 51% governance attack).

The cost of such an attack would scale with the governance token's market capitalization and liquidity, potentially providing significant economic security. However, this approach has a fundamental limitation: the L2 would still be cheaper to attack than Ethereum's L1, as the DAO token's market cap would likely remain smaller than ETH's total market cap. Thus, while Stage 3 could improve upon multisig security, it cannot match L1's economic guarantees.

Native Rollups

Another approach is to build key L2 logic directly into the EVM itself. Rollups that leverage this concept are referred to as native rollups, though no such rollups exist today.

An implementation would require two key components:

1. An EVM precompile contract capable of validating rollup blocks
2. A "wrapper" L1 contract that interfaces with this precompile to handle rollup-specific features like asset bridging and cross-layer messaging

This architecture offers a compelling security advantage: because the precompile would automatically update with Ethereum's protocol upgrades, rollups could inherit new EVM features without requiring admin-controlled contract upgrades. This would substantially reduce the need for admin keys to maintain critical rollup functionality.

However, there are caveats:

• Complex State Transitions and Upgradeability. Modern rollups support complex interactions that go beyond simple transaction validation. Features like L1 contract-initiated L2 transactions might require sophisticated wrapper contract logic—logic that would likely need ongoing upgrades to maintain and enhance. Even with core validation handled by a precompile, this necessity for wrapper contract upgradeability reintroduces the risk of centralized admin control over crucial protocol functions.
• Development Speed. This approach ties rollup development to Ethereum's conservative fork schedule. While independent rollups can rapidly iterate on features and fixes, native rollups must coordinate changes with L1 protocol upgrades, potentially slowing innovation.

The Ethereum research community, led by Justin Drake, is converging on Based Native Rollups as the long term approach for mitigating admin key risk. Vitalkin Buterin also voiced support for Native Rollups as an important area of research, though he did caution “Native rollups are still an early-stage idea. There is a lot of active thinking to be done.”

Despite these limitations, native rollups represent a promising direction for reducing admin key dependencies. By moving critical functionality into the protocol layer, we could significantly decrease the attack surface that upgradeable contracts present, even if we cannot eliminate it entirely.

Facet

A third approach to eliminating admin-key risk is to remove privileged L1 smart contracts altogether, creating sovereign rollup. This approach recognizes that the fundamental security risk comes not from admin keys themselves, but from their control over contracts with special protocol-level powers. By designing a rollup protocol where no single contract holds privileged or "canonical" status, we eliminate any central point that could be used to shut down the chain.

In the OP Stack (and most other rollup architectures), privileged L1 contracts serve three key functions:

• Sequencer selection: Centralized sequencers require a privileged L1 contract to maintain the current sequencer address, allowing benign admins to replace malfunctioning sequencers quickly.
• Forced inclusion mediation: The rollup's ability to process transactions when the sequencer fails depends on privileged contracts that manage forced inclusion and based sequencing mechanisms.
• Native token bridge: While most bridge contracts can be deployed permissionlessly, the bridge handling the L2's native token (typically bridged ETH) must be privileged, as an EVM chain can support only one native token.

In principle, the OP Stack can be modified to eliminate these privileged elements, creating an unstoppable sovereign rollup. Below we walk through the strengths and weaknesses of this approach.

Facet’s Approach to Unstoppability

Facet is precisely such a sovereign rollup—an Optimism-based fork that removes admin-key vulnerabilities. This design lets Facet maintain censorship resistance even in “hard times,” such as when a powerful adversary or government tries to shut down the rollup.

Facet is the only Ethereum rollup live on mainnet today that cannot be shut off by admin keys, which means that if you need to implement a working 31-day timelock on an EVM rollup, Facet is your only option.

How Facet Works

Facet is an Optimism fork that reimagines rollup architecture by eliminating all permissioned actors from the protocol. While maintaining most of the OP Stack's proven functionality, Facet introduces three fundamental modifications:

1. Permissionless Sequencing: Rather than relying on a privileged sequencer, Facet implements based sequencing—allowing any participant to include rollup blocks on L1. This eliminates the need for centralized sequencer selection.
2. Contract-Free Sequencing: Facet's based sequencing operates without any L1 smart contract oversight, removing a common upgrade vector present in other rollups. This ensures no privileged contract can be used to disable transaction processing.
3. Native Token Design: Instead of using bridged ETH like other OP Stack rollups, Facet introduces its own gas token—Facet Compute Token (FCT). This native asset can be earned equally by any participant, eliminating the need for a privileged bridge contract to manage the L2's native currency.

Beyond these core modifications, Facet maintains compatibility with the OP Stack's battle-tested infrastructure. For instance, its bridging system remains fully compatible with Optimism's design—any user can deploy validating bridges and process withdrawals using the L2ToL1MessagePasser predeploy, just as they would on other OP Stack rollups.

In the following sections, we'll explore how these modifications work in practice, beginning with the mechanics of creating Facet transactions.

Creating Facet Transactions

Users create Facet transactions by RLP encoding their transaction data⁸ as the payload of an EIP-2718 typed Ethereum transaction (type 0x46). This encoded data can reach Ethereum through two paths:

1. EOA-Initiated: Send an Ethereum transaction containing the encoded data to the Facet inbox (0x00000000000000000000000000000000000face7)
2. Contract-Initiated: Emit an event with topic 0x00000000000000000000000000000000000000000000000000000face7, including the encoded transaction in the event data

Note: Currently, each Facet transaction requires its own L1 transaction, as batch submissions are not yet supported.

Processing Facet Transactions

A Facet node processes these L1 submissions through three main steps.

Transaction Discovery: The node scans L1 blocks for both direct transactions to the Facet inbox and events with the Facet signature.

Transaction Assembly: For each discovered transaction, the node creates a "deposit transaction"⁹ by adding:

• From: Since Facet transactions aren't individually signed, the source address is inferred:
• For EOA submissions: Uses the Ethereum transaction signer's address
• For contract submissions: Derives an aliased address from the emitting contract (using OP-style aliasing)
• Source Hash: A unique identifier derived from the enclosing L1 transaction hash, necessary because Facet transactions don't use nonces
• Mint Amount: The quantity of FCT to mint to the sender, calculated using Facet's mint formula (detailed in later sections)

Block Creation: After assembly, the node:

• Bundles deposit transactions into Facet blocks.
• Prepends an “L1 Attributes Transaction” to the start of the block. This transaction enables facet-geth to store the L1 block hash and block number corresponding to each Facet block, which enables Facet nodes to handle reorgs.
• Transmits these blocks to the Facet execution engine (a modified op-geth) via the Engine API.

All transactions from an L1 block appear in the corresponding Facet block, preserving their original ordering. While Facet blocks can technically contain transactions whose combined gas exceeds the standard 200 million limit, gas constraints are enforced at execution time—transactions fail if they cannot secure sufficient gas.

Paying Gas on Facet

Most rollups treat bridged ETH as their native gas token—a design that introduces a critical vulnerability. Since EVM chains can support only one native currency, this approach requires designating a privileged bridge contract to mint gas token balances. The result: bridge admin keys gain significant control over the entire rollup's operation.

Facet takes a different approach. Instead of relying on bridged ETH, it introduces FCT (Facet Compute Token) as its native gas token. Users earn FCT through a novel "proof of L1 blockspace" mechanism that works as follows:

1. Transaction Posting: When users submit Facet transactions to L1, they receive FCT in proportion to the L1 gas consumed by their transaction data. Similarly, when contracts emit Facet events, they earn FCT based on their event data's gas cost.
2. Gas Consumption: During execution, the protocol burns a portion of this newly minted FCT to cover L2 computation costs.
3. Token Balance Credit: Any FCT remaining after gas payments becomes part of the user's spendable balance, available for future transactions.

To keep issuance stable and predictable, Facet adjusts the FCT mint rate with a mechanism analogous to Bitcoin’s difficulty adjustment:

• During high usage periods, the mint rate decreases to moderate supply growth
• During low usage periods, the mint rate increases to ensure adequate FCT availability

This design eliminates the need for any privileged bridge contract while ensuring consistent gas token availability for network operations.

Run a Facet Node

All the steps required to derive a Facet block from L1 transaction history are handled automatically by the Facet Node software, which derives the chain’s final state using only data published on Ethereum. The simplest way to run a Facet node is with Docker Compose:

1. Install Docker or Docker Desktop
2. Clone facet-node:
1. git clone https://github.com/0xFacet/facet-node
2. cd facet-node/docker-compose
3. mv .env.sample .env
3. Edit .env to add L1_RPC_URL.
4. Start the node: docker compose up

Bridging on Facet

While Facet reimagines the native gas token, its bridging infrastructure builds upon the battle-tested patterns of Optimistic rollups. By leveraging the OP Stack's permissionless bridge framework, Facet enables developers to deploy and operate bridges with minimal modifications to existing tooling. All bridging functionality is available through our facet-optimism GitHub repository.

Below we discuss deposits, withdrawals, and proofs work in the context of the facet-optimism repository.

Deposits

When bridging assets from Ethereum into Facet, the flow mirrors a typical OP Stack rollup:

1. User calls bridgeERC20() (or similar) on an L1 bridge contract
2. Bridge escrows the L1 tokens and triggers a message to L2 using an event-based Facet transaction.
3. L2 Standard Bridge mints corresponding tokens to the user

Withdrawals

Withdrawing assets back to Ethereum requires a few more steps:

1. User burns their L2 tokens through the L2 Standard Bridge
2. Bridge records a withdrawal message in Facet's state
3. After the challenge period, user proves the withdrawal on L1
4. L1 bridge verifies the proof and releases the original tokens

Proof Systems on Facet

In Facet, like all rollups, users cannot retrieve their L1 assets unless they prove the corresponding L2 tokens have been burned. A full L2 node can attest to this, but executing a complete node on-chain is too expensive. Thus, L2 protocols generally adopt light-client style proof systems—either optimistic or ZK—to validate withdrawals on L1.

Because Facet includes the L2toL1MessagePasser predeploy, the simplest approach is to use the Optimism framework via facet-optimism. This currently uses a permissioned model for state roots, similar to early OP Mainnet.

We plan to upgrade this tooling to support fault proofs, but importantly, this remains at the application layer—individual bridge deployments can choose their own security model.

Unlike traditional rollups where fault proofs secure the native token bridge, on Facet they serve purely to secure individual bridge deployments. This separation between protocol and bridge security is a key benefit of Facet's sovereign design.

The Facet Roadmap

Transaction Batching

While Facet currently requires each transaction to be posted individually to Ethereum, we plan to support more economical transaction submission while preserving censorship resistance:

1. Users will always retain the ability to submit transactions directly to L1, ensuring Facet remains unstoppable even if all aggregators fail.
2. Optional batching mechanisms will let users trade some autonomy (like waiting in transaction pools) for lower costs.
3. Anyone can act as a batch builder, aggregating transactions into either regular calldata or EIP-4844 blobs. Multiple competing builders ensure no single party controls transaction inclusion. Over time Facet transactions could even “hitchhike” on the batches of other unrelated rollups.

Fault Proofs

While Facet’s sovereign design eliminates any requirement for a single on-chain contract to validate state transitions, bridges and applications still need strong correctness guarantees. That’s why we’re forking Optimism’s Cannon system to offer plug‐and‐play fault-proof tooling. Built on our existing OP Stack foundation (op-node and op-geth), this “Cannon‐style” approach will let developers implement secure, instruction‐by‐instruction dispute games for their Facet‐based bridges.

Crucially, these proof systems remain at the application layer—no single “canonical” contract dictates how they must operate. Each bridge can choose its own verification mechanism—optimistic, ZK, hybrid—without impacting Facet’s core protocol or relying on a chain‐level upgrade. In other words, you get the best of both worlds: robust correctness checks when you need them, and a fully sovereign rollup that never places admin‐key power in any single contract’s hands.

Arguments Against Facet

Facet’s hard times readiness requires tradeoffs. In this section we consider criticisms of the Facet model and potential responses.

No Canonical Bridge Leads to Liquidity Fragmentation

Without a single “canonical” bridge, multiple competing assets (e.g., wrapped USDCs) may fragment liquidity and confuse users. Moreover, if a major issuer or DeFi protocol offers a heavily used bridge, it could functionally become “too big to fail,” undermining Facet’s goal of avoiding privileged control.

Response

Facet deliberately rejects any privileged L1 bridging contract, favoring an Ethereum‐like ecosystem where no single stablecoin or “portal” is enshrined. Liquidity might initially fracture across multiple versions of the same asset, but the market typically consolidates around a few well‐audited or trusted bridges—just as Ethereum has multiple stablecoins that coexist peacefully.

Even if one bridge gains dominant market share, it still cannot shut down Facet by unilaterally suspending transactions or upgrading a rollup‐level contract. Social coordination (e.g., switching to a different asset or ignoring the malicious bridge’s contract) remains an option. Ultimately, this design ensures no “canonical” bridge admin can freeze or kill the entire chain.

Forced Inclusion Is Already Available on Other Rollups (So Why Facet?)

OP Stack rollups claim to support forced inclusion via upgradeable L1 contracts. Why not rely on that?

Response

If the L1 contract controlling forced inclusion is upgradeable, an attacker (or coerced admin) can disable it. “Guaranteed forced inclusion” collapses under pressure from compromised keys.

Facet, by contrast, has no privileged L1 contract at all, so no single action can remove forced inclusion. This is crucial in “hard times,” ensuring unstoppable user transactions at the protocol level.

High Costs and Awkward UX for Atomic Transactions

Posting each Facet transaction to Ethereum individually is expensive and can be awkward. Wallets like MetaMask don’t natively support typed transactions with custom call data to a “burn” address.

Response

Facet prioritizes unstoppable forced inclusion as the baseline. Our batching roadmap will let users “hitchhike” on bulk submissions for lower fees, while the atomic fallback remains available at all times. Wallet providers are also likely to add layers of abstraction so users see only “normal” transactions, with the low‐level call data logic happening in the background.

Why Not Rely On Forks During “Hard Times”

If an admin shuts off forced inclusion or censors transactions on a conventional rollup, the community could simply fork away from the compromised chain. Why build a sovereign rollup instead of just relying on forks as the fallback?

Response

Forking is a severe move that demands large‐scale coordination by users, dApps, and infrastructure providers. Meanwhile, a hostile admin on a standard rollup only needs to push a single contract upgrade (or sign a single transaction) to “flip off” the chain. Facet flips that power dynamic: no single admin can kill the chain with one transaction, so any adversarial changes require major social consensus—a far bigger lift than threatening or bribing a few signers. Forks become a true last resort, not a knee‐jerk necessity.

Sovereign Rollups are a “Free For All”

Because Facet is a sovereign rollup, anyone can post any state root, and any node can do whatever it wants. Without a canonical L1 contract, how do we know which state roots are valid?

Response

Facet supports proof systems to verify that proposed state roots align with the chain’s execution rules. These proofs allow any two participants who agree on Facet’s rules to confirm that neither posts an invalid state root.

However, in the event of a hard fork of the Facet protocol, no proof system can determine which version of Facet’s rules is “correct.” In traditional rollups, “correctness” is dictated by the canonical bridge contract. On Facet, this decision relies on social consensus—the community collectively determines which fork constitutes the legitimate chain.

This approach mirrors how Ethereum itself handles contentious upgrades (e.g., Ethereum Classic vs. Ethereum). Once a dominant fork is recognized, no invalid state root can pass a proof check under the recognized chain’s ruleset, preventing the chaos of a “free for all.”

Conclusion

While Ethereum’s Layer 1 is designed to withstand “hard times,” Ethereum rollups do not automatically gain hard times resilience by virtue of being rollups. To serve users in periods of extreme adversity, a rollup must be designed with hard times in mind.

Today, rollup admin key structures introduce critical vulnerabilities—vulnerabilities that persist even in the most "decentralized" systems and aren't addressed in current development roadmaps. Facet presents an alternative: a fundamental reimagining of rollup architecture through a sovereign approach. As the only live Ethereum rollup that cannot be shut off by admin keys, Facet demonstrates that true Layer 1-level censorship resistance is possible at Layer 2. While this path involves trade-offs, we believe it provides a crucial option for users and developers who require guaranteed availability, even in the hardest of times.