# content plans for b^2 and unirouter

### background material
1. b^2's [intro on its b^2 Hub](https://medium.com/@bsquarednetwork/announcing-b%C2%B2-hub-unlock-the-bitcoin-da-layer-0d16016e801b), focus on parts that mentioned "Challengers (Validators)"
2. our [integration proposal](https://docs.google.com/document/d/1Gop2-1A9_x_MwA9jx_119WvMyUy4RhhdCj_UN4Jdy3Q/edit?usp=sharing) (and yes it's written by gpt)
3. [a 'fluffy' doc](https://docs.bsquared.network/architecture/da_layer/b2_nodes) on b^2 nodes

### goal
1 ~ 2 articles detailing how we can work with b^2 to have a staking protocol for the validators OR a liquid staking network on top of it

### strategy
1. b^2's doc is not concrete either, so our content won't need to have very specific technical details. but an architecture graph similar to b^2 would be great. I can help draft something like that
2. our talking points can be focused on:
- bitcoin staking can help b^2 achieve better network security (e.g. those challengers need to have stakes to access the network), we can work together with b^2 to design and implement such mechanism. for example, all the challengers will be asked to stake their bridged BTC (b^2 BTC) before taking the challenger roles, and once the protocol finds out they are behaving maliciously, those BTC can be slashed. alternatively, b^2 can ask challengers to stake their mainnet BTC before joining as challengers, but that would be harder to implement
- once a bitcoin staking mechanism is in place, we can build on top of it a liquid staking platform, similar to Lido on eth. our architecture can also be similar to them, so we can use some wording [like in this doc](https://hackmd.io/@0xildefonso/babylon-lsd-unirouter#Liquid-Staking-Demystified-Ethereum-and-Lido-as-Paradigms), talking about the relationship between stakers (retail users), node operators (unirouter-specific roles) and validators (b^2 challengers)
- value props of unirouter: unleash the liquidity of staked bitcoin, help secure BTC L2, blah blah blah

### bitcoin staking primer

1. for now, there is no universal consensus on what bitcoin staking should mean, unlike ethereum where after "the merge" it became the common knowledge. the most recognized definition is probably what [Babylon chain](https://babylonchain.io/) has been promoting: use bitcoin as collateral to secure other protocols (layer 1s, oracles, cross-chain bridges etc.) in a decentralized fashion, where the stakers can either 1) rececive rewards for the securing work, or 2) get slashed for malicious behavior. babylon proposed a very detailed technical solution to achieve ~80% of that goal, which is detailed in [this explainer doc](https://hackmd.io/@0xildefonso/babylon-lsd-unirouter#Babylon-Bitcoin-Staking-Redefined) together with this workflow diagram
2. every other project talking about bitcoin staking may mean totally different things. for example, [bouncebit says bitcoin staking is essentially the same as locking up the coins for yields through centralized custody](https://twitter.com/bounce_bit/status/1754798210869285300). so every bitcoin layer 2 may have different definitions for bitcoin staking, and our goal is to find out if a project needs bitcoin staking or not, and if yes, convince them we can help build the protocol itself, or build a liquid staking layer on top of it
3. back to b^2's case. for now they don't have a full picture of where to use bitcoin staking. so the next section, I'll propose a solution to enhance their network security leveraging bitcoin staking

### bitcoin staking for b^2

in the first section of this doc, the architecture diagram shows a role in b^2 called 'challengers' in their challenge platform, whose job is to 1) verify the submitted commitment, 2)

~~to be continued~~

b2 has [a relatively new article](https://medium.com/@bsquarednetwork/b%C2%B2-network-pioneering-the-modularization-of-the-btc-ecosystem-94819b946439) out about its modular design, we can piggyback on its hype and elaborate more on **b2 hub** parts:

1. we can intro a bit about modular design of block chains and why it's important, and explain more about data availability
2. then we dive into its b2 hub validators, where, from my discussion with them, has the following preliminary design choices (wording can be slightly vague):
- b2 hub validators will have to stake their b2 tokens to participate
- but they are also thinking about requiring those validators to put some bridged btc (on b2 L2) as stakes, slashable for malicious behavior
3. what we can do for them is a) integrate into their b2 hub validator protocol design; b) built a LSD on top of their btc staking. we can focus on some design aspects, as design questions, saying we are closely working with b2 team to come up with some answers, including
- how to accrue rewards for LSD of bridge btc? note those validators are likely to receive b2 tokens for their jobs, should we have a dex pool to convert those b2 tokens to accrue value for LSD token holders?
- how to organize node operators (as in Lido) to manage the validation work for DA? what are typical requirements for those validators?