Framework
Bitcoin Layers Framework
The Bitcoin Layers risk assessment is broken down into four sections. They cover BTC Custody, Data Availability, Network Operators, and Finality Guarantees.

This assessment is not reflective of L2 or sidesystem security. It is not a security audit. It is an opinionated assessment covering the trust assumptions related to specific system.

Protocols are divided into three categories; bitcoin native, sidesystems, and alternative chains. For a project to be considered a bitcoin layer or sidesystem, they must meet our technical requirements listedΒ here.
BTC Custody
  • 🟒 Green must match one of the following conditions:
    • Users can unilaterally exit the protocol with a Bitcoin L1 transaction

  • 🟑 Yellow must match one of the following conditions:
    • The two-way peg is managed by an alternative consensus mechanism that is financially incentivized not to steal
    • The two-way peg is managed by a mechanism where anyone can become a watchtower to challenge malicious withdrawal requests

  • πŸ”΄ Red:
    • The the two-way peg is managed by at least 5 publicly known signers, who are external to the organization building the network.

  • πŸ›‘ Stop!
    • The two-way peg does not meet the requirements for Red.

  • Additional considerations:
    • If the custody mechanism is upgradeable, the score is analyzed based on the signers who can upgrade. We will assess timelocks when applicable.
    • If the protocol sees a user maintain custody, but does not support unilateral exits, the score is degraded to yellow.
    • Alternative blockchains, including those that qualify as sidesystems, have various pegs with bitcoin. We analyze each individually.
Data Availability
  • 🟒 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 and/or unilateral exit transactions

  • 🟑 Yellow must match one of the following conditions:
    • Data is made available by an alternative consensus protocol (that is not bitcoin) and the full node software is open-source

  • πŸ”΄ 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.

Network Operators
  • 🟒 Green must match one of the following conditions:
    • Users can transact in a peer-to-peer manner.

  • 🟑 Yellow must match one of the following conditions:
    • The network operator node software is open-source, anyone can become a validator in a (at least) minimally permissioned (e.g. proof of stake) way
    • The layer is merge-mined with bitcoin and secured by greater than 50% of hashrate

  • πŸ”΄ Red:
    • The layer is operated by an operator set of at least 5 externally, publicly known operators

  • πŸ›‘ Stop!
    • Doesn’t meet the criteria for any other rating in this section
  • Additional considerations:
    • We will assess sidesystem network's that enable self-sequencing, in the context of bitcoin, when applicable.

Finality Guarantees
  • 🟒 Green must match one of the following conditions:
    • The network finalizes its state based on data posted to bitcoin
    • Users maintain, a periodic, provable assurance that they are the only party that can spend their funds

  • 🟑 Yellow must match one of the following conditions:
    • Transaction finality is provided by an alternative consensus network

  • πŸ”΄ Red:
    • Finality guarantees come from a federated system

  • πŸ›‘ Stop!
    • None of the requirements for Red are met.

  • Additional considerations:
    • Single-sequenced networks that post state roots to bitcoin, but who's bridge programs do not finalized based on this state, are degraded to yellow.
Summary

Individual categories are analyzed in isolation of each other. A poor score in one category does not affect a score in another category.


This risk assessment is a living document and is subject to change.


If you have comments on this framework, please consider joining our community chat to discuss.