# Proposal for updated Bitcoin Layers risk framework
[Bitcoin Layers](https://www.bitcoinlayers.org/) currently has a risk assessment framework where scaling protocols are analyzed against four key aspects of their protocol. Each aspect is given a risk score, high, medium or low risk, after review. The scaling protocol will then receive a pie chart score, with the colors resembling its overall risk score.

*An example showing that Stacks received a high risk score related to unilateral exit.*

We are currently assessing protocols based on the following criteria:

- Unilateral exit
- Data availability
- Block production
- State validation (settlement)

Our [docs](https://bitcoin-layers.gitbook.io/bitcoin-layers) outline why we’ve chosen these areas.

## Current challenges
Some challenges we are currently facing with this framework are that 1) other aspects of the overall protocol assessment related to security and not included (e.g. alternative tokens) and 2) not all protocols are designed with the same goals in mind and have varying tradeoffs. For example, a rollup is inherently different from a payment channel protocol.

## Proposed solution
Saunter (from Alby) suggested that we create a more diverse framework that assigns weights to the specific risk questions. If a protocol does not meet a specific requirement, they would be deducted points off their total score relative to the weight of that question. I’m proposing a similar model, and believe it will help create a more granular framework for the Bitcoin Layers project.

### Starting point
Every protocol starts with a score of 100 points. For every category, there are a number of possible risk scenarios. If a protocol fits criteria related to a specific risk item, then the it would be deducted points based on the value of the specific category and scenario.

The potential overall influence from the scores could be:

- Unilateral exit: 45%
- Data availability: 15%
- Block production: 15%
- State validation: 15%
- Alternative token: 5%

The potential scoring mechanism could be:
#### Unilateral exit
- The protocol enables unilateral exit
- The protocol doesn’t enable unilateral exit, but has a two-way peg managed by an alternative, permissionless (see below) consensus mechanism - **deducted 20 points**
- The protocol doesn’t enable unilateral exit, but has an enshrined two way peg managed by a federation - **deducted 30 points**
- The protocol doesn’t enable unilateral exit, and has no protocol-level consensus mechanism securing its (or any) two-way peg - **deducted 45 points**
#### Data availability
- Self-hosted: User can store data related to L2 transactions locally
- Onchain: Data is stored on the Bitcoin and L2 writes state updates onto Bitcoin directly
- Offchain and Onchain: Data is primarily stored on another publicly available, decentralized network, and Bitcoin full nodes can access that data or users can run a full node - **deducted 8 points**
- Offchain DAC: State updates are stored via a centralized committee and Bitcoin full nodes, and users, cannot access that data - **deducted 15 points**
#### Block production
- N/A: L2 doesn’t produce blocks
- Decentralized block production + L1 escape hatch: If decentralized block production in the L2 fails, or your transaction is censored, you can submit your transaction to the L1 directly
- L1 escape hatch: If centralized block production in the L2 fails, or your transaction is censored, you can submit your transaction to the L1 directly. Users must wait for the L2 block producer to resume, or submit a L1 transaction to exit the L2, to access their funds. - **deducted 5 points**
- Permissionless block production: If permissionless block production in the L2 fails, a user’s transaction is censored, or a user cannot self-sequence, they are stuck in the L2 and cannot access funds or withdrawal - **deducted 8 points**
- Cannot access funds: If centralized block production in the L2 fails, or your transaction is censored, you are stuck in the L2 and cannot access funds or withdrawal - **deducted 15 points**
#### State validation (settlement)
- Onchain: Settlement happens on, or is enforced by, Bitcoin
- Offchain via client side validation: Settlement happens offchain via a CSV (or CSV-like) protocol (RGB, Sovereign rollup)
- Offchain via alternative consensus protocol: Settlement for the layer is finalized by offchain by a permissionless consensus protocol - **deducted 10 points**
- Offchain via committee: Settlement for the layer is finalized by participants in a permissioned, offchain consensus protocol/network - **deducted 15 points**
#### Alternative token
- Network can make progress w/o token or does not have a token
- Alternative token (non-BTC or BTC IOU) plays a role in permitting withdrawals and/or network is dependent on token - **deducted 5 points**

### Customization
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 granular point deductions based on how decentralized the network is. E.g. A network with 200 validators is presumably better than a network with 10, and we can customize the points system to highlight this.

Thus, the scores may show a more holistic representation of the overall risk related to these protocols versus our n/4 framework.
### Final risk score
The final score will be 100 subtracted by the amount of points the layer loses per category.

The protocol will then be placed within a risk category related to its score. An example of this is:

- 0-25 points = Very high risk
- 26-50 points = High risk
- 51-75 = Medium risk
- 76-100 = Low risk

### Next steps
The Bitcoin Layers project is assembling a research advisory board and will be working with them, and other researchers in the Bitcoin space, on assigning more detailed point deduction mechanisms to this framework. After this, we will present a formal write-up to gather feedback from our community and then move forward with updating our assessments with this updated framework in mind.
### Clarifying point(s)
We define permissionless as meaning anyone with sufficient capital and resources can participate in consensus, operating a node, block production, etc.