So, you got orange-pilled and now hold BTC. Good for you, better late than never.

Then, you heard the sacred adage of this industry: not your keys, not your coins. Compounded by the horrors of various CEX rugs and hacks, you finally decided to self-custody your bitcoins.

Congratulations, you are now in charge of your own financial destiny. Hooray, no?

You realize that transacting on Bitcoin is stupidly costly, so expensive that it will put Ethereum’s notoriously high gas fees to shame. Because unlike those damned whales, you don’t have $1M worth of bitcoins to spend — every transaction that you make on the mainchain will hit you hard.

Now what? Surely there’s got to be a better way.

Leaving the nest

When you hold bitcoins (BTC, the cryptocurrency) outside of Bitcoin (mainchain, the blockchain), you won’t be afforded the security and protection of the mainchain, thus requiring you to inherit the trust assumptions of whatever chain or layer that you’re on, as well as the BTC representative token that you hold (if applicable).

Unfortunately, this is the iBitnevitable trade-off that you’re gonna have to make — for now.

This article will aim to provide an overview on the various scaling approaches and bridges that are out there, as well as outlining the trust sacrifices that you will have to incur on each. In addition, we will lay bare the shortcomings of each, and why there is still no proper Bitcoin scaling solution that is able to “export” BTC without significantly compromising users of its mainchain’s security and protection.

The term Bitcoin and mainchain will be used interchangeably throughout. Let’s begin.

Lightning Network

Launched on January 2018, the Lightning Network presents one of the earliest attempts that is made to scale Bitcoin. At its core, the Lightning Network is made up of a network of payment channels, whereby each payment channel is fundamentally a 2-of-2 multisig contract (leveraging HTLCs) amongst two parties on Bitcoin.

What makes the Lightning Network work, is that there exists multiple payment channels that maintain a connection to the peer that you want to send your bitcoins to. As such, even if you do not have a direct connection to Bob, as long as you have a connection with Alice (who has a connection with Bob), you can initiate payment from your Lightning node and pay Bob via Alice.

In theory, you can transact with anyone as long as your counterparty share at least one mutual peer (with enough liquidity). Hence, the “network” in Lightning Network.

tldr

When Bob wants to open a payment channel with Alice, they combine their keys to generate a 2-of-2 multisig contract, which will act as the channel’s address. Then, Bob broadcasts two transactions: his commitment transaction (to spend his funds back to his funding wallet if Alice becomes unresponsive) and his funding transaction (Bob deposits his bitcoins into the 2-of-2 multisig). Likewise, Alice also broadcasts her commitment transaction and her funding transaction. Note that it is important for the first commitment transaction to be signed by both parties before anyone funds the payment channel. This is to ensure that funds won’t be stuck in the multisig in case either party goes offline.

Once the payment channel is established, Bob and Alice is free to spend the bitcoins inside the multisig as many times and however they see fit. When you “send” funds, you’re actually updating the shared commitment transaction that you have with the other party to reflect the latest state of balances, invalidating the previous commitment. The commitment transaction is never submitted onchain when the payment channel is still live, and is known to only Bob and Alice. The commitment transaction is only published upon closure of the payment channel.

When Bob wants to close a channel (and get his bitcoins back to the mainchain), there are two ways to do it: cooperatively with Alice, or non-cooperatively (aka force close). In a cooperative close (happy path), both Bob and Alice agree on their share of balances from the multisig, and they both sign a new transaction that spends the funds back to their respective wallets immediately.

However, in a force close scenario (unhappy path), either Bob or Alice may not be available or unwilling to cooperatively sign the closure transaction. In this case, the party initiating the force close will spend their balance to an arbitration contract, allowing their peer to contest it within the CSV delay (aka dispute period). In the event that this party were to attempt to “cheat” (publishing an older commitment transaction), their peer simply publishes the most recent commitment transaction, claiming the funds of the cheating party from the arbitration contract for themselves.

‍

[lightning.engineering] illustrated: Bob’s failed 8 BTC force closure claim

To illustrate, let’s assume Bob and Alice has a “true” balance of 4 BTC and 6 BTC respectively (the payment channel contains 10 bitcoins in total). If Bob initiates force closure and claims that he has 8 BTC in the payment channel (by publishing an older commitment transaction), Alice may simply publish the latest commitment transaction and claim Bob’s 8 BTC from the arbitration contract. This will serve as a deterrent to Bob, ensuring that parties do not need to trust each other when opening a Lightning channel.

not your node, not your coins.

The thing with the Lightning Network, is that you can’t self-custody unless you run your own Lightning node. Otherwise, you must deposit your BTC to a trusted Lightning node in order to use the network, where your bitcoins form part of their internal ledger and they transact on your behalf. If the Lightning node which holds your deposit rugs, then your BTC runs with them and you have no recourse. This is basically worse than depositing your bitcoins into a trusted CEX — I mean, at least you’re dealing with Binance or Coinbase!

Should you decide to run your own Lightning node, then you’d need to be constantly online to monitor for channel breaches from your peers. While you can assign Watchtower nodes to help you monitor breaches (they will store your commitments that are generated on every transaction that you make on the payment channel to contest fraudulent force closures on your behalf), you essentially revert back to trusting centralized entities. Again, you might as well trust Binance or Coinbase rather than some random watchtower company to safeguard your bitcoins!

[Sam Aiken] illustrated: the LN watchtower in action

As if the above isn’t enough to deter you, if you run your own Lightning node, then you’d need to manually manage your own node’s liquidity in relation to your peers. For instance, if a payment channel only has 10 BTC in total, then the maximum balance that either party can hold between each other is 10 BTC. However, this is notwithstanding the fact that you may have connections to multiple peers (since you’re likely to be making payments to many different parties) — if you want to transact with someone you don’t have a direct connection with, you’ll need to rely on other Lightning nodes who have connections to both you and your counterparty, also with enough liquidity to route the payment. Now you can see why liquidity management is very cumbersome to the average node runner.

Therefore, most Lightning nodes simply do away with this and connect to routing nodes, which are well-capitalized Lightning nodes (most likely run by large institutions) dedicated towards routing payments. They sit between Lightning nodes as an intermediary channel, acting as a quasi-matchmaker of payments throughout the network. As a result, the network tends towards centralization in this regard — at the time of writing, the top 10 Lightning nodes make up >75% of the network’s entire capacity!

[LnRouter.app] active Lightning Nodes, filtered by capacity

Phoenix Wallet, developed by ACINQ, is an attempt to simplify self-custody on the Lightning Network for the average user. When you download their wallet app, your phone automatically becomes your own Lightning node. To simplify liquidity management and payment routing, your Lightning node will connect to ACINQ node, relying on ACINQ as a router for your inbound and outbound payments.

Nonetheless, you’re still required to be periodically online and watch for breaches — else, you are still at the mercy of ACINQ. As unlikely as it is, assuming ACINQ attempts to force close your channel with an outdated commitment, you would need to come online to contest it and present the correct most recent commitment. Otherwise, you stand to lose your funds to ACINQ.

conclusion

The Lightning Network is designed for node runners. In the real-world, however, not everybody needs to run their own node — this isn’t realistic nor practical.

Alas, the Lightning Network is never meant for the average non-geek BTC holder. The fact that you need to run a node just to remain self-custodial, coupled with its restrictive use case of strictly being a payments network (not programmable to natively unlock richer use cases such as DeFi), relegates the protocol to the fringes of the true Bitcoiner running their own node.

Not your node, not your coins. And not ideal for the average user.

Statechains

Statechains as a concept borrows heavily from Lightning’s payment channels, in which both enable unlimited offchain transactions that will be eventually “settled” on Bitcoin at its closure.

tldr

Unlike Lightning channels (which are 2-of-2 multisigs), a statechain’s UTXO deposit address is created completely offchain by the operator, which is a trusted entity who generates key shares both to themselves and the UTXO’s current owner. The UTXO owner wanting to initiate a statechain collaborates with the operator (trusted entity) to create an address where the corresponding public key is formed from both the first owner and the operator’s key shares. From here, the owner funds the statechain with the UTXO (or bitcoins), then creates a backup transaction (with the operator’s cooperation), which is a timelock that will allow the owner to unilaterally claim their UTXO back upon its expiry.

‍

[Nik/Coinmonks] Statechains in action: transferring UTXO ownership from Alice to Bob

If the current owner wants to transfer ownership of the UTXO to a new owner, the operator will simply re-generate key shares amounting to the same deposit address and delete their key share with the old owner. Then, the new owner creates a backup transaction (with the operator’s cooperation) but with a shorter timelock. Each time a statechain changes hands, the operator will delete the previous key share and co-sign the new owner’s backup transaction that will have a shorter timelock than the previous owner, that is until the timelock is unable to be shortened further (which necessitates a new statechain to be created for the new owner).

This way, the old owner can’t unilaterally withdraw funds from the statechain in lieu of the new owner. Because in order to cooperatively exit the statechain (instant withdrawal), the old owner needs the operator to co-sign their exit transaction (which the operator can no longer do, as they have deleted their previous key share that could co-sign the transaction), else the old owner has to wait for their timelock to expire before they can submit their backup transaction. Nevertheless, even if the operator goes offline when the new owner wants to exit the statechain, they can always submit their backup transaction and claim the funds ahead of the old owner, as their backup transaction has a shorter timelock.

in the operator we trust

As if it isn’t obvious enough, the operator is the single point-of-failure for statechains. New owners need to trust that the operator has indeed deleted their previous key share and will not collude to cooperatively claim funds for the previous owner. Since the operator’s server is basically a web2 closed box, the new owner has no way to verify the deletion of the operator’s previous key share (that is unless they are the operator themselves).

Mercury Layer, a statechain project, aims to eliminate this trust factor. Utilizing a blinded variant of Schnorr, the Mercury operator is not aware of the Bitcoin chain itself. Thus, the operator has no idea which deposit address are they co-signing for, the details of backup transactions, nor learn of any signatures that they generate. Assuming the same operator handles multiple statechains, Mercury will essentially blind sign every incoming co-sign request that comes their way, with no knowledge of what they signature will enable. This prevents selective collusion by the operator, ensuring that key generation and signing are done correctly on their server as they simply have no incentive to be malicious (they do not know what’s at-stake due to blind signing).

[Ruben Somsen] the operator is signing blinded messages — it does not know whether these are Bitcoin transactions or something else entirely.

In spite of Mercury’s efforts, however, statechains fundamentally remain severely limited. You can only “send” the exact amount of BTC that you deposited to the statechain, as statechains at its very core is simply an address ownership transfer protocol instead of actually facilitating UTXO transfers like Lightning Network. Furthermore, in the event that the operator goes offline, all “sends” will be halted, and you will have to wait for your long timelock to expire before you can claim your funds back to Bitcoin via a backup transaction.

conclusion

While statechains offer a clever “hack” for transferring UTXOs over the cost and limitations of Bitcoin, they remain unsuitable for large-scale high-frequency UTXO transfers of differing amounts. In this context, statechains are even more restrictive than Lightning Network — aside from being able to only transfer the exact UTXO that you funded the statechain with, you also have to contend with the same lack of programmability that prevents you from unlocking richer use cases other than payments (i.e. DeFi).

When all is said and done, statechains are just exactly that — a “hacky” trust-minimized address ownership transfer protocol. I mean, at least Lightning actually works for node runners!

Statechains — fun for devs, not so fun for everyone else.

Custodial BTC

Custodial BTC solutions (called “bitbanks” by the OGs), despite being an ideological slap in the face for “true” Bitcoiners, unironically remains one of the safest (and also most convenient) avenue for the average user to transact their bitcoins in a cheap, fast, and reasonably secure way.

Trusted BTC custodians are mostly amongst the oldest crypto institutions, and is highly regarded within the industry, and even in TradFi.

tldr

Pretty self-explanatory, custodial BTC solutions usually involve reputable entities trusted enough by depositors to act as a custodian for all bitcoins deposited with them. Afterwards, they would mint representative tokens across different chains (and environments), where each unit will be backed 1:1 with the amount of bitcoins held in reserve by the custodian (in theory).

As they live on a cheaper and faster chain than Bitcoin, these BTC representative tokens (e.g., wBTC, cbBTC, etc.) allow holders to use it across DeFi, earn BTC-denominated yields, and transact with each other in a much faster and cheaper execution environment.

in the custodian we trust

‍

[BitGo] BitGo: the trusted custodian of wBTC

Goes without saying, users of custodial BTC solutions must place full trust on the custodian of the BTC representative token that they’re holding. Different custodian entities would carry with them differing levels of risk, that is according to interpretation from the holder’s perspective.

For instance, a user would be more inclined to use BitGo’s wBTC if they are someone who values historical track record, exchange liquidity, and its OG-ness. Likewise, people on the other side of the spectrum might prefer to hold Coinbase’s cbBTC if they are someone who puts greater emphasis on clear regulations, transparency, and respect for the American due process and rule of law. This is analogous to someone’s considerations on deciding between Tether’s USDT or Circle’s USDC for their stablecoin of choice — or you just hold both!

conclusion

Although custodial BTC solutions currently serve as a useful bridge for BTC users who wouldn’t otherwise be self-custodial, it remains a stop-gap solution at best.

When you hold wBTC, you’re trusting BitGo just like how you would trust a CEX when you have funds deposited with them. Same goes to Coinbase’s cbBTC, Binance’s BBTC, and numerous other BTC custodians out there.

One lax security opsec and an encounter with the mighty Lazarus (hopefully not), and there goes your bitcoins to finance Kim’s nukes!

Federated BTC

Imagine wBTC, but instead of only having BitGo as the custodian, you also have Wintermute, ChorusOne, and other institutions joining the party and given the keys to the kingdom.

Say, what’s better than one custodian? A hell lot of them!

tldr

Federated BTC bridges are essentially a collective custodial BTC bridge. They involve multiple reputable entities forming a signer set, whereby a majority is needed to authorize transactions on deposited bitcoins held amongst them.

The idea is to eliminate the single point-of-failure risk that is present in custodial BTC solutions. Just like how you would use a multisig wallet over an EOA to self-custody the bulk of your life savings, the idea is that by spreading signing privileges across multiple trusted entities, you’re able to place less trust on each individual signer.

As such, in order to compromise a federated BTC setup (and steal the bitcoins stored within it), the attacker would need to compromise the majority of the entities part of the signer set. To compromise Coinbase is hard. But to compromise Coinbase, OKX, Wintermute, and Fireblocks whilst remaining undetected, is quite the ambitious undertaking for any potential attacker.

multisigs and MPCs

Oversimplified, there are primarily two ways to distribute signing privileges in a federated BTC setup — via multisig (multi-signature) and/or MPC (multi-party computation) constructions. I won’t go into the implementation details for each (it is a lot), but the main idea is that in a multisig, the “shared” address is generated onchain and each signer possesses a full independent private key. This means that when a transaction from the shared address is collectively signed by the signers, the signature is recorded onchain.

With MPC, the “shared” address is generated offchain and each signer possesses a partial key share. When signing an onchain transaction, the signers will jointly compute a signature by combining their key shares. From the blockchain’s perspective, it would seem like the signature is just a standard signature coming from one signer, while in fact it is collectively generated offchain by the signer set part of the MPC construction.

Of course, there are nuances and tradeoffs that exist between each approach. While elaborating on them is very much out of this article’s scope, I would recommend reading this MPC vs. Multi-sig primer by Fireblocks in case you’re a nerd that wants to dive into details and stuff.

in the federation we trust

In theory, this all sounds very safe. You have the very best of crypto institutions, each with their own reputations on the line, collectively safeguarding the federated BTC bridge. What could possibly go wrong?

You see, less trust doesn’t mean no trust. With a federated BTC bridge, signer selection is of paramount importance. The federation needs to include enough number of signers, a safe majority threshold (at least two-thirds), and sufficiently geographically distributed. Not to mention that each signer needs to already have a good enough reputation that they are willing to protect, as well as having vested interest over the success of the federated bridge.

For me, out of the institutions that are signers to at least one currently live federated BTC bridge, there are honestly only a handful of them that I would trust my life savings with. Fingers crossed, you have the trustworthy Coinbase — then probably Galaxy, Wintermute, and Fireblocks. I’m not saying that the rest are all dud institutions, but to trust them with 100% of my life savings is another matter.

‍

In short, there’s no use in having 15 signers on your federation, when 10 of them do not implement good security practices or even just downright sketchy. The problem is, to find 15 signers of superb reputation with great opsec, let alone 50 signers, is easier said than done.

When everybody claims to be reputable and secure? Voila, only a few actually are!

‍

With that said, it is my view that federated BTC bridges remain the best way to “export” BTC to other chains (or layers) that are external of the Bitcoin mainchain. Expect cypherpunks to roll in their graves, but a carefully curated federation of quality signers would in most cases be safer than any permissionless alternative that is possible at current circumstances.

After all, there’s a reason why most BTC representations that you see today mostly rely on a federation of signers. You have solvBTC, pumpBTC, Lombard’s LBTC, Stacks’ sBTC, Avalanche’s BTC.b, Bitlayer’s WBTC, Liquid’s L-BTC, Merlin’s MBTC — all of which would require you to place trust on the federation of signers that each has respectively curated. But since actually reputable signers are hard to come by, don’t be surprised to find multiple instances of signer overlaps between federations, in which the same signer would find themselves be part of two or more bridge setups. For example, Cobo is a signer for solvBTC, pumpBTC, and Merlin’s MBTC. Or Chorus.one, a signer for both Lombard’s LBTC and Stacks’ sBTC.

There are even instances where two signers within a federation are actually part of the same wider ecosystem or entity. For instance, Avalanche’s BTC.b includes Avascan and Ava Labs as part of its 8-signer federation. Assuming a 5-of-8 majority threshold (the necessary minimum), that leaves the attacker with “only” 3 signers left to bribe or compromise (and seriously threaten the security of the BTC.b bridge).

Lombard LBTC

To their credit, some projects do recognize the importance of signer opsec and have taken steps to minimize this attack vector. For example, Lombard employs a multi-tiered approach to security by mandating their Consortium (signer set) to run CubeSigner, a non-custodial key management platform built by Cubist utilizing HSM-sealed Nitro enclaves. In practice, CubeSigner allows keys to stay in secure hardware from address generation to transaction signing — no one, not even Cubist or the signers themselves, can see the keys let alone for outside attackers to extract them.

However, just like how you trust Ledger on the integrity and incorruptibility of the Ledger hardware wallets that you have at home, Lombard’s LBTC holders would also need to trust Cubist on the integrity and incorruptibility of the CubeSigner instances run by the Consortium signers — else, we’re back to relying on each Consortium signer to not botch their own opsec.

‍

[Lombard] illustrated: Lombard LBTC architecture

In addition, this is notwithstanding the risk of possible signer collusion, no matter how unlikely it seems to be. The simple fact is that if a majority of Lombard Consortium’s signers collude, they will be able to compromise the BTC held across the Consortium’s addresses and steal user funds.

conclusion

As an industry, we would be doing ourselves a disservice were we to be satisfied with the selection of BTC representations that we have today. Harsh, but it needs to be said: there is no point to Bitcoin (and in fact, this entire industry) if only a select few whales with the pockets to pay for mainchain transaction fees are the only ones that can transact BTC in a trust-free manner. This whole notion of BTC as the trustless sound money for the masses, would cease to exist when the only realistic way for most people to save, spend, and transact BTC requires them to place trust on entities run by fallible humans under state jurisdiction.

Federated BTC bridges indeed paved the way for people to hold and transact BTC in a fast and cheap manner, while still being relatively secure compared to other available alternatives. But they are never intended as the endgame for Bitcoin scaling, but rather as a means to an end.

Good enough so far, but certainly not the holy grail solution that the industry (and the market) desperately needs.

Rootstock rBTC

‍

[Rootstock] Rootstock: one of Bitcoin’s OG scaling solutions

Launched on January 2018, Rootstock is the first and longest-lasting Bitcoin sidechain. It leverages merge-mining for consensus, and employs a two-way federated BTC bridge where rBTC is also used to pay for gas fees on Rootstock.

The catch? Rootstock’s federated BTC bridge doesn’t require an honest-majority assumption for it to be secure!

Now that I have your attention, let’s dive in.

merge-mining

The Rootstock chain employs merge-mining to reach consensus. Unlike PoS chains (where the proportion of your staked assets relative to the staking set represents your voting power), merge-mined chains seek to leverage the hashrate capacity that is already being used to mine Bitcoin by extending it to validate the Rootstock chain. This allows Bitcoin miners to simultaneously secure both Bitcoin and Rootstock with the same infrastructure and energy consumption, allowing them to earn mining rewards from both networks with the same expenditure. If you’re more familiar with PoS, merge-mining would be analogous to restaking — the same resource (e.g. ETH) is used to simultaneously secure both the native PoS chain (via liquid staking platforms) and external PoS networks (by restaking your LST to secure your networks of choice).

‍

[Alexei Zamyatin] illustrated: merge-mining

As of writing, ~80% of Bitcoin miners have opted in to participate in Rootstock’s merge-mining process — every PoW of a Rootstock block will now inherit ~80% of Bitcoin’s hashing power!

To facilitate higher throughput on the chain, Rootstock blocks are designed to be mined faster than Bitcoin blocks (thus, has a lower difficulty than Bitcoin). As of today, Rootstock’s average block time stands at circa 25 seconds compared to Bitcoin’s 10-minute average block time.

tldr

To bridge BTC onto the chain, Rootstock has implemented a special type of federated BTC setup that comes with a hardware twist. Pegnatories (signers) are required to run Rootstock’s hardware security module, called PowHSM. The PowHSM is a tamper-proof device responsible for storing the signer’s key that is part of the federation’s multisig scheme. Similar to Lombard’s CubeSigner implementation, PowHSM is designed to ensure that keys stay in the secure hardware from generation to signing — no one, not even Rootstock or the signers themselves, can see the keys let alone for outside attackers to extract them.

The Bridge contract on Rootstock runs Bitcoin SPV, giving it a view of Bitcoin from Rootstock in a trustless manner. For peg-in transactions, pegnatories wait for the user’s BTC deposit on Bitcoin to accumulate 100 confirmations before informing the Bridge, whereby it will then mint rBTC to the user upon verification of the user’s BTC deposit (via Bitcoin SPV).

For peg-out transactions, the Bridge will first accept the peg-out request. After 4000 block confirmations (on Rootstock), the Bridge builds the Bitcoin peg-out transaction corresponding to that request for pegnatories to sign off. Every PowHSM will then receive this command (via Powpeg, aka Rootstock full nodes) and trigger the pegnatory to sign the transaction. Once a majority of pegnatories sign the transaction, Rootstock’s Bitcoin multisig will then release the corresponding amount of BTC to the withdrawing user’s Bitcoin address.

collusions be damned

What sets Rootstock’s federated BTC bridge implementation apart from the others, is that it doesn’t require an honest-majority trust assumption from its signer set in order for its bridge to remain secure. In other words, even if a majority of Rootstock’s pegnatories collude, they still won’t be able to compromise the bridge and steal user funds.

How is this possible? The reason is because Rootstock is able to decouple transaction generation away from transaction signing, and pair it with HSM-secured signing connected to Powpeg.

To illustrate, in a typical multisig or MPC construction, its signers generate and sign transactions. Taking Lombard as an example, a user must first submit a peg-out request by interacting onchain with a Lombard bridge contract. One of Lombard’s signers will pick this up, then generate the user’s request as a Bitcoin transaction before proposing to the Consortium for sign-off. Upon majority approval, Lombard’s Bitcoin multisig will then release the corresponding BTC amount to the withdrawing user. Expect this to be representative across every federated BTC bridge, less minor (inconsequential) variations.

Following on, notice that the Lombard signer is the one who generates the Bitcoin transaction facilitating the user’s peg-out. In the event of majority signer collusion, the signer (with the majority’s blessing) will be able to propose a rogue transaction to the Consortium for majority approval. This is why federated BTC bridges have almost always implied an honest-majority security assumption — that is, until Rootstock!

‍

[IOV Labs] illustrated: architecture of Rootstock’s Powpeg

Rootstock is unique in a way that pegnatories do not generate Bitcoin transactions corresponding to a user’s peg-out request. This is because the Bridge contract on Rootstock is the one that builds the Bitcoin transaction for the user, which is in turn validated by Bitcoin miners who have opted in to participate in the chain’s merge-mining process. Pegnatories play no part in transaction generation — their role is merely to run the PowHSM, which connects to Powpeg and will “automatically” sign the already-built transaction once received.

To visualize, imagine that you’re visiting the Uniswap interface to do a swap. First, your wallet (i.e. Metamask) will generate transaction data based on what you intend to do (e.g. ”swap X ETH for USDC”), which then pops up on your hardware wallet (i.e. Ledger) for you to sign. In this scenario, the one clicking on the Uniswap interface is analogous to the withdrawing user, the wallet generating the transaction data is analogous to the Bridge contract on Rootstock, and the one pressing the physical buttons on the hardware wallet is analogous to the pegnatory-run PowHSM signing the received transaction.

in the hardware we trust.

Recall that the Rootstock blockchain is now merge-mined with 80% of Bitcoin’s hashing power. Therefore, unless you want to go the hard route and try to compromise the rBTC bridge by possessing >40% of Bitcoin’s hashing power and maintaining it for at least 4000 Rootstock blocks (~28 hours), as a prospective attacker you’d be better off targeting the integrity of Rootstock’s PowHSM implementation instead. Just like how you’d be trusting Cubist when it comes to negating Lombard’s signer opsec risk, the user would also need to trust Rootstock Labs that the pegnatory-run PowHSM do not have any bugs or covert backdoors that can be exploited by Rootstock, a potential attacker, or even the pegnatories themselves.

In Rootstock’s defense, they have actually taken steps to reduce the amount of trust that users need to place with them by open sourcing the PowHSM firmware. However, as the firmware itself is implemented on top of Ledger Nano S or Intel SGX, users still need to trust Ledger or Intel (as the manufacturers) on their word that the Secure Element chip is indeed secure, and that they will not introduce covert channels, biased random number generators, or any form of backdoor on their devices.

conclusion

Leveraging defence-in-depth (aka layered security), Rootstock has accomplished what no other has done — implementing a federated BTC bridge that doesn’t require an honest-majority assumption for the security of its user-deposited funds.

But again, less trust doesn’t mean no trust. You still need to trust the makeup of Rootstock’s 12-member pegnatory set, just like how you trust the signer sets of other federated bridge setups. Albeit in Rootstock’s case, since pegnatories have no power to tamper with the transaction data (they “merely” run the PowHSM), you eliminate the risk of honest-majority collusion and you “only” trust the pegnatories for liveness. Though, in the event that a majority of pegnatories go offline, you do incur the risk of having your funds stuck inside Rootstock’s Bitcoin multisig.

Moreover, you also need to trust the security of Rootstock’s PowHSM implementation. This includes trusting that firmware installations on PowHSMs are done properly, and also trusting Ledger and/or Intel on the integrity of their devices.

‍

[Rootstock] the big picture: Rootstock’s federated two-way peg and the Bitcoin mainchain

Rootstock’s rBTC bridge is indeed a major improvement to existing federated BTC bridges, but the fact remains: it still necessitates the user to place some level of trust on certain parts of the stack. While I won’t deny that security afforded by Rootstock’s federated bridge setup is already more than enough for 99% of tokens and representations out there, I will digress when it comes to BTC — a trust-minimized bridge is not only preferred, but rather a prerequisite.

Rootstock deserves a lot of flowers for having (in my opinion) not only the best federated BTC bridge implementation, but also the best overall BTC bridge that is currently up-and-running — elegantly balancing the need for security and capital-efficiency with its design.

However, the job’s not done — yet.

Collateralized BTC

Aside from Lightning, collateralized BTC bridges represent one of the only few known ways to “export” BTC to a scalable chain or layer in a truly permissionless manner.

No reputations involved, no trusted entities necessary. Designed to be open for anyone to join yet trust-minimized, users do not need to trust anyone whatsoever.

Here, cash is literally king.

tldr

The idea is straightforward: for every $1 worth of BTC deposited into the collateralized BTC bridge, there would be at least more than $1 worth of other assets backing it.

What about the implementation? Not so much!

Though minor variations exist, we can primarily categorize collateralized BTC bridges into two implementation types: CDP-style bridges and stake-weighted bridges.

Interlay iBTC

CDP stands for collateralized debt position, popularized by MakerDAO and is mostly found in decentralized stablecoin projects such as Liquity’s LUSD and MakerDAO’s DAI itself. To mint a debt token (aka LUSD or DAI), users must deposit collateral (i.e., wBTC, ETH) exceeding the value of the position’s maximum allowable debt. The collateralization ratio will depend on the perceived volatility and risk of the collateral asset — safe “blue-chip” assets would tend to fetch a lower ratio, while long-tail assets would require a higher collateral ratio to compensate for their perceived risk. If collateralization ratio falls below a certain threshold (i.e. 110%), then vaults will fall into liquidation where position owners runs the risk of losing their entire collateral.

Interlay’s iBTC is one such example of a CDP-style BTC bridge implementation, in which every $1 worth of bridged BTC must be backed by >$1 worth of collateral on the destination chain. To mint iBTC, vaulters must first deposit collateral on Interlay before depositing BTC on the mainchain. The amount of iBTC that can be minted corresponds to the vaulter’s collateral value on Interlay: if locked collateral is worth $160, vaulters may only mint $100 worth of iBTC on Interlay (160% CR). If the vaulter’s collateral value drops below the liquidation ratio, anyone will be able to burn iBTC to redeem their collateral at a premium (110%) which ensures that the system remains healthy as liquidators will constantly monitor vaults for a chance to extract liquidation premiums.

‍

[Interlay] illustrated: Interlay iBTC

To redeem iBTC for BTC on Bitcoin, users first submit a request to a vaulter, which will then process the withdrawal by sending the corresponding BTC amount to the user from their Bitcoin vault. If the vaulter goes offline or simply refuses to redeem BTC, the user may claim the vaulter’s collateral commensurate to the value of their iBTC redemption, plus some “failed redeem” reward. This way, vaulters are incentivized to redeem BTC for the user, lest they risk paying a premium to the user with their locked collateral on Interlay.

Threshold tBTC

On the other hand, stake-weighted bridges are basically federated BTC bridges, but instead of restricting the signer set to only a select few handpicked trusted entities, anyone can participate as a signer by staking their assets to the bridge (and running the required software to operate as a signer for the bridge). Signing privileges are distributed via multisig and/or MPC, depending on each bridge’s implementation details.

Now let’s take a look at Threshold’s tBTC, arguably the most prominent stake-weighted BTC bridge implementation. Threshold leverages MPC to generate its bridge’s Bitcoin deposit address, each consisting of 100 signers. Signers are chosen via a randomized process (via Sortition Pool), where the probability that a staker is chosen to be a signer is equal to their percentage of their staked $T relative to the signer set — if you staked 10 $T and the signer set has 800 $T staked in total, your chance of being selected as a signer for that Bitcoin deposit address will be 1.25%. Assuming 100 signers for a Bitcoin deposit address, you can expect that your node will make up at least 1 signer from the set. Furthermore, since it uses the Threshold ECDSA algorithm for wallet generation and signing, 51-of-100 signers must cooperate in order to move funds out of Threshold’s Bitcoin deposit addresses.

[Chaos Labs] illustrated: Threshold tBTC

Every 14 days, the bridge will generate a new Bitcoin deposit address for user BTC deposits based on Threshold’s current staking composition. Apart from allowing new stakers to become signers of Threshold’s future Bitcoin deposit addresses, this also accomplishes forward security: even if a corrupt majority were to make up Threshold’s staking composition, it will only compromise new Bitcoin deposit addresses generated from that point on. In other words, if you used Threshold to bridge your BTC (and mint tBTC) before the corrupt majority took over the staking composition, your BTC will remain safely stored in the Bitcoin deposit address controlled by the then-secure honest-majority signer set.

iBTC — in the collateral we trust

Both bridge models (CDP-style and stake-weighted) do not impose upon a closed set of privileged entities in their design. Signer identity nor reputation does not matter here — the only thing that matters vis-a-vis bridge security, is the collateral that is locked in the system.

In the case of Interlay’s CDP-style bridge, users have to trust the collateral that is backing each iBTC. Garbage in, garbage out — if the bridge accepts dud assets for its collateral, it will run the risk of undercollateralization: liquidators may not be motivated to liquidate vaults if the collateral that they receive in exchange does not have a liquid market or efficient price discovery. To bring home the point, imagine that you’re a liquidator and ask yourself: are you willing to liquidate a vault paying 10% premium for a memecoin with thin onchain liquidity and is susceptible to 20% price swings on the hourly?

This is notwithstanding the oracle risk that you will have to incur — as a user, it is inevitable that you need to trust the oracle network that streams the price feeds of collateral assets on Interlay. Oracles are not built the same — while some do have a sizable sample for their price sources and implement robust security practices, others might be a bit more suspect. In fact, the weakest link has often turned out to be the oracle instead of the CDP’s collateral, or the implementation of its smart contracts!

tBTC — in the stakers we trust

Naturally, by being a stake-weighted bridge, tBTC holders would need to trust that Threshold’s $T staking composition remains decentralized, and that no single entity or coalition will be able to comprise more than 51% of staked $T — present or future.

Although Threshold’s forward security will limit damage to only future BTC deposits after the point of (staking composition) compromise, you can’t be quite sure when this actually happens. The attacker can just split their staked $T balances across multiple addresses, which makes it seem like their balances are held by multiple parties while in fact they’re controlled by the same entity. This is compounded by the inability of Threshold’s underlying signature algorithm to identify misbehaving signers (at least in tBTC v1), which allows for prospective attackers to remain undetected as they slowly creep into the signer set and (eventually) form a staking majority. The above is apparently of enough concern to Threshold such that they decided on launching the bridge with a permissioned signer set, in which only vetted reputable entities are allowed to be a signer — effectively making Threshold, at least at its current form, a quasi-federated BTC bridge!

But for argument’s sake, let’s assume that the bridge is made permissionless — the $T token has attained billions in market cap, and that it would be highly unlikely for any attacker to be able to accumulate $T up to 51% of the bridge’s staking composition. Even in this “endgame” state, the bridge is still throttled by capacity: user BTC deposits are only considered to be economically secure, if the signer set stands to lose more in staked collateral than what they could gain from stealing user funds across all Bitcoin deposited addresses that they collectively control.

To quantify the above, let’s imagine a scenario in which a total of $10M worth of $T is staked on Threshold. Also for simplicity’s sake, let’s assume that the signer set remains unchanged throughout. Since you need 51-of-100 for sign-off, you can say that the bridge’s economic security is worth $5.1M — this is the maximum collateral value that is available for Threshold to slash rogue stakers with. Now you can see where this goes — theoretically, once the sum of user BTC deposits across controlled Bitcoin deposit addresses has reached a total of more than $5.1M, it would become profitable for signers to collude and siphon away user funds. Although in practice the signer set won’t be fixed across multiple Bitcoin deposit addresses (to accommodate new and exiting stakers), the game-theory behind it still stands: a rogue majority of the signer set is able to compromise the bridge provided that the value of user BTC deposits across controlled Bitcoin deposit addresses is more than the staked collateral that they stand to lose.

conclusion

Other than Lightning, only collateralized BTC bridges can lay the claim that they’re truly permissionless. Unfortunately, they also carry a set of conundrums and implicit trust assumptions that exist external of the bridge itself.

The safety of CDP-style bridges are basically intertwined with the collateral makeup that they accept to back the bridge. If the bridge restricts itself to only high-quality assets (i.e. ETH), then they would need to compete with other DeFi protocols on yield to attract those said assets: why should an ETH holder deposit with you, when they can earn higher yields on other protocols?

CDP-style bridges are also highly capital-inefficient — in the case of Interlay, at least $1.6 worth of collateral is needed in order to mint $1 worth of iBTC. You can only lower the collateralization ratio down to a certain threshold: set it too low (<110%), and you’re staring at a barrel of failed liquidations and the risk of the bridge failing due to being straddled by bad debt.

There’s also the issue of oracle security. For orderly liquidations to be possible in the first place, CDP-style bridges rely on robust and accurate price feeds sourced from the oracle. Which means by default, users would need to trust the bridge’s oracle network or provider as well.

As for stake-weighted bridges, stake distribution is the make-or-break — after all, they determine who will be part of the signer set when generating the bridge’s new Bitcoin deposit addresses. Users must trust that ownership distribution of the staking token is sufficiently decentralized such that no single entity or coalition will be able to attain a majority — now, and into the future.

In addition, stake-weighted bridges are fundamentally capacity-throttled (albeit much better than CDP-style bridges) — it can only economically secure user BTC deposits up to the total staked collateral value of a potential rogue majority from the signer set. This effectively caps how much BTC can be securely stored across the bridge’s multiple deposit addresses — under no circumstances should the total value of user BTC deposits across those addresses ever exceed the total staked collateral value of the signer majority controlling them.

Representations aren’t made equal

Exiting the mainchain comes with its own sets of nuances. It is true that BTC representations external of Bitcoin will never be quite as secure as holding BTC on the mainchain, but sometimes you just don’t need that much security for your stash anyway. Not everyone here is a millionaire, y’know!

While I believe most of the BTC scaling layers and bridges that are discussed above will remain reasonably secure for the foreseeable future, I think it is important that as a self-custodial BTC hodler, you should at least be aware of the choices that you have in the market today. Hopefully through this article, the average BTC hodler is now better informed on the trust tradeoffs that exist when navigating across different self-custodial environments.

For our next article of the series, we will explore the game-changing discovery that is BitVM, a computing paradigm on Bitcoin which allows programs to be run on Bitcoin in an optimistic manner. This means it handles most computation off-chain and is therefore not hampered by Bitcoin’s limitations. However, if anyone disagrees with the result, they can raise a dispute on-chain on Bitcoin. If there’s any cheating, the fraudulent person gets exposed, and is punished. As a first step, this will enable the construction of trust-minimized BTC bridges from Bitcoin to external scaling layers for the very first time. In the future BitVM could even enable true Bitcoin rollups where transaction data is stored on the Bitcoin blockchain.

BOB’s Hybrid Chain fuses the strengths of Bitcoin’s security and EVM’s state-of-the-art tooling, inheriting the best of both worlds. Pioneering the world’s first practical implementation of BitVM, BOB will be the home for safe yet cheap bitcoin transactions and DeFi — behold native Bitcoin, outside of Bitcoin!

Sounds too good to be true? Stay tuned for Part 2 — a deep dive into BOB’s Hybrid Chain, the gateway to Bitcoin DeFi.

If you feel that I missed something worth mentioning, please reach me on X/Twitter — always open for suggestions and feedback. Also, if you found this article helpful, reposts and likes here are much appreciated!

‍