The Exchange of Immutable Bitcoin
In the ten years since I started working in the cryptocurrency industry, Bitcoin has gone from relative obscurity to almost mainstream. In ten years, it has increased 10,000 times in market value.
The world was in desperate need of limitless, unchanging money, therefore this rise was neither random nor unpredictable. Eight billion people’s need is being partially satisfied by bitcoin.
And yet, without the power to trade it, all money is nothing. Exchange must also become immutable for this reason. Bitcoin’s promise will always be compromised in the absence of immutable exchange
Change comes with baggage. The first notable venue, Mt. Gox, detonated spectacularly in early 2014, almost wiping out the sector. Numerous other exchanges have suffered similarly disastrous outcomes. Victims of these tragedies have lost billions of dollars.
These early failures were largely the result of incompetence. Thankfully, market competition has resulted in a large number of competent exchanges today. Numerous companies, including Coinbase, Kraken, Binance, Bitfinex, and others, are run well by qualified staff.
The State must always and everywhere approve of a centralised exchange. They will go toward the appearance of a bank, either slowly or fast.
The barriers of centralised custodians prevent Bitcoin’s borderless immutability, or its entire purpose.
The Walled Garden DEX
Decentralized exchange has been mentioned as a potential solution to the custodian problem as least as recently as 2014. Workable DEXs existed by at least 2017, and by the beginning of 2020, Uniswap in particular had attained an astonishing scale. DEXs were actual, not only hypothetical.
However, there has been a noteworthy drawback, particularly for Bitcoiners: up until now, DEXs have only supported Ethereum. Trading on the DEX was solely available between Ethereum and ERC-20 assets, with no notable exception (tokens that exist on the Ethereum blockchain). DEXs on the Binance Smart Chain have gained popularity recently, although they only support BEP20 assets. Only Solana assets are supported by DEXs there. All walled gardens.
Real bitcoin (or other top native chain assets) have not been able to be traded at scale in a decentralised manner.
There are “atomic swaps,” but they haven’t scaled in reality.
And yes, there is trade of “wrapped” BTC on DEXs. However, wrapped BTC equals genuine BTC.
And certainly, there are P2P exchanges like Bisq. While I’m delighted they exist, neither their volume nor liquidity are really noteworthy.
It’s been a challenging challenge to overcome, but we shouldn’t be at ease with the fact that custodians and middlemen still account for 99.99% of all worldwide bitcoin trade today. There is no immutability in this trait.
How Does It Work?
A user sends Coin A into a liquidity pool and receives Coin B when she transacts. The deposits of other users who are gaining yield (from the trading fees) by depositing make up this liquidity pool.
This concept has so far been widely adopted by DEXs like Uniswap. There are two primary user groups, similar to Uniswap:
Liquidity Providers (User Group A): These users add assets to liquidity pools, such as native bitcoin or ethereum. They receive yield in exchange for putting their assets in a bank (from the trading fees of Group B).
Users in User Group B who want to trade one asset for another, such as native ETH for native BTC, are known as traders. They send ETH and receive BTC.
The third user group, THORChain Nodes, is necessary for this to function across chains, and this is where THORChain differs from Uniswap.
Node Operators (User Group C): These users manage THORnodes, which include a node for each supported chain as well as the THORChain Node (Tendermint/Cosmos SDK). Thus, a node operator will be in charge of managing a node for Bitcoin, Ethereum, etc.
THORChain Nodes can be compared to “fragments” of a centralised exchange’s wallets.
The THORChain Nodes hold the keys in a multi-sig configuration as opposed to that central custodian (technically Threshold Signatures).
Instead of being managed by any centralised server, the liquidity pools are just decentralised node operators’ wallets.
Users are depositing native bitcoin into a bitcoin address that looks recognisable, like 3LdykT, for the THORChain bitcoin pool, for instance.
Because they are running Ethereum nodes, the validating nodes will first notice and acknowledge that ETH has been received in the ETH vault when a user converts ETH to BTC. They then combine their signatures to sign the user’s outgoing BTC transaction from their Bitcoin nodes. Any outbound transaction requires the approval of two thirds of the nodes.
There are now about 35 of these validating nodes. It is anticipated that this number would eventually surpass 100. Being a validating node merely requires you to outbid rivals for the right. Once your THORnode is operational, you can start earning money for up to a month before being expelled from the set once more (THORnodes are churning in and out every couple days).
To be a validating THORNode, one does not need a particular permission or privilege. Additionally, standard nodes that don’t sign transactions are allowed to exist in any number, making it possible for anyone to independently verify the chain data.
Is the THORChain’s collection of 35+ validating nodes sufficiently decentralised? It’s decentralised more than all the conventional exchanges that now handle 99.99% of bitcoin trading, so there.
THORChain is more decentralised than any place where native bitcoin is being traded at scale, while it is not quite as decentralised as the Bitcoin network itself.
Also keep in mind that these validators are designed to be anonymous, and that the set churns (together with the wallets) every few days to reduce the risk of jurisdictional capture and surveillance
A random subset of the total validators also signs each outbound transaction from a vault. This indicates that nobody, not even the validators themselves, is aware of who signed which transactions.
Only time will tell if THORChain’s incentive system permits it to keep a strong enough decentralisation.
Note: This model was made possible by a multi-party computation innovation that was published in 2019. Although multi-sig is well known among bitcoiners, the Bitcoin protocol only allows a maximum of 20 signers. Furthermore, multi-sig either doesn’t exist at the protocol level on some blockchains (like Ethereum) or is implemented in a unique fashion that is incompatible with other chains. TSS/MPC outperforms traditional multi-sig because it can operate on virtually any blockchain and has no technical signer cap (though performance degradation creates practical limits).
So what controls the nodes’ acceptable behaviour, then? What avoids a coin grab from the vault? Keep in mind that these anonymous node operators will have power over billions of dollars’ worth of bitcoin and other assets. Why would anybody believe them?
Bitcoin uses financial incentives to build trust between anonymous strangers.
RUNE enters the picture in this. The native coin of THORChain, called RUNE, is endowed with the ability to provide the right economic incentives. Below, we look into its mechanisms.
The RUNE Resource
A key component of THORChain’s design is RUNE. If RUNE has been constructed properly, THORChain might be successful. RUNE will not function properly if THORChain is implemented.
Supply total: 500,000,000 RUNE
Chain: THORChain (Tendermint consensus/Cosmos SDK)
RUNE plays a number of roles in the THORChain:
It is the asset in which traders pay fees and validators and liquidity providers are paid fees (LPs).
1 RUNE = 1 Vote is used for THORChain governance, which is only used to communicate the importance of assets and chains.
It is the asset that validating THORnodes are required to put up as a guarantee for the right (and duty) of validating transactions.
Every deposit from LPs must be paired with this asset. It is advised that an LP deposit $100k in BTC and $100k in RUNE simultaneously. If they don’t, RUNE will be given control of half of their assets.
Why Do THORnodes Post RUNE as Bond?
The security model of THORChain is based on proof-of-bond. It maintains the integrity of THORChain Nodes by posting bond. Actually, it severely punishes children for wrongdoing.
An quantity of RUNE that is posted as a bond that is close to two times the value of all native assets in the liquidity pools is actively encouraged by THORnodes.
The THORnodes are motivated to jointly post at least $50m of RUNE in their bond, for instance, if the liquidity pools have $25m of combined BTC, ETH, and USDT.
If they don’t, the THORChain system is said to be “underbonded,” which causes trade fees to be diverted from LPs and directed toward THORnodes instead.
This has the apparent result of making running a node more profitable and providing liquidity less profitable. Liquidity eventually decreases, and the competition among nodes increases the amount of RUNE in the overall bond. The system self-corrects when more RUNE is bonded by the nodes vying for the larger portion of trade fee money. Nature has recovered, and the faceless, profit-driven parties have once more found equilibrium.
The “Incentive Pendulum” is a mechanism that automatically adjusts the trading fee revenue between LPs and Thornode operators. It is a distinctive feature of THORChain’s design that, as far as I am aware, no other DEX shares.
In reality, the financial incentives are such that Thornodes are motivated to keep an RUNE bond that is worth twice the value of all assets put in the liquidity pools. They consequently lose $2 for every $1 they could steal, even in the worst case scenario when every node colludes.
Why Must RUNE be Paired in Each Liquidity Pool?
Each asset deposit made into a liquidity pool (such as bitcoin, ether, etc.) must be coupled with RUNE in an exact amount. Depositing $100k BTC will automatically split into $50k BTC and $50k RUNE to achieve the same economic outcome unless it is matched with $100k RUNE at the same time.
Every pool in THORChain consists of Coin X plus RUNE.
Every pool in the majority of other DEXs (such as Uniswap) is Coin X Plus Coin Y.
Why is it done this way?
For the reason that THORChain combines liquidity into N number of pools, where N = number of assets supported by THORChain, by pairing each deposited asset against RUNE (i.e., BTC+RUNE or ETH+RUNE).
10 THORChain assets equal exactly 10 liquidity pools (where each asset is paired with RUNE only).
Contrast this with the Uniswap concept, which allows any pair of deposited assets to be used (DAI+ETH, DAI+USDC, DAI+AAVE, DAI+COMP, etc.). Liquidity is divided into N different pools in this paradigm, where N is the “binomial coefficient” of the number of assets supported by Uniswap.
10 assets in Uniswap could result in 45 pools (where each asset is paired with each other asset).
Why are there fewer pools better here? Because each pool gets deeper when deposited assets are dispersed among fewer pools. For the traders, this implies less slippage, which leads to better rates, more traders, which leads to more fees, which leads to more LPs, which leads to more liquidity, and so on. This is the virtuous cycle; as the adage goes, liquidity breeds liquidity.
Given how successfully Uniswap has performed despite using a fragmented pool model, the aggregated pool architecture proposed by THORChain offers significant liquidity.
Fortunately, she can still switch between any two assets in the system from the viewpoint of a trader. For instance, she can transition straight from ETH to BTC. The transaction is executed in the background by pricing ETH to RUNE and then RUNE to BTC, but this is hidden from the trader.
Note: Bancor should be commended for being the first company to use this strategy of pairing liquidity pools with a single asset. To better align incentives and draw liquidity, THORChain adopts a similar model with a few modifications.
RUNE’s 1:3 Ratio and Valuation
LPs are required to deposit RUNE equal to 1x the value of the asset they are depositing, as was previously mentioned.
Therefore, it follows that the THORChain protocol holds $3 in RUNE for every $1 of deposited assets.
Liquidity suppliers offer…
1 Bitcoin in the pool.
RUNE for $1 in the pool
Arbitrage is utilised to enforce this.
The THORChain Nodes offer…
This is enforced through competitive bidding and the Incentive Pendulum, which is detailed above. $2 of RUNE in the bond from validators
Thus, it can be argued that RUNE is worth 3 times the total value (TVL) of non-RUNE assets in the liquidity pools of THORChain. This would be the basic value, free of any premium for speculation.
$1 billion in non-RUNE assets in the pools = $3 billion in RUNE’s base value.
But why can’t THORChain utilise BTC itself or a stable coin instead of this new asset RUNE as collateral?
The sceptics should inquire into this right away. Why use a token?
In order to address an exogenous Sybil Attack issue, THORChain needed to employ its own asset (RUNE) rather than an external asset (such as BTC, ETH, or USDT).
The security of the network, more specifically the security of the liquidity pools, is affected by this Sybil attack.
Let’s think about two situations that both share the following circumstance:
The liquidity pools for THORChain hold $1 billion (across BTC, ETH, USDC, etc.)
Attacker seeks to take over the network in order to steal these assets.
Scenario 1: An other universe in which BTC is utilised as the stake rather than RUNE
The $1 billion liquidity pool consists of
$500m in several crypto assets
$500 million BTC in each pool
The incentives require THORChain Nodes to submit a $2 billion bond in Bitcoin.