Value bridged versus value locked

Unlocking economic scalability

tBTC brings censorship-resistant, physically-backed tokenized Bitcoin to DeFi, but it isn’t the only project working to give Bitcoin super-powers. Projects like Thorchain and RenVM are building bridges to Bitcoin and other networks from Ethereum and Cosmos.

All of these projects rely on a simple idea. Mutually validating consensus isn’t possible with Bitcoin, today; and changes happen on Bitcoin very slowly. Instead, we’re all building bridges using additional collateral to secure the bridged BTC. Thorchain uses RUNE, RenVM plans to use REN, and tBTC uses KEEP and ETH. By holding additional collateral on Ethereum and Cosmos, these projects can ensure their custodians follow the rules of the system.

Unfortunately, this additional collateral can quickly become a bottleneck. tBTC has struggled to scale without more ETH, hovering at $300M TVL. RenBTC hasn’t struggled to scale, and has instead had to relax its security model, remaining heavily undercollateralized and relying on centralized custody to ensure security.

The core issue is this: to scale a Bitcoin bridge, we need an economic mechanism that doesn’t rely 1:1 on outside collateral.

Two alternatives present themselves today.

Liquid, the Bitcoin inter-exchange settlement network by Blockstream, is one alternative approach. Liquid is built on a federation of known members. Anyone who uses Liquid and is defrauded can actually sue someone, since there is a known, permissioned set of custodians. While the custodians operate across a few different jurisdictions, there are so few that they can’t be made censorship-resistant. While imperfect, the insight here is that custodians are using their reputations and potentially their balance sheets as collateral against deposits.

Another approach goes by a few names: trusted hardware, trusted execution environments (TEEs), secure enclaves, or hardware security modules (HSMs). The idea is to use these trusted modules to secure private data in a way that prevents operator tampering.

Unhappily, in practice, this turns out to be a false sense of security. HSMs have been broken many times, and a growing permissionless network with a huge amount of value locked is also growing the bug bounty for breaking one of these elements. In addition, there are only a few reputable HSM providers — meaning only one or two entities need to be compromised in order to break the network’s security.

For this reason, today’s professionals working on adversarial networks like Ethereum, Bitcoin, and Zcash, prefer multiparty computation, homomorphic encryption, or zero-knowledge proof systems to trusted hardware. The false sense of security and huge number of trusted hardware hacks even led to Keep’s motto: “Trust math, not hardware”.

Another approach — embracing an honest majority

tBTC v1 has been running smoothly since September. All tBTC is backed by real bitcoin, held in the decentralized Keep custody network. The system is further over-collateralized by the nodes themselves, which self-insure against fraud, putting down 150% the BTC value they defend in ETH.

We’ve learned a lot since September. The system works beautifully, but the economic constraints are real. We know that we need better capital efficiency. We know that staking reputation is a step backward toward fiat, and that relying on secure hardware is an attack vector. And we know that the majority of stakers are honest, and are looking out for their own interests, as well as those of the network.

No staker has acted maliciously on-chain in the history of the network. In fact, many have acted altruistically, coordinating to recover funds when users have made mistakes. While we can’t rely on every participant acting honestly, we can introduce an assumption in v2 that’s common in other areas of cryptography — an honest majority assumption.

The idea, relied on frequently in multiparty-computation and consensus schemes like Bitcoin and Ethereum, is simply that a majority of stakers are honest. These stakers will follow the protocol faithfully, and while they aren’t altruists, they won’t actively collude to undermine the security of the system.

If we assume, say, a 2/3 honest majority across all stakers, we can re-architect tBTC

• Instead of 3-of-3 wallets, we move to 51-of-100.
• Instead of a wallet per deposit, we generate a new wallet roughly each week.
• Instead of asking stakers to put down KEEP and ETH, we only ask them to stake KEEP.

Now, we model the likelihood of a wallet being controlled by a malicious majority. Assume 1,000 stakers. We need to pick 100 stakers, randomly, for a new wallet.

Recall from highschool probability that we’re picking “without replacement”. Once a staker has been picked for a new wallet, we don’t want to pick them a second time. This scenario is modeled by a hypergeometric distribution.

If 51, 52, 53, and so on malicious stakers are chosen, up to 100, we know that a wallet is compromised. That makes it clear that we should be looking at the cumulative probability distribution function, which for 100 stakers sampled from a 1000 staker population, with 1/3 malicious, yields a 0.0087534% chance of the wallet being captured by a malicious majority.

If wallets are generated weekly, that means that for 52 wallets generated a year, there’s a

(1 + 0.000087534) ^ 52–1 = 0.45619% chance of a wallet being compromised over a year.

Not bad! But also not risk free.

If we increase the number of stakers per wallet, or the required signing threshold, this probability plummets further. And while the risk is vanishingly small, it’s never 0 — an attacker could always buy a third of the active staking slots, and eventually compromise the system.

To offset the small risk to the peg, we introduce an additional idea — a backstop. Coverage pools, first deployed against tBTC v1, are perfectly suited to insure against fraud in tBTC v2. Assuming each wallet receives the roughly the same amount of deposits, a coverage pool holding 0.45619% of the total market cap of tBTC can cover the risk to user funds over an entire year.

Now, we have a new, scaleable architecture. The last missing component is governance — a body to watch over the system and ensure parameters are adjusted to match market activity. As new stakers come online and technology improves, governance can grow wallet size, signing thresholds, wallet frequency, and a number of other knobs to optimize security.

What’s next?

Short of a Bitcoin hardfork, we believe a staker honesty assumption is the best possible approach to scaling trust-minimized Bitcoin bridges on Ethereum and other smart chains.

Over the next two quarters, we’ll develop tBTC v2 in public. Unlike tBTC v1, the code won’t be immutable at the start; instead, we’ll work hand-in-hand with community governance to build and optimize a secure, permissionless, capital efficient bridge to bring Bitcoin to DeFi.

Does this approach sound interesting? Join the community and get involved at chat.keep.network.