Trendaavat aiheet
#
Bonk Eco continues to show strength amid $USELESS rally
#
Pump.fun to raise $1B token sale, traders speculating on airdrop
#
Boop.Fun leading the way with a new launchpad on Solana.
bitcoin rollups don't have escape hatches
i don't map these things one to one, because CR relative to the DA layer, ethereum wins

10.1.2025
Can upcoming bitcoin rollups meet @l2beat's Stage 2 requirements?
The tl;dr is almost. But to meet all requirements, you'd need something like OP_CAT.
Bitcoin rollups can have 1-of-N trust assumptions related to their bridge. But there’s some nuance to this. There’s two things you trust:
- Operators: You trust 1-of-N operators to process withdrawals and not freeze the bridge
- Verifiers: You trust 1-of-N, N being anyone, to secure the bridge
In the proposed implementations of rollups, withdrawals are processed by permissioned operators. Operators of the bridge front liquidity to users to satisfy withdrawal requests and then reimburse themselves from the bridge. While not incredibly efficient, this could work.
Now, stages. There are a number of requirements for a rollup to be “Stage 2” per @l2beat’s framework. Let’s see if a bitcoin rollup can meet them:
Bitcoin rollups can meet all of L2Beat’s stage 0 requirements. You can use bitcoin for DA, post state roots there, and people can reconstruct that state of the rollup based on this data.
Stage 1 is where it starts to get tricky. Bitcoin rollups can meet all requirements… except:
“Can the users exit without the operator’s coordination?”
The system should be designed so that user withdrawals cannot be blocked by the rollup operators. The rollup must implement mechanisms that allow users to exit independently, ensuring they can always access and control their assets.
Users can bypass the rollup operators theoretically (we haven’t seen it yet, so I’m not entirely sure how it’d work). But, they can’t bypass bridge operators if all of the bridge operators are offline. Therefore, the condition that users “can always access and control their assets” is not met.
This trend continues in Stage 2.
As we mentioned earlier, these rollups can have permissionless fraud proofs. Anyone can ensure the integrity of the bridge. And, they can likely have a mechanism to bypass rollup operators in the event that an unwanted upgrade is implemented.
“…This ample time frame allows users to react to significant changes in the system that they may not agree with and withdraw their assets if needed.”
But, requirements related to permissionless withdrawals cannot be met because users trust at least 1 operator to fulfill withdrawal requests.
So, to clear things up:
- Bitcoin rollups are possible
- They can have permissionless fraud proofs to secure the bridge with a 1-of-N trust assumption
- Instead of relying on a 2/3s federation to process withdrawals, you can rely on just 1-of-N operators
- This is not the same liveness (exit) assumption as optimistic rollups in ethereum. The security assumption is similar
A bitcoin rollup, with a Strata or Clementine-style bridge, can meet all of L2Beat’s requirements except those that require permissionless exit. While users may be able to bypass rollup operators, they must trust that 1-of-N bridge operators will fulfill withdrawal requests.
But, if you have something like OP_CAT, you can construct state-carrying spend conditions and onchain verifiers. This enables a bridge program to unlock funds if certain conditions are met. Like verifying a SNARK proof attesting to the updated state of the rollup, or a fraud proof challenge period passing.
So if additional opcodes are added, then bitcoin rollups could meet requirements related to permissionless exit and be a Stage 2 rollup.
Hope this clears up some confusion!
even if a user could self-propose an exit, they trust a bridge operator to honor it
i don't say "no escape hatch" as a way to shit on bitcoin rollups, i say it so we know, immediately, it is not a 1:1 comparison
bitcoin rollups enable bridge operators to supply liquidity into emerging bitcoin markets where they only trust themselves to be honest. this further extends onto users only needing to trust 1 operator versus a majority.
does it completely work like this in practice? no, there's other considerations (i.e. security councils). is it worth building and seeing if this premise delivers a competitive advantage? ofc.
2,31K
Johtavat
Rankkaus
Suosikit