Some thoughts on Bitcoin Staking
Thanks to Red Sheehan and Veronika Kütt for reading the draft. Double thanks to Veronika for drafting our initial review on Babylon (not posted yet). I took a lot of stuff from that document and used it here. Basically anything italicized.
We’ve been thinking a lot about bitcoin staking recently.
Babylon has been on our minds for a minute. I (Janusz) first heard of the project while I was still working at Espresso. The timestamping protocol seemed like a cool way to add extra some security to Cosmos chains. Since then, I haven’t really thought of it much.
A friend of the project told us a lot of interest is occurring in bitcoin LST tokens, all building on top of Babylon. We were kind of intrigued, and decided to take a look.
To say the least… we were, or I was at least, surprised.
Tl;dr on all of it
- Bitcoin staking isn’t live yet, deposit scripts are
- The supply side for staked BTC has been established with over 30k BTC (20k+ from Babylon). The demand side is yet to be seen
- Slashing can (eventually) be enforced on the L1
- Covenants make bitcoin staking better
- LSTs aren’t really LSTs because staking isn’t live
- Most (all?) LSTs are operated by a custodian. Pinky promise to get your (wrapped) bitcoin back
- Like most things this season, we’re early. Bitcoin Layers is tracking it
Babylon
Bitcoin staking is being driven forward by Babylon. The Babylon protocol will be a Cosmos SDK chain (meaning a Proof-of-Stake blockchain) that creates a marketplace for bitcoin staking. The staked bitcoin is remotely staked; a user will lock their funds in a staking vault on the bitcoin L1, assign it to a finality provider, and then the finality provider within the Babylon protocol will do its magic 🪄
Users could, in theory, become finality providers and self-assign BTC stake. However, becoming a finality provider on Babylon is currently permissioned.
Bitcoin staking scripts
Bitcoin staked into Babylon is ackshually done on bitcoin. Candidly, it’s dope. This is how a user stakes on bitcoin:
A user sends BTC to a self-custodial staking script on bitcoin L1. Funds can securely be retrieved from the staking contract after the expiration of a timelock or on-demand. On-demand retrieval of funds needs a permissioned 6-of-9 signers committee to co-sign the transaction.
The 6-9 committee is a covenant emulator committee. Since Script can’t enforce spending conditions on a UTXO (wen CTV?), we need to have a committee to do it. This committee is managed by six entities. The ‘minimum attack vector’ is four, as Babylon holds three keys and any three of the remaining six operators can form a majority with them. Find them here.
These are the spending conditions that the covenant committee puts on BTC deposited into Babylon:
- If the staker is malicious and gets slashed, the percentage of the slashed bitcoins must satisfy the protocol's fractional slashing percentage.
- If the staker is malicious and gets slashed, the destination address of the slashed bitcoins must be the unique slashing address specified by the protocol, not any other address.
- When the staker unbonds, the unbonding time must be no shorter than the protocol's minimum stake unbonding time.
Note that the covenant committee can’t steal a user's funds… they can just potentially censor an on-demand retrieval of funds. They can also help stakers avoid slashing penalties. Full outline of trust assumptions available here.
So, tl;dr: Stake on bitcoin via a script (with some help from the committee), notify Babylon validators of this transaction, and then the stake is assigned to a finality provider (a validator on the Babylon chain).
“You gotta slash the hell out of them”
Bitcoin can’t enforce slashing conditions from PoS chains…
Well, kind of. Babylon introduces a cool trick to make BTC on bitcoin slashable via Extractable One Time Signatures:
In the context of the Babylon bitcoin staking protocol, accountable assertions using extractable one-time signatures (EOTS) will ensure that misbehaving stakers can be penalized and funds can securely be slashed on bitcoin L1, despite bitcoin's lack of smart contract functionality.
EOTS are a type of cryptographic signature designed to be extractable. It is used by the validator to sign events on the PoS system. If a finality provider signs multiple conflicting messages with the same EOTS key, their private key can be derived from these signatures, enabling anyone to initiate a slashing transaction on the bitcoin chain, thus “burning” the staked bitcoin as punishment and therefore hold the staker (or the delegatee respectively) accountable for the assertions made.
The combination of accountable assertions and EOTS will help Babylon provide enforceable penalties (slashing) on the bitcoin chain for violations occurring on the PoS chain, even though bitcoin doesn’t natively support smart contracts.
So since we have this neat trick to enforce slashing (e.g. revealing a stakers private key), we can enforce economic penalties on stake associated with malicious validators on a given PoS chain.
But… it’s not live
Babylon’s PoS protocol (you know, the thing that actually leverages the staked bitcoins and provides security across selected Comet BFT chains), isn’t live. We can’t really say how it’ll end up working, but we know it’ll be fantastic 🎉
But, deposits are live. And, they’re using the staking scripts we mentioned above. Users can deposit BTC via a staking script today, but the BTC isn’t really doing anything.
Thus, we don’t really consider it staking as the BTC is not actively securing any PoS chain (and as a result, earning rewards).
So, liquid staking tokens aren’t real then?
Something that is being “built on top of Babylon” are liquid staking tokens. Liquid staking tokens (LSTs) are IOUs that users receive when they give their funds to another entity to stake funds on their behalf. People opt to do this for user experience sakes. There’s dozens of these things popping up today (note that Babylon does not offer an LST).
Additionally, LSTs can be used as collateral in onchain applications, can be transferred among users, and more. The LST isn’t locked in the protocol, like the BTC would be in Babylon.
Sooo… YES! We get to say it one more time.
[insert new bitcoin szn 2 thing] isn’t real. This time it’s bitcoin LSTs.
LSTs aren’t real (yet) 👇
The current rendition of bitcoin LSTs are simply tokenized (wrapped) bitcoin IOUs that a user holds on another chain. They can leverage these tokens in all kinds of crazy financial games, and they just hope this token doesn’t become worthless.
The process of acquiring one of these tokens (basically) is:
- A user has some version of wrapped bitcoin on another network. For example, wBTC on Ethereum
- They deposit the token into a “bitcoin LST” protocol and receive an “LST” in exchange for their deposit. They use this new token for whatever
- The operator of the “LST protocol” then takes the wrapped bitcoin, sells it for native bitcoin, and then deposits it into a Babylon staking script
- Everyone waits (because Babylon staking isn’t live)
The operators behind these LST protocols are all custodians. We haven’t developed a 1:1 mapping between the redeeming of wrapped bitcoin for native bitcoin done by the LST. At this point, we’re kinda just trusting that the custodians are actually depositing into Babylon. We’re also trusting that when a user wants to redeem their wBTC or native BTC, that they will process and honor the redemption.
The incentive? Points.
Remember, Babylon staking isn’t live. There is no yield (yet).
We’re looking at it (slowly)
We think bitcoin staking is kind of cool. It’s a new design space that is one of the most exciting things from this new wave of bitcoin-adjacent protocols.
But, framing the current state as “bitcoin staking” and users earning “yield from liquid staking tokens” is a bit of a stretch.
We feel that the current state of things is simply users, and custodians on behalf of users, depositing funds into bitcoin staking scripts in exchange for points and future participation in the Babylon staking protocol.
Like with most things in bitcoin season 2, we remain excited about the possibilities, but cautious on the current implementation.