• 🟢 Green must match one of the following conditions:
• Users can contest a dispute in the final state with a counterparty and claim their assets on the L1
• Bitcoin can verify changes to the layer’s state directly in Script when users’ offchain balances are updated, permitting withdrawals when users want to leave the system
• The bridge is managed by an alternative consensus mechanism where anyone can challenge malicious withdrawal requests. Operators can be rotated in the event of liveness failures.


• 🟡 Yellow must match one of the following conditions:
• The bridge is managed by an alternative consensus mechanism that is financially incentivized not to steal
• The bridge is managed by an alternative consensus mechanism where anyone can challenge malicious withdrawal requests
• We are currently considering a score where systems like the Spiderchain and tBTC v2 would be considered yellow


• 🔴 Red:
• The bridge is managed by at least 5 publicly known signers, who are external to the organization building the layer.


• 🛑 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 external, publicly known 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 by including it on bitcoin and the centralized validator cannot selectively censor. In layers with centralized block producers, they cannot selectively censor, the validator(s) would need to halt the entire system to censor users.


• 🟡 Yellow must match one of the following conditions:
• The validator (aka network operator) node software is open-source, anyone can become a validator in a (at least) minimally permissioned (e.g. proof of stake) way, and at least 5 externally, publicly known 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 externally, publicly known operators


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

• 🟢 Green must match one of the following conditions:
• Layer's consensus is constructed in a way that operators (including users in P2P network) must build on a state root, or state commitment, posted to bitcoin
• Layer transactions happen atomically and cannot reorg


• 🟡 Yellow must match one of the following conditions:
• Settlement guarantees come from a permissionless, alternative consensus network operated by at least 5 externally, publicly known operators


• 🔴 Red:
• Layer finality guarantees come from a federated system


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


• 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.