• 🟢 Green must match one of the following conditions:
• Users can unilaterally exit with an L1 transaction and have the ability to challenge a faulty operator
• Anyone can ensure the integrity of a bridge with a fault proof


• 🟡 Yellow must match one of the following conditions:
• The two-way peg is overcollateralized with a minimum of 150% of value locked in the form of a slashable asset
• The layer relies on a federated operator and verifier set, where one entity needs to remain honest to ensure the integrity of the bridge. There needs to be at least 6 signers who are publicly known entities.


• 🔴 Red:
• The two-way peg is managed by a (likely federated) group of signers whose identities are known to the public and/or core development organizations. There need to be at least 8 publicly known signers participating in securing the two-way peg. The signing mechanism for the bitcoin wallet must also be publicly acknowledged.


• 🛑 Stop!
• The two-way peg does not meet the requirements for Red.


• Additional considerations:
• layers that settle to a parent blockchain must consider their exit window. For rollups, we follow L2Beat’s suggestions on exit windows. These exit window scores overrule any other score related to the two-way peg. For example: If a rollup-style layer leverages tBTC (a yellow or red score) to natively mint bitcoin-backed tokens, but has an immediately upgradeable contract, then the layer will receive a “Stop!” score in the assessment.
• Due to complexities related to federated set ups, we will additionally highlight more granular trust assumptions for federated two-way pegs in a subsection of the review. In this upcoming framework, we will outline how a federated peg can be upgraded to yellow if it meets a certain threshold of requirements.
• Additional situations can be added to this framework for edge cases. For example, users of Statechains can unilaterally exit with a Bitcoin L1 transaction, but an operator can steal funds by colluding with the past owner, and users cannot submit a challenge transaction.

• 🟢 Green must match one of the following conditions:
• All data needed to reconstruct the layer’s state lives on the Bitcoin L1 and is accessible via full nodes
• Data is self hosted by default and users are required to store data relative to their own state


• 🟡 Yellow must match one of the following conditions:
• Data is made available by an alternative consensus protocol (that is not bitcoin) node operate set and the full node software is open-source
• Data is stored via an offchain committee or consensus protocol, where validators stake slashable collateral greater than value locked in the layer and DA attestations are backed by this economic security


• 🔴 Red:
• Data is stored via an offchain committee with at least 5 actors attesting that the data is available.


• 🛑 Stop!
• None of the requirements for Red are met.

• 🟢 Green must match one of the following conditions:
• Users can self-sequence their own transactions and the network fails if the sequencer does not publish blocks that include forced included transactions. Sequencer cannot selectively censor.


• 🟡 Yellow must match one of the following conditions:
• The validator node software is open-source, anyone can become a validator in a permissionless or minimally permissioned (e.g. proof of stake) way, and 21 or more validators participate in proposing and signing blocks
• The layer is merge-mined with Bitcoin and secured by greater than 50% of hashrate


• 🔴 Red:
• The layer is operated by a validator set of at least 5 publicly known, independent operators
• Anyone can ensure the integrity of a bridge with a fault proof


• 🛑 Stop!
• Doesn’t meet the criteria for any other rating in this section

• 🟢 Green must match one of the following conditions:
• Settlement happens onchain and is immediately enforced by Bitcoin Script
• Settlement happens onchain optimistically where anyone can challenge invalid state transitions during a given time period with a Bitcoin L1 transaction


• 🟡 Yellow must match one of the following conditions:
• Settlement guarantees come from a permissionless, alternative consensus network, and the layer inherits reorg resistance from Bitcoin


• 🔴 Red:
• Requirements for yellow are not met


• 🛑 Stop!
• Layer does not have an active state validation mechanism in place. Namely rollups that do not have fault proofs in place.


• Additional considerations:
• If all transactions are finalized offchain, and the sidesystem’s initiation and closure transactions are finalized by the bitcoin L1, but there is no challenge mechanism to dispute an operator, then it is likely a yellow score.

• In addition to performing this assessment, we additionally have a “Bitcoin security” section where we cover:
• If the protocol inherits security from bitcoin
• If the protocol needs an alternative token to function
• If the protocol introduces MEV to bitcoin
• If the protocol contributes to bitcoin’s security budget
• We also cover areas related to various technologies used, and potential use cases.

Some context related to risks with certain protocols may not be covered directly in our risk assessment. This can be covered in an 'additional considerations' section that outlines relevant information. An example of this could be acknowledging that the majority of Lightning Network adoption is by way of custodial providers.

If we cannot verify a specific category in this assessment (e.g. some aspect of the code is not source-viewable), then we automatically assign it a "Stop" score. If the mainnet node implementation is not source-viewable, we do not include the project on the site.

This framework can be easier to customize and provide more nuance given the number of scaling solutions that are present in Bitcoin today. For example, related to block production/network operators, we can add even more scoring mechanisms based on how decentralized the network is. E.g. A network with 200 validators is better than a network with 10, and we can customize the assessment to highlight this.

This risk assessment is an initial starting point to analyze Bitcoin scaling protocols. It is a living document and is subject to change.

Bitcoin does not have a unified scaling roadmap. There are tradeoffs with every protocol being implemented to support Bitcoin scaling. This framework hopes to capture some of the nuance related to the various designs being proposed.

If you have comments on this framework, please consider joining our community chat to discuss. You can also add comments or feedback here.