Introducing StakePeg: A trust-reduced two-way bitcoin peg

In 2020 I started researching the existing solutions for creating a two-way bitcoin peg. I have been eagerly awaiting the advent of trust-minimized bitcoin sidechains and, after years of effort, I wanted to check in on the progress. What I found was inspiring, and led to the formulation of an idea that I am now calling StakePeg.

I should note at the outset that StakePeg is heavily inspired by the work of Matt Bell (Nomic), Ruben Somson (P1WP), and the tBTC authors. All of the good ideas in this blog post can be credited to those cited, and all of the bad ideas in this post can be credited to me; that said, you can of course direct all questions about StakePeg to me and I’ll do my best to answer them.

How StakePeg works

StakePeg enables users to deposit BTC into a specially-crafted multisig address, mint an equivalent amount of tokens on an alternative blockchain (or “altchain”), and later redeem the minted tokens for an equivalent amount of BTC back on the mainchain. This capability is generally referred to as a “two-way peg”, since the tokens minted on the altchain are 1:1 redeemable for and therefore pegged to the value of BTC.

StakePeg implements a two-way peg in a way that requires a significant reduction in trust compared to centralized or federated pegs. The incentives of StakePeg are designed to make attempts to break the peg for extended periods of time unprofitable, giving users a strong guarantee that they can always redeem their pegged tokens for an equivalent amount of BTC. If this is a useful point of reference, you can think of StakePeg as “tBTC but more decentralized, fully permissionless, and with weaker trust assumptions”.

Here is a step-by-step high-level explanation of how StakePeg works:

Step 0. Launch an altchain that you want to create a two-way bitcoin peg for and deploy all of the necessary smart contracts to run the StakePeg system.

Step 1. Burn some amount of BTC on the bitcoin mainchain by sending an OP_RETURN burn transaction, adding some application-specific metadata so that only BTC burned for this specific purpose is counted by the StakePeg system (e.g. application and chain identifiers and a destination address on the target altchain, the purpose of which is discussed in the next step).

Step 2. Mint some amount of tokens that we’ll call STAKE on the target altchain according to a given formula based on the amount of BTC burned. The formula could dictate a 1:1 issuance rate or the issuance rate could be based on a bonding curve of some predefined slope (e.g. the more BTC is burned, the fewer STAKE is issued; a 1:1 ratio makes the system simpler for reasons explained later in this post). Valid burns are proven to the StakePeg system using either an SPV proof if the altchain and StakePeg system is loosely coupled with the mainchain or, if the altchain and StakePeg system is tightly coupled with the mainchain, by having altchain full nodes monitor the mainchain for valid burn transactions directly. The corresponding amount of STAKE is then minted to the altchain destination address specified in Step 1.

Step 3. Deposit STAKE into a Staking smart contract on the altchain to register as a StakePeg signer. Signers are responsible for taking joint custody of BTC deposits and signing valid withdrawals. It is up to the initiator of the system to decide on the collateralization ratio required between STAKE and BTC deposits.

Step 4. When someone wants to “transfer” some BTC to the altchain, they will first call the Deposit smart contract on the altchain. Deposits can be made in fixed denominations, specified by the system initiator. If the given deposit would not push the system over its required collateralization ratio, the contract will generate a deposit address derived from the public keys of registered signers.

Step 5. Once the deposit is sent to the specified deposit address and has a sufficient number of confirmations (another parameter to be decided by the initiator) then the depositor can call a Mint smart contract to mint a corresponding amount of XBTC, a token on the altchain that can be redeemed for an equivalent amount of BTC. When XBTC is minted, a portion specified by the system initiator is set aside and paid to the signers as a signer fee. XBTC can then be freely transferred and used the same as any other token on the altchain. If the altchain developers are so bold, they could even require that XBTC be used for paying altchain mining fees, making XBTC the first-class money of the altchain.

Step 6. When a user wants to make a withdrawal, they will send their XBTC to a Withdrawal smart contract, specifying a mainchain bitcoin address that their withdrawal should be sent to. The withdrawal smart contract will then select a custodian group to process the withdrawal, and they will produce a signed bitcoin transaction sending the specified amount of BTC to the specified mainchain withdrawal address.

Handling failures

There are two main types of failure: liveness failures and fraud failures.

A liveness failure occurs when signers do not “show up for work” when summoned by the StakePeg system. Specifically, signers must respond to and process any valid withdrawal requests. If a user does not receive their withdrawal within a specified period of time, then the signer group in charge of processing the withdrawal will have their STAKE seized by the Withdrawal contract. The seized STAKE is then auctioned off for XBTC using a falling-price auction. The user who attempted the failed withdrawal will receive up to 100% of their XBTC back from the proceeds of the auction. Any extra XBTC collected from the auction will be split 50/50 between the account that reported the liveness failure and the signers that the STAKE was seized from to fund the auction. The user can then try to make their withdrawal again and have their withdrawal assigned to a more responsive signer group.

A fraud failure occurs when a signer group produces an unexpected signature for the BTC in their custody e.g. they sign a BTC withdrawal without there being an associated valid XBTC withdrawal. When fraud is reported, the STAKE of the guilty signers is seized and auctioned off for XBTC, as in the liveness failure case. The proceeds from the fraud auction are sent to the Mint smart contract to ensure full collateralization of the system. Any extra XBTC leftover is given to the account that reported the fraud.

In both instances of failure, guilty signers are punished by having their STAKE seized, making intentional instances of failure unprofitable.

How is StakePeg different than tBTC?

At the beginning of this post I said StakePeg can be thought of being very similar to tBTC. So what is different about StakePeg? The main difference is that ETH and KEEP tokens in the tBTC system are replaced with STAKE tokens. The requirement to burn BTC to mint STAKE guarantees the StakePeg system is fair, permissionless, and trust-reduced: there is no privileged party who can mint free tokens for themselves and their friends and there is no need for users who want to enter the system to get permission from an existing tokenholder to join since it is always possible to burn BTC to mint STAKE. These qualities ensure that StakePeg is consistent with the permissionless and trust-minimized ethos of bitcoin itself.

Another difference is that while tBTC relies on oracles to maintain proper collateralization ratios between ETH and BTC in the system, StakePeg does not strictly require an oracle except as an optional “defense in depth” measure. The reason is that the initiator of the system could set some fixed collateral ratio between STAKE and BTC, for example 1.5 STAKE is required for every 1 BTC in the system, and assume that the value of STAKE will never drop below 0.66 BTC per STAKE (at which point it could become profitable for signers to steal BTC in their custody). There’s no way to guarantee that this price drop never occurs, but since BTC has to be burned to mint STAKE, it may be reasonably safe to assume that STAKE holders will not let go of their STAKE for less than the BTC value that the STAKE was acquired for, or that such aberrations would be rare as long as the system remains in sufficient use, since STAKE is an income-producing asset. Over-collateralization would also create a buffer against temporary price fluctuations. If an oracle is desired to harden the peg further, then one could be implemented using an on-chain decentralized exchange to source manipulation-resistant price feeds.

What does “trust-reduced” mean?

The reason for calling StakePeg “trust-reduced” instead of “trust-minimized” is that, as pointed out above, there is a possibility that the system becomes profitable to attack if the price of STAKE drops too much. Users are mainly “trusting” that STAKE will maintain an exchange rate close to the collateralization ratio so that stealing from the system remains unprofitable.

I think it is possible to build a two-way peg deserving of the label “trust-minimized” with even stronger security guarantees; something like Zendoo but without a trusted setup comes to mind, however this would require further research and, if it’s even possible, a change to bitcoin’s consensus rules would be required. I therefore have decided to call StakePeg “trust-reduced” to signal that while StakePeg does have weaker trust assumptions compared to centralized or federated pegs, the amount of trust required is not as minimized as I think it possibly can be.

What is StakePeg good for?

The purpose of StakePeg is to create a stronger two-way peg than the other two-way pegs that are out there: centralized pegs like WBTC, federated pegs like Liquid L-BTC or RSK RBTC, and stake-backed pegs like tBTC that have centralized origins. StakePeg liberates BTC to be able to be moved between blockchains with the strongest guarantee currently available that the pegged XBTC tokens will be redeemable for real BTC.

The future I envision for StakePeg is that BTC holders will be able to transfer their BTC to zero-knowledge altchains to make end-to-end encrypted transactions with perfect anonymity; to transfer their BTC to advanced smart contract altchains to leverage their BTC in DeFi smart contracts; to transfer their BTC to decentralized DNS altchains and register censorship-resistant domain names; etc, etc, for every new blockchain feature and use case imaginable, all in a way that keeps BTC as the preferred money within a 100% bitcoin-powered blockchain ecosystem.

Next steps for StakePeg

The next obvious step, after getting public review to sanity check this idea, is to build an implementation of StakePeg. I think the most obvious candidate altchain to build on is RSK, since it has support for the smart contracts needed to run the system and is merge–mined with bitcoin. Someone could code up the STAKE token contract and burned-BTC issuance mechanism, copy most of the Keep Network code and tBTC code and replace KEEP and ETH with STAKE, and deploy all that to RSK to launch the StakePeg system.

There’s an open question about how profitable it would be to participate in this kind of system in the long run. Will the signers who burn BTC for STAKE or buy STAKE off the market be able to turn a profit in a reasonable amount of time? Will people really want to use StakePeg rather than just using the existing federated RSK PowPeg? Both the RSK RBTC PowPeg and tBTC peg have relatively low usage compared to weaker and more centralized pegs like RenBTC and WBTC. Maybe people don’t actually care about decentralization enough? Or maybe it’s a “gradually, then suddenly” kind of thing, like bitcoin itself? IDK. TBD.

Source: https://explorer.rsk.co/

Source: https://defipulse.com/btc

Then there’s the (exciting) uncertainty introduced by the possibility of even stronger two-way pegs, such as Drivechain, Softchains, and Zendoo. While these require consensus changes to bitcoin, which puts their arrival further out, their eventual availability could obsolete StakePeg, at least on bitcoin-native sidechains like RSK. This would leave the STAKE holders on those chains holding some heavy bags depending on how much BTC was burned in exchange for STAKE.

One way to resolve this dilemma would be for there to be a “social contract” between STAKE holders and the sidechain community that, should a stronger two-way peg mechanism one day be adopted by the sidechain as a replacement for StakePeg, that some portion of the sidechain mining fees will be used to buy STAKE at its burn value until all of the BTC that was burned for STAKE has been paid back. All STAKE bought back this way would in turn be burned by a smart contract to permanently remove it from circulation. This would give prospective STAKE holders some assurance that they can invest in the StakePeg system without having to worry as much about getting burned later if an even more secure two-way peg system is adopted that makes StakePeg obsolete.

So. Who wants to build this thing?

---

Email is probably the most popular decentralized messaging protocol, and I expect it to be around for a while. Add yourself to my email contacts if you would like to stay in touch! I will never sell, rent, or share your email address.