Facet: The Unstoppable Ethereum Rollup

Introduction

Ethereum rollups secure tens of billions in user assets, yet almost all can be halted or censored by a handful of admin keys. These systems simultaneously advertise that they will eventually “inherit L1 security”—a promise that, as Vitalik Buterin put it, “assets on the L2 are safe and can be withdrawn as long as the L1 is secure.”

Because users cannot withdraw from a stopped rollup, unstoppability is a prerequisite for inheriting Ethereum’s security. Yet the community’s rollup Stages Framework never targets unstoppability: even its end-state (Stage 2) lets administrators halt a rollup so long as they give users a 30-day exit window.

We define an Unstoppable Rollup as a rollup that takes the alternate approach: a rollup that cannot be interrupted without compromising the L1. No exit windows, no security councils.

This paper has three parts:

• Stage 1 Case Study: Base. Exactly how the largest OP Stack chain can be halted today¹, and the changes required to make it unstoppable.
• Stage 2 Exit-Window Analysis. Why a 30-day exit window still leaves users exposed to asset loss.
• The Facet Solution. A deep dive into Facet’s approach to achieving unstoppability.

How to Stop a Rollup

Definitions

A rollup is considered stopped when any of the following conditions holds:

• Block production ceases entirely
• An account or class of transactions is censored for a prolonged period
• The gas token is manipulated so that normal users cannot purchase block space

Our focus is rollup protocols with built-in administrative controls that enable chain halts—not stoppage achieved through exploits or denial-of-service attacks. We are specifically concerned with forced stoppage (changes imposed without user consent) rather than voluntary migrations where users choose to follow a fork with different rules.

Unlike Ethereum L1, which defines its protocol rules entirely in node software (“off-chain governance”), rollups implement key protocol rules in L1 smart contracts. This “on-chain governance” enables administrators to modify the protocol without requiring users to voluntarily update their software.

In certain cases, this approach is uncontroversial. For example, some rollups manage their sequencer's address with an L1 contract. Here's how it works: rollup nodes read from a "system configuration contract" every block to determine the current authorized sequencer address. When processing batches, they only accept transactions from that source.

This is useful because if the sequencer's address needs to be changed, admins can simply update the address in the contract. Nodes automatically pick up the new value without requiring a coordinated fork—an elegant solution for this specific case.

In addition to predefined configuration options, however, many rollups rely on L1 smart contracts that are arbitrarily upgradeable. While users can plan around certain predefined capabilities (like updating the sequencer’s address), upgradeable contracts can be modified to add entirely new capabilities that weren't initially contemplated.

This architecture creates specific vectors for forced stoppage, as we'll see in our case study of Base.

Stopping Base (The Largest OP Stack Rollup)

Base is the largest Optimism rollup and therefore serves as a useful yardstick for “Stage 1 security.” Everything described below applies generically to any OP Stack chain.

We first examine stopping Base by disabling its sequencer through a configuration change:

• Contract: SystemConfigProxy
• Keys required: 3 of 14 (Base Multisig 1)
• Action: call setBatcherHash(bytes32(0))

A single L1 transaction signed by any 3 of the 14 keys is enough to swap the sequencer to an address with no known private key. Rollup nodes will enforce the change from the next L2 block.

Even without multisig intervention, the current sequencer can unilaterally censor or halt the chain. This vulnerability has already manifested in the broader rollup ecosystem:

• In June 2024 Linea responded to a DEX hack by halting block production and censoring attacker accounts.
• In January 2025 Soneium blocked trading of the potentially trademark-infringing memecoin $AIBO.

Forced Inclusion: A Partial Solution

While disabling the sequencer halts ordinary transactions, OP Stack rollups implement a backup mechanism called Deposit Transactions (referred to informally as “forced inclusion”). This allows users to submit transactions directly through an L1 contract, bypassing sequencer censorship.

Forced inclusion is implemented via the depositTransaction function on the OptimismPortal2 contract. When called, this function emits a TransactionDeposited event instructing rollup nodes to include the transaction within the 12 hour sequencing window.

Limitations and Vulnerabilities

In the OP Stack forced inclusion has several weaknesses:

1. Constrained Gas. Base, and all OP Stack rollups, limit the amount of L2 gas available to forced transactions. Base limits deposit transactions to buying 20M L2 gas units every L1 block with a target of 2M L2 gas per L2 block. Base’s current overall gas target per L1 block is ~300M. In a forced inclusion-only scenario, Base's per-L1 block gas target drops from 300M gas to 2M gas—a reduction of more than 99%. While not a complete stoppage, this could constitute a functional stoppage if many Base users race to exit simultaneously.
2. The Handoff Problem. The sequencer retains significant control by determining when forced transactions are included and which transactions appear before and after them. This gives the sequencer great power to interfere with user goals when they involve contentious state, even when user transactions cannot be literally censored.
3. Contract Upgrade Risk. Most critically, forced inclusion itself can be disabled through contract upgrades. While it protects against a hostile sequencer, forced inclusion offers no protection against hostile admins who can upgrade the OptimismPortal2 contract.

On Base, such upgrades require approval of the following multisig wallets which can be accomplished with as few as 15 signatures:

• Base Security Council (threshold: 7 / 10)
• Base Multisig 2 (3 / 6)
• OpFoundationOperationsSafe (5 / 7)

Total distinct keys: 7 + 3 + 5 = 15.

This vulnerability isn’t purely theoretical. In March 2024, Blast used a contract upgrade to block three addresses from force-including transactions, preventing them from withdrawing allegedly stolen funds.

Making Base and the OP Stack unstoppable would be technically straightforward: simply remove the ability to disable forced inclusion or change its resource metering parameters (such as the 20M per-L1 block gas purchase limit) via contract upgrade.

However, this isn't the path Base and the rest of the Ethereum rollup community have chosen. Instead, they've opted to mitigate shutdown risk via exit window rather than eliminate it entirely.

Stage 2 and Exit Windows

The Ethereum community's answer to rollup upgrade risks is the Stages Framework which mandates that rollups eventually implement 30-day exit windows before significant protocol changes in lieu of forbidding forced shutdown and censorship entirely.

This approach fundamentally differs from Ethereum L1's security model: while Ethereum cannot be stopped by any group, Stage 2 rollups merely promise users time to exit before forced changes. We argue that this gap is not purely theoretical and its practical ramifications manifest in three weaknesses:

1. Prohibitive Exit Costs. Mass exits during a 30-day window could impose enormous costs on users, creating an asymmetric advantage for attackers who can trigger such exits with minimal expense.
2. Application-Level Constraints. Many assets are locked in smart contracts with their own withdrawal schedules and restrictions, which may not align with the exit window. A user with tokens in a 90-day vesting contract, for instance, could find their exit window entirely blocked.
3. L2-Native Asset Complexity. While bridged assets have clear L1 equivalents, L2-native assets face fundamental challenges during forced exits. Converting complex L2 financial positions to L1 representations involves technical and social coordination problems that may be impossible to solve within a fixed timeframe.

These limitations suggest that exit windows, while better than nothing, fall far short of providing L1-equivalent security.

The Problem With Exit Windows

Withdrawing Bridged Assets

Consider first the cost of withdrawing bridged assets in a mass exit scenario. In a recent post, Vitalik Buterin modeled such a scenario. Applying his assumptions, we arrive at the following cost model for exiting:

• Cost per asset withdrawal per user: $30 (assuming 120k L1 gas per withdrawal, 100 gwei L1 gas price, 36M L1 gas limit, and a $2,500 ETH price)
• Potential total cost to the community: $900 million (assuming 3M users, each holding 10 assets)

Even under ideal conditions, users collectively spend nearly a billion dollars to secure their assets. Meanwhile, an attacker pays only a small Ethereum transaction fee to initiate the hostile upgrade. This asymmetry enables two attack vectors:

• Pure Disruption: Force a shutdown with minimal cost.
• Governance “Tax”: Demand a fee lower than the user’s exit cost, effectively extorting them.

Increasing Ethereum’s gas limit could lower individual withdrawal costs, but does not solve the fundamental cost imbalance—especially given ongoing demand for L1 blockspace.

Contract Lockups: Timing Misalignments

A more fundamental problem facing the 30-day exit window’s effectiveness is that most assets aren't sitting idle in user wallets but are actively deployed in smart contracts, some of which have their own withdrawal constraints. These contract-level restrictions create additional “withdrawal windows” that must align with the protocol's exit window.

Consider a vesting contract that releases tokens weekly. In a hostile governance upgrade, users must exit during the overlap of the 30-day exit window and their contract’s withdrawal schedule. With weekly vesting, the effective window might shrink to about 23 days; quarterly vesting could eliminate it entirely.

Perpetual futures illustrate a more challenging case. These derivatives have no expiration and rely on continuous margin checks and funding payments tied to real-time market conditions. Unlike halted vesting contracts perpetual markets cannot be fairly “paused and resumed,” because ownership of assets depends on real-time user actions and market fluctuations, neither of which can be accurately reconstructed retroactively.

Users must either avoid dynamic DeFi protocols—negating a core benefit of rollups—or attempt to migrate entire DeFi states back to Ethereum L1 under time pressure. That migration is both costly and complex, involving addresses, contract state, and execution context changes.

“Withdrawing” Native Assets

When you withdraw an L1-bridged asset from an L2, the L1 contract already holds that asset in escrow. The rollup provides trust-minimized proof of ownership, and the L1 contract can transfer the asset back to its rightful owner. This is an unambiguous “withdrawal.”

However, L2-native assets (assets minted on the L2) have no L1 equivalent escrowed. Even if the L2 supplies trust-minimized state data showing “Alice owns 100 tokens,” there’s no single “correct” way to represent those tokens on the L1².

However, a token’s value hinges on its behavior and internal logic, not merely the mapping of who owns how many tokens. Therefore, for a true L2-issued asset “withdrawal,” we need an L1 representation of its behavior in addition to its internal state.

Challenges Representing L2-Issued Assets on the L1

L2s have fundamentally different execution environments with unique chain IDs, block times, gas limits, and opcode behavior. These contextual differences, accessible to L2 contracts via EVM opcodes, make direct L1 replication impossible.

Another source of indeterminacy arises when an L2-issued asset’s internal state references specific L2 contract addresses. The same address on L1 might point to a blank account or an unrelated contract with different logic. If an L2 token internally references (for example) an L2 liquidity pool contract at address X, a naive attempt to “port” that balance to L1 could render those tokens unusable if X is a different contract (or a blank account) on the L1³.

Finally, there’s the practical issue of cost. Earlier, we estimated withdrawal costs per user, per asset. But lower L2 transaction fees encourage richer interactions and far more state than just asset balances. Migrating this larger state back to L1’s limited and expensive storage quickly becomes prohibitively costly, especially in a fixed time window.

Social Consensus & L2 Asset Dependencies

L2‐native tokens are often integrated into DeFi via:

• Collateral in Lending Protocols
• Wrapped Derivatives
• Liquidity Pairs with L1 Assets

Each integration adds another stakeholder whose agreement is required for any L1 token representation to be accepted. For example, a lending protocol cannot accept a new version of collateral without agreement from its borrowers and lenders.

The complexity introduced by these dependencies creates systemic risk. If stakeholders fail to reach consensus on a new L1 representation:

• The L2 asset may become effectively worthless due to uncertainty about its canonical representation
• This can trigger liquidations in protocols using it as collateral
• Liquidations may impact other assets paired with or dependent on the L2 token
• The effects can cascade through the broader DeFi ecosystem, potentially affecting even protocols with no direct exposure

A hostile governance upgrade provides an ideal trigger for such a cascade. As Vitalik Buterin notes:

If an L2 goes through a hostile governance upgrade, then an ERC20 launched on that L2 could start issuing an unlimited number of new tokens, and there would be no way to stop those tokens from leaking into the rest of the ecosystem.

Issuing Assets on L1: A Workaround?

Vitalik proposes issuing assets on L1⁴ and bridging them to L2 to preserve a canonical withdrawal path, but this faces significant limitations. Many tokens have already been issued on L2s, and migrating them would require complex redeployment and user coordination. More fundamentally, even L1-issued assets become exposed to L2 governance risk the moment they interact with any L2-native component in DeFi protocols.

L2-Native Asset Adoption

Hayden Adams, creator of the Uniswap protocol and Unichain rollup, said this in response to Vitalik’s suggestion:

You can issue an asset on L2, and the L2 is still using L1 for [data availability] + execution proofs, and the asset can still be withdrawn to L1 if the L2 fails

Many / most assets should and will be issued on L2 bc it's expensive to do on L1 and there are going to be many assets

Let's not create the incorrect narrative that L2 native assets are bad for ethereum when they're actually critical for ethereum to succeed on its current roadmap

While we've shown that his claim about L2 assets being withdrawable to L1 holds only in limited cases, his broader point stands: economic forces will drive most new assets to launch directly on L2s, where deployment and transaction costs are dramatically lower.

Achieving Unstoppability

Exit windows impose substantial burdens on users. To protect themselves from hostile upgrades, users must:

• Monitor governance actions and be prepared to withdraw on short notice
• Accept losing assets whose withdrawal costs exceed their value
• Avoid contracts with time-locked assets that might restrict withdrawals
• Issue assets on L1, or accept heightened risks with L2-native assets

Enter Unstoppable Rollups. But how to build one? Recall our definition of rollup stoppage:

• Block production ceases entirely
• An account or class of transactions is censored for a prolonged period
• The gas token is manipulated so that normal users cannot purchase block space

All three failure modes trace back to admin keys that control

• Transaction inclusion (sequencer & forced-tx portal)
• Gas-token issuance (upgradeable bridge)

Facet eliminates this control with two high-level changes:

• Immutable inbox: forced inclusion can never be switched off.
• Native-issued gas token: pricing block space without depending on an upgradeable bridge.

The Facet Approach

Admin-Free Sequencing

To achieve admin-free sequencing, two requirements must be met:

1. Make forced inclusion impossible to turn off
2. Give forced transactions a reasonable share of L2 blockspace

Facet achieves (1) by making the forced transaction “inbox” a permissionless EOA address instead of a smart contract and (2) by enabling all user transactions to have an equal share of L2 blockspace in an “anything goes” based sequencing model.

Here’s how it works. To create a Facet transaction, users embed the RLP-encoded Facet transaction payload into an ordinary Ethereum transaction sent to the Facet inbox address (0x00000000000000000000000000000000000face7):

L1 smart contracts can also create Facet transactions by emitting events with topic 0x00000000000000000000000000000000000000000000000000000face7 and including the same RLP-encoded transaction in the event’s data field.

Note: Currently, each Facet transaction requires its own L1 transaction, as batch submissions are not yet supported. In essence, today all Facet transactions are 'force included'"

Facet State Derivation

Facet state is derived from L1 history using the OP Stack paradigm:

1. facet-node (inspired by op-node) fetches transactions sent to the inboxes, validates them, assembles Facet blocks, and sends them to facet-geth via the engine API
2. facet-geth (fork of op-geth): executes blocks, stores Facet state, responds to user queries.

Facet node is also responsible for managing Facet’s native gas token, Facet Compute Token.

Facet’s Gas Mechanism

Typical rollups use bridged Ether as their gas token. Users deposit Ether into a specific L1 smart contract ( the rollup’s “canonical bridge”) which emits a corresponding event and rollup nodes know that such events emitted by that contract should trigger issuance of the rollup’s gas token.

Rollup canonical bridges are almost universally admin-upgradeable. Under this arrangement, bridge admins have the ability to withdraw all funds from the L1 bridge, leaving the gas token unbacked. Equally concerning, but less often discussed, are admin ability to:

1. Halt deposits, making it impossible for new users to buy gas
2. Issue billions of ETH to admin accounts and use it to raise gas prices to a level such that no one else can afford to buy gas.

What is the solution? One approach is to preserve the bridged gas token but remove admin control, for example by making the canonical bridge immutable. This faces two major challenges:

1. Dynamic Updates: Bridges rely on being able to validate claims about L2 state in order to finalize withdrawals. When the rules of the L2 change as in a fork, the bridge must “repoint” to the new rules, which requires admin intervention. Native rollups have been raised as a solution here as they could give L2 bridges a way to "automatically update," but they are still an early-stage concept.
2. Protective Admin Functions: Admins can protect users as well. Forfeiting admin control entirely might “go too far,” creating an Unstoppable Rollup but placing user funds at risk in the case of a proof system bug. Users need a mechanism to enlist admin protection over the assets in the bridge without also giving such admins the ability to stop the entire L2 chain.

Therefore, Facet is designed without a canonical bridge and its gas token is issued natively (i.e., it has no L1 representation).

How Facet Compute Token (FCT) Works

Instead of minting a gas token in proportion to how much ETH users deposit in an (upgradeable) L1 bridge, Facet’s gas token (FCT) is issued in proportion to how much gas users spend (and therefore how much ETH users burn) creating Facet transactions. Here’s how:

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.

L2 to L1 Messaging on Facet

All EOAs and L1 smart contracts can permissionlessly create Facet transactions and thereby send L1 to L2 messages. How does the reverse process work? Facet borrows heavily from the OP Stack:

1. L2 to L1 messages are initiated via a call to the L2ToL1MessagePasser L2 predeploy, just as they would on other OP Stack rollups.
2. The storage root of this contract is posted to an L1 contract which validates it using ZK fault proofs.
3. Once validated, users can prove their message exists in the L2ToL1MessagePasser’s storage and pass it to its intended L1 recipient.

Facet ZK Fault Proofs

Traditionally rollup proof systems have come in two flavors, each with advantages and disadvantages:

• Interactive Fault Proofs
• Pros: Free unless there’s a challenge
• Cons: Bonds escalate with each round of the game
• ZK Proofs
• Pros: No bonds, no multi-round games
• Cons: You pay to prove everything, even when nobody disputes it.

Both options share the same “chicken and egg” problem: a chain needs significant usage to justify the capital requirements to run the proof system, but a chain needs an operational proof system to gain significant usage. Fortunately there is a third option that offers the best of both worlds: ZK Fault Proofs:

• Pay to prove only when there is a dispute. The normal / happy case is cheap.
• Single transaction resolution. A single validity proof settles the dispute—no bond escalations.

The flow is fundamentally the same as ordinary interactive fault proofs: a proposer proposes a state root and challengers can dispute it. The difference is that each challenge is resolved with a single proof instead of a multi-step game.

Facet’s ZK fault proofs are based on the OP Succinct Lite project, with a few modifications.

Fault Proof Components

Like all ZK proofs, Facet fault proofs are claims about the result of certain computations. In Facet’s case, the programs being proven are created by:

1. Porting Facet's state transition function (STF) to rust (via Kona and REVM)
2. Compiled our STF into SP1 ELF binaries.
3. Generated cryptographic commitments from these ELFs that contracts can use to validate proofs

Our reference implementation uses a single immutable L1 smart contract to handle all functionality Rollup.sol. It:

• Stores the anchor root and three critical constants:
• AGG_VKEY: Verification key for the aggregation program
• RANGE_VKEY_COMMITMENT: Commitment to Facet's state transition program
• ROLLUP_CONFIG_HASH: Hash of Facet's chain configuration
• Accepts proposals/challenges
• Verifies ZK proofs against these immutable commitments
• Pays out bonds

Two off-chain workers interact with this contract:

• proposer.rs: Computes roots every N L2 blocks, submits proposals, and generates proofs when challenged
• challenger.rs: Re-derives each proposed root using the same STF; if mismatched, files a challenge

The lifecycle:

1. Propose: A whitelisted proposer chosen by the Rollup.sol deployer (or anyone after 2 weeks of inactivity) posts (root, l2BlockNumber) + proposal bond
2. Challenge: Anyone may stake a challenger bond and assert the root is wrong
3. Prove: A prover generates a ZK proof by:
• Re-executing Facet transactions from L1 using the Kona/REVM implementation
• Proving correct execution inside SP1's zkVM
• The proof is only valid if generated by the exact ELF whose verification key is stored in the contract
4. Resolve: Contract verifies the proof; winner gets both bonds

Fault Proof Design Principles

1. Simplicity: entire proof system fits into one L1 contract.
2. Unstoppability: Rollup.sol is immutable. No admin can compromise the system. To upgrade or fork Facet, one must redeploy a new Rollup.sol with updated ZK parameters.
3. No “Training Wheels”: No “guardian” can override the proof system, even if there is a zero-day bug. This is the flipside of unstoppability: to protect against hostile admins we must also disempower benevolent admins.

Note that “training wheels” here refers only to training wheels at the protocol level. That is, admin controls that affect all applications and users on Facet. Facet applications can still implement training wheels on an opt-in basis.

For example, a bridge contract could implement a delay between Rollup.sol accepting a state root and allowing withdrawals:

State root accepted → Delay period → Admin can blacklist → Withdrawals enabled

During the delay, an admin can intervene if they detect issues. End users could then decide whether to use such a bridge or to instead use a different bridge with different training wheels or none at all.

A more scalable alternative might be “Guardian as a Service.” Instead of each bridge implementing its own safety logic, they could point at a shared “guardian service” contract which would sit between the bridge and Rollup.sol. Then select admins could standardize delay and blacklisting functionality across multiple bridges.

In the limit case, such a service could become just as dominant as the protocol-level training wheels on typical rollups, with the important difference being that it would be opt-in and subject to market competition.

Finally, note that there is nothing “special” about any instance of Rollup.sol, including whatever happens to be deployed by the creators of the Facet protocol. All Rollup.sol instances that prove the execution of the same program will work equally well for proving Facet state. Users are free to customize their own instance of Rollup.sol and add whatever training wheels they desire.

To summarize:

• Traditional rollups: Protocol-level training wheels affect everyone
• All users must trust the same guardians
• No way to opt out of guardian oversight
• Single point of failure for the entire network
• Facet's approach: Application-level choice
• Each app decides its own safety/speed tradeoff
• Users can choose apps based on their guardian preferences
• Core protocol remains trustless and unstoppable

Bridging on Facet

On Facet, bridges are apps. Anyone can create a bridge, all bridges compete on equal footing (no “canonical” bridge), and, most importantly, no one has to use any bridge to use Facet because obtaining FCT doesn’t require bridging.

Bridges typically have two components:

1. An L1 smart contract that escrows assets and sends messages to its L2 counterpart using events with the Facet event topic.
2. An L2 smart contract that mints an L2 asset in response to the L1 contract’s message that a deposit has taken place and, when a user withdraws, burns the asset and communicates that fact to the L1 bridge via the L2ToL1MessagePasser predeploy + proofs.

Because Facet does not have a bridged gas token, all Facet bridges deal in assets that smart contracts can create, such as ERC-20s, ERC-721s and so forth.

The fact that all bridges are on equal footing on Facet means that there is no “official” representation of any L1 asset on Facet. For example, two people could independently create Facet bridges for USDC. In such a case there would be two L1 contracts that accept USDC deposits and two L2 contracts that issue bridged USDC at two different contract addresses.

Users would need to keep track of which “bridged USDC” they held as it would not be possible to withdraw one bridge’s USDC on the other.

This is analogous to how stablecoins work on the L1. If you hold USDC you cannot redeem it for USD through Tether. You first need to swap to USDT. It is also possible to create a token with the name “USDC” that’s backed by an L1 escrow on any rollup stack that enables bi-directional message passing, for example on the OP Stack.

Which L2 representation dominates will be the result of competition and user choice.

Conclusion

On an Unstoppable Rollup developers can build applications knowing that protocol administrators cannot shut them down. When users choose applications on Facet, they don’t have to worry that the underlying protocol will block their transactions or freeze their assets. The protocol layer provides unconditional guarantees about liveness and inclusion.

This doesn't mean users are automatically safe—applications themselves may still have admin keys that could freeze funds or censor users. The difference is that on Facet, users have a choice. They can select applications based on their security models, choosing between different trust assumptions and tradeoffs. Some may prefer applications with training wheels for additional safety; others may opt for fully immutable contracts.

On stoppable rollups, this choice doesn't exist. No matter how carefully an application is designed, no matter how decentralized its governance, protocol administrators retain the ultimate kill switch: the ability to halt all applications simultaneously.

Consider centralized assets like USDC: even on an unstoppable protocol, Circle retains the ability to blacklist addresses. This limitation exists on Ethereum L1 as well. However, on Facet (as on Ethereum), users can choose whether to interact with USDC or to use alternatives without such controls. On a stoppable rollup, even decentralized alternatives can be shut down by protocol administrators.

Being unstoppable at the protocol level is therefore not a complete solution—it's a necessary foundation. It ensures that the marketplace of applications can exist, that innovation can flourish, and most importantly, that users retain the ability to choose based on their own risk tolerances.