It Was Almost Impossible to Keep Up With all the Bitcoin-on-Ethereum Efforts ––Until Now
The ultimate cross-chain primer, by Andrew Kang

Camila Russo
Apr 20



Hello Defiers! One of the biggest themes in decentralized finance this year has been the growing number of efforts aimed at bringing Bitcoin to Ethereum. Bitcoin on DeFi would potentially increase liquidity, boost the number of users, provide Bitcoiners access to all the different financial applications on Ethereum without giving up their Bitcoin, and give Ethereans exposure to Bitcoin investments without leaving DeFi. But it’s a challenge because most of DeFi is built on Ethereum, which means DeFi apps can only interact with Ethereum-based tokens, not with Bitcoin.

Builders are getting around that dilemma by creating Ethereum tokens which are backed by Bitcoin or concocting “bridges” connecting the two chains, in so many different projects that it’s hard to keep track… until today! Andrew Kang, a venture investor and analyst deep in the crypto space, has compiled these efforts in the ultimate Bitcoin-to-DeFi primer. You’ll get the pros and cons of Bitcoin tokens and bridges including by Ren, Synthetix, Keep, pTokens, and TokenIon —the team behind imBTC, the token at the center of last weekend’s hacks on LendfMes. And see where the fall in the decentralization and scalability scale.

I’ve been wanting to see something like this for a while, I’m sure many of you have too! Hope you enjoy :)

Both paid and free subscribers receive full guest posts, but paid subscribers get them hours early. Paid subscribers also get complete access to The Defiant content and archive, and access to the subscribers-only Discord chat —here’s the link!

🙌 Together with Ampleforth, a digital asset protocol for a base money which doesn’t require collateral and is uncorrelated with the rest of crypto.



The Cross-Chain Pegging Dilemma
By Andrew Kang, for The Defiant

The holy grail of DeFi has always been the integration of Bitcoin. In the much larger CeFi market, Bitcoin and USDT dominate the volume — From spot exchange, to borrow/lending, to derivatives trading. While Ether as a collateral base has allowed DeFi to achieve impressive credit market growth, incorporating Bitcoin would unlock a market an order of magnitude larger.


https://reports.credmark.com/TheCryptoCreditReport-q4-2019.pdf

The commonly proposed approach is creating an ERC20 token pegged to the value of Bitcoin. The benefits of an ERC20 pegged bitcoin is that it takes advantage of composability — the ability to be easily slotted into current DeFi protocols without major architectural changes to the underlying applications. There are many pegged BTC projects currently in development, but the only live implementations today that are currently interoperable with DeFi are centralized custodial solutions (wBTC, imBTC).

Pegged BTC projects that operate with a less centralized, permissionless model include tBTC (Keep Network), sBTC (Synthetix), renBTC (Ren), and pBTC (ptokens). All of these projects back their version of pegged BTC through collateralization, but have different security and pegging models. The different models used in these assets having different trust and scalability properties.

Trust
All of these tokens, except for sBTC, are backed by actual BTC (from the Bitcoin blockchain) managed by one or multiple entities. In order to ensure full collateralization of pegged BTC, the BTC used as collateral must be sent to Bitcoin addresses custodied by either a central party, or a group of parties (i.e. validators). In order for these projects to function, there must be an element of trust to ensure that the party(s) managing the system act as intended.

There can be multiple components in a project where trust is required, and the amount of trust required can vary. For imBTC and wBTC, the trust is centered around the BTC custodian. For pBTC, renBTC, and tBTC, a set of validators must coordinate in order to perform the necessary functions of a pegged system — namely mint, burn, and secure assets. They must reach consensus on their collective actions, and the various approaches in how they reach consensus result in different trust assumptions. Price feeds, which can vary in their trust assumptions, inform functions within the system (e.g. liquidations, minting/burning fees, collateral maintenance, etc.) With this in mind, these pegged BTC projects can be said to fall on a spectrum of decentralization.


The degree of decentralization can roughly be determined using a framework analyzing the trust elements of custodianship, consensus mechanism, and price feeds for each project.

imBTC
Custody— custody of BTC backing imBTC is managed by TokenIon, a startup with low-moderate risk of default. On-chain proof of reserves.

Consensus Mechanism — Pegging in and out is permissionless and managed by an Ethereum smart contract, but TokenIon essentially controls the bridge between Bitcoin and Ethereum.

Price Feed — There is no price feed since the bridge is centrally controlled.

wBTC
Custody — custody of BTC backing wBTC is managed by BitGo, a reputable digital asset custodian with $1B assets under custody and partial insurance coverage. Regular proof of reserves.

Consensus Mechanism — Pegging in and out is permissioned and can only be initiated by registered “merchants” that have completed KYC/AML. BitGo essentially controls the bridge between Bitcoin and Ethereum.

Price Feed — There is no price feed since the bridge is centrally controlled.

pBTC
Custody— pBTC smart contracts are non-custodial for deposits and withdrawals. The centrally managed admin key maintains the ability to fully upgrade the system. The long-term plan is to move towards a DAO model.

Consensus Mechanism — BTC address(es) managed by a network of validators running TEEs (Trusted Execution Environments) and coordinating via Threshold Signature Schemes (TSS). TEEs allow for computations to be run securely, but this results in trust shifting from the validators to the tech manufacturer(s) responsible for producing TEE hardware.

Price Feed — Since validator bond and slashing amounts are not proportional to BTC secured, no price feed is required.

renBTC
Custody — renBTC smart contracts are non-custodial for deposits and withdrawals. Admin key configuration is currently unknown.

Consensus Mechanism — Validators execute transactions via a newly developed multi-party computation algorithm: “RZL sMPC”. RZL utilizes Shamir secret sharing (SSS), which traditionally has been criticized for “dealer” trust requirements in which the private key is generated and distributed by a dealer. However, this algorithm was designed to never centralize private key/secrets, unlike traditional SSS. RZL sMPC is currently undergoing an audit and has not yet been tested in a full production environment. In order to disincentivize bad actions (e.g. stealing collateral), Ren validators for each shard must collectively bond greater than or equal to 3x the value (in REN token) of the BTC secured in each shard.

Price Feed — Ren utilizes dynamically adjusting minting and burning fees. The fees are calculated based on the following formulas and inputs:

“Minting fees are defined by the curve fee(k, a, x) = k^(1-x^2) where k=0.0001, a=2, and x=3L/R"

“Burning fees are defined by the curve fee(k, a, x) = k/(x+1)^a where k=0.0001, a=2, and x=3L/R"

L is the total value of BTC locked, and R is the total value of REN bonded in the BTCEthereum shard

A price feed should be necessary in order to determine the values L and R , however, the Ren team has denied the necessity of a price feed. They have claimed that these values can be determined by the income of the darknodes (validators).


We can model an expected value of REN compared to the assets moving back and forth. RenVM already knows the fees it’s earning, so it can calculate what a “stable” value of REN is (not including speculation). It can use this calculation (based on fees alone) to determine the “value of REN denominated in the assets being shifted around”.

In order for REN and BTC value to be determined, darknodes need to agree on a set valuation formula for REN based on the BTC income produced. Herein lies the problem — value is subjective. It is not rational for “REN valuation formula” to be hardcoded as different market participants have different expectations for income, risk, cost of capital, etc. What this means practically is that one darknode owner may value their REN at 5x system income, while another values theirs at 100x system income. The degree of decentralization for Ren can’t be determined until a price feed mechanism is produced.

sBTC
Custody — sBTC is backed by SNX locked by the non-custodial SNX token smart contract. However, the SNX smart contract ecosystem is fully upgradeable and managed by a centralized admin key.

Consensus Mechanism —sBTCis overcollateralized with SNX, an ERC 20 token, so sBTC can piggyback off of Ethereum’s security model instead of requiring a unique security mechanism to secure cross-chain collateral. However, trust is still required in both the safety of the smart contracts and that the system will be able to prevent sBTC from becoming undercollateralized.

Price Feed — Synthetix price feeds are managed by a centralized closed source oracle system, but is moving towards a more decentralized approach utilizing ChainLink.

tBTC
Custody — Smart contracts are non-custodial for deposits and withdrawals. The admin key has control over (1) emergency one-time 10-day pause (2) time-delayed fee rate setting (3) lot size setting (4)collateral threshold setting. These privileges only affect new deposits and have an upper and lower bound set in the contract.

Consensus Mechanism — Validators coordinate to sign transactions using multi-party Threshold ECDSA without a trusted dealer. In order to disincentivize bad actions (e.g. stealing collateral), tBTC validators must bond 150% of the BTC value secured in ETH.

Price Feed — tBTC plans to use a semi-centralized price feed operated by MakerDAO for v1. MakerDAO price feeds are managed by a consortium of addresses voted on by MKR holders. Keep plans to introduce a new price feed mechanism for v2, but details have not yet been released

Scalability
Similar to falling on a spectrum of decentralization, these projects also fall on a spectrum of scalability. In fact, we find that scalability is inversely correlated with the degree of decentralization.

This inverse correlation is due to the fact that more decentralized systems come with more implicit costs. Maintaining a bridge between two blockchains requires a new security model to ensure that the bridge is properly maintained. The costs required to maintain the bridge need to be born by some party, whether it’s minters, validators, holders, etc. and in turn can lead to additional friction in the pegged product.


imBTC — The supply of imBTC can quickly grow with demand since the creation of imBTC is permissionless. TokenIon also incentivizes imBTC supply growth by charging a 0.3% fee whenever imBTC is purchased from Tokenlon DEX and distributes this to imBTC holders.

wBTC — The creation of wBTC is semi-permissioned, but approved merchants are incentivized to quickly initiate the minting of more wBTC to arbitrage price increases of wBTC compared to actual BTC. This is similar to how USDT has been able to massively scale with a permissioned minting/burning mechanism.

pBTC — The supply of pBTC can quickly grow with demand since the creation of pBTC is permissionless.

sBTC — The supply of sBTC is constrained by the total synth supply in the Synthetix ecosystem. Synth supply is constantly readjusted to balance with synth demand. Synth demand is a function of synths demanded for trading with synthetix exchange plus synths demanded for trading within Synthetix Exchange. Since sBTC is collateralized by SNX, it is also constrained by the value of SNX. The value of SNX is a function of expected future Synthetix Exchange transaction fees.

renBTC — The amount of renBTC that can be secured is constrained by the value of REN, since Ren always enforces L < R/3. In the long run, the value of REN will be dictated by the minting, burning, and continuous fees accrued by the darknodes (i.e. highly uncertain). Fees faced by holders & minters of renBTC create additional friction for renBTC usage and supply growth

tBTC — The creation of tBTC is permissionless, but the supply of tBTC is limited by the amount of ETH that validators are willing to bond. In the short run, this amount will be bootstrapped via a Keep Network subsidy. However, in the long run, it is likely that the revenue produced by tBTC signers (compared to the cost of capital) will be a major hindrance to tBTC scalability.


tBTC signers earn a signing revenue of 1.875%. After considering a 150% over-collateralization ratio, this comes out to a 1.25% yield. Given that borrow rates for ETH range between 2% — 10%, and the expected yield from Proof of Stake is expected to be between 2–6%, it would not be economically rational for most potential signers to contribute ETH to secure tBTC. There is also friction on the creation side considering minters need to pay fees. In comparison, minters of imBTC, wBTC, pBTC, and sBTC do not face fees.


Kava
Kava is a project building a cross-chain CDP platform. Similar to the pegged BTC projects discussed, its protocol design involves creating pegged versions of other cryptoassets on Kava’s chain. Kava may fall in the middle of the decentralization spectrum, and on the left hand side in terms of scalability.

While Kava uses a set of validators to coordinate cross-chain transactions, the pegging functionality within Kava relies heavily on a centralized relayer called the “deputy” which has full control over deposited funds used for creating pegged tokens. For cross-chain security, Kava uses Tendermint based consensus which is also used for chains such as Cosmos and Binance Chain. Tendermint based consensus allows for delegation of base layer assets to validators. This poses a security/decentralization risk since validators that are able to attract significant delegation may have outsized power in consensus compared to the assets they are personally risking. Kava relies on Chainlink for Price data.

In terms of scalability, the amount of CDPs that can be managed by Kava is constrained by the value of the KAVA token. KAVA acts both as the bonded collateral that provides security to the system, as well as a token that accrues value based on the income generated — similar to Ren.

The following economic conditions can be assumed based on conversations with the Kava team and observations of the MakerDAO system:

200% CDP collateralization ratio

3:2 KAVA to CDP value ratio

5% Average long term stability fee

Target savings rate of 50 bps below the stability fee

25% of USDX supply deposited for savings

100% Long term Kava staking rate

These conditions imply that for $15M of Kava, there will be $10M of CDP assets, and $5M of USDX. The $5M of USDX at a 5% SF rate should produce $250k in annual fees, with $56,250 going to USDX savers and $193,750 going to Kava validators. This implies a 1.3% yield on capital for KAVA stakers. An average 10% long term stability fee implies a 2.5% yield on capital. Given this low asset productivity for validators, it is likely that in the long run, KAVA will equilibrate serving a niche market at a relatively high stability fee while providing low-moderate yield for KAVA stakers.

ThorChain
Thorchain is a project building a statechain that facilitates cross-chain liquidity pools without pegged tokens. The first iteration of Thorchain derives its security from a cross chain auto market maker (AMM) exchange. In oversimplified terms, it can be thought of as Uniswap type model working across Bitcoin, Ethereum, Binance Chain, etc.

Similar to REN and KAVA, the native asset of Thorchain, RUNE, is used as the bonding asset for validators and derives its value from system income accruing to the token. Exogenous income is primarily derived from exchange transaction fees, thus, the greater the expected value of transaction fees, the greater the value of RUNE and assets that can be secured by the system.

Thorchain breaks the inverse correlation between scalability and decentralization as it is architected to be both highly decentralized and highly scalable. It is able to accomplish this through a capital efficient design without pegged tokens. In Thorchain, the assets secured by the system are those placed into the liquidity pools which serve as market making assets and directly produce income. The transaction fees produced through a swap feed both the liquidity providers and the validators.

Thorchain deposit addresses are non-custodial and maintained by a rotating validator set with overcollateralized bonds. Thorchain consensus is achieved via a Gennaro Goldfeder TSS based system which removes central points of trust, similar to tBTC. Since the AMM exchange is central to Thorchain’s architecture, it is used as a trust minimized price feed for the system.

Conclusion
I hope this piece served as a good primer on the tradeoffs faced between these different cross chain systems. The respective teams have put in a remarkable amount of work designing and building these projects. Remember that they are all still experimental and subject to future iteration as project teams find ways to improve their system design. This piece should serve as a non-comprehensive overview of these incredibly complex systems.

Feel free to reach out to me on Twitter at https://twitter.com/Rewkang for further discussion.

Thank you to Thomas Bertani, Loong Wang, Scott Stuart, Kevin Davis, Yan Liberman, and Matt Luongo for helping with my research when writing this article.