Thorchain Analysis and Valuation

By Joe Kendzicky, James Todaro and Joseph Todaro

Overview

Thorchain is a decentralized cross chain settlement layer that allows value to be transferred across blockchains. Similar decentralized exchanges (DEXs) like Uniswap and Sushiswap exist, but are deficient due to the fact that they are smart contract logic resting on top of an existing L1 protocol—thus limiting the scope of swap functionality to tokens within a particular blockchain. For example, on Uniswap, the Ethereum blockchain handles the networking/consensus layer for transactions, thereby underwriting the security of the application. However, this means that interoperability of swaps is limited to ETH and other ERC-20 tokens only. The same dilemma exists for DEXs built on top of Binance Smart Chain, Solana, etc. The revolutionary component of Thorchain is its cross-chain liquidity features, which allow token exchange across siloed blockchains. Furthermore, it does so not by wrapping assets (e.g. 2-way pegged sidechain model exhibited in REN protocol), but instead directs transfer of native tokens on the native chains). 

Thorchain’s advantage is that it marries advantage of cross-chain capabilities of centralized exchanges (CEXs) with the user-controlled, decentralization of DEXs by differing from centralized exchanges (CEXs) in three notable ways:

1. Instead of using a central limit order book (CLOB) as a means to achieve asset price discovery and accompanying asset swaps, the protocol uses an AMM model called Continuous Liquidity Pools (CLPs).

2. Instead of the exchange being the trust intermediary and handling private key management, keys are distributed and delegated across a set of nodes. Transmission of funds in the system requires consensus from 2/3rds of the node operators who are economically incentivized to act in accord with the protocol rules, lest they risk getting their bond deposits slashed.

3. The native token RUNE exists as the base pair between all asset pools.

Herein, we detail the mechanics and technical design of the Thorchain platform followed by a token price model accounting for the value capture of Thorchain’s token, RUNE.

---

Mechanics

The system initializes with liquidity. Like many other decentralized exchanges, Thorchain builds off the model of Liquidity Pools, where entities can deposit idle capital into said pools and become passive market makers. This capital provides a foundation for traders to swap tokens against. Liquidity Providers consent to their capital being managed by a deterministic algorithm, defined and run by the protocol, which tenders liquidity to traders on a continuous basis. Each swap levies a fee on the trader, which is then kicked back to the Liquidity Providers. Accrued transaction fees provide a yield incentive for liquidity providers to deposit capital into the system.

Here’s where things start to vary with the Thorchain model. Uniswap, Sushiswap, Pancakeswap, etc. are merely smart contracts built on top of pre-existing L1s. All logic, execution and security is derived from the base layer. This is friendly from a developer standpoint—they can simply write a couple hundred lines of code, deploy it on Ethereum, and have backend infrastructure and maintenance automated for them. However, this creates its own set of dynamic challenges as the base layer execution tends to not always be optimized for the applications built on top of it. A notable example of this is miner extractable value (MEV) in Ethereum (discussed in depth later).

Architecture

Thorchain is an application specific, customized blockchain built using the Cosmos SDK framework. As a brief overview, a blockchain at its most basic definition is simply a database replicated across many nodes. There is a deterministic protocol that allows the database to transition from one state to the next, allowing the database to remain synchronous across all nodes in the network. A blockchain can be broken down into three primary components:

Application layer - Defines state logic and submits the transactions. When processed, these transactions ultimately lead to a state transition. 

Network Layer - Broadcasts transactions initiated by one node to the rest of the network. It is the delivery system that calls a state transition into process

Consensus - Ossifies the state transition performed by the application layer into permanency. Consensus is the judge and jury of the blockchain. It ensures that any and all state transitions acted in accordance with the ruleset of how a transition is to occur, safeguards against forged transactions, and prevents machines from rolling back or hiding transitions that occurred. 

Both Bitcoin and Ethereum see their three layers intertwined. In fact, this is the general maxim of almost all blockchain systems until recent years. Let’s look at Ethereum. The Ethereum selling point is that, as a general purpose virtual machine (VM), developers can write a smart contract that encompasses the entirety of the application layer, and deploy it onto the network. The consensus and networking backend components are extracted away, allowing developers to concentrate their focus on what they do best: writing code. This can be highly beneficial as it saves hundreds of hours writing backend solutions to navigate these complexities, as well as natively bootstrapping consensus security. However, the drawback is that the application layer is ultimately bottlenecked by the consensus + networking components. Consensus in PoW based systems like Ethereum are computationally expensive, slow and highly limited with respect to scalability. This directly hinders the application’s ability to perform high degrees of throughput, and potentially leads to a negative user experience, depending on the objective the application is trying to facilitate. 

Cosmos SDK isn’t itself a blockchain, it’s merely a toolkit that allows developers a convenient method to plug and play different modules, creating a customized blockchain from scratch. Cosmos is able to facilitate this by separating the application layer from the consensus and network layers—the latter being referred to as Tendermint Core. 

The consensus layer is powered by Tendermint, a Byzantine Fault Tolerance (BFT) consensus algorithm considered to be the ‘gold standard’ for proof of stake blockchains. Developers have the ability to import their own native BFT consensus algorithm (most will choose to use Tendermint, as does Thorchain). Tendermint provides advantages to PoW based consensus mechanisms in that it has deterministic finality, energy efficiency, faster performance and accountability. Downsides include requiring a known validator set, less decentralization (scalable up to ~100 validators), and inability to guarantee liveliness.

The application layer is where you see wide divergence from one Cosmos blockchain to the next. Cosmos SDK lets you outfit the state machine that’s being operated by the nodes. SDK gives you tools required to define the state transition process, what the application’s state intrinsically looks like, transaction format, etc.  

The application itself is broken down into components called stores. These stores operate together to make up the functional component. An analogy: the body is the application, and the brain, lungs, heart, etc. are different stores. Each store is powered by a module; thus each module essentially is a fractional component of the state, and these fractional state components comprise the full application. The unique feature is that these modules are customizable by the developer as they can utilize pre-configured modules developed by the Cosmos team (or other community contributors), or craft their own. 

Additionally, the SDK and Tendermint Core components are tethered by the application blockchain interface (ABCI). The ABCI is a translation mechanism for the application code to be delivered and executed on by the consensus and networking layers. This is powerful because it means the application can be written in any language, making the barrier to entry lower for building such applications, providing access to leverage existing toolkits, and not requiring a native language from scratch. 

Overall, because each SDK chain is independently constructed, upgradeability and governance of the system is very easy, and the application in which the blockchain was ultimately designed for are highly optimized for its particular use-cases. This is contrary to predominant general purpose VMs like Ethereum where the applications built on top are crafted in a manner that conforms to existing consensus/networking stacks. 

The major tradeoff here comes in the form of network security. These SDK chains are forced to bootstrap their own validator sets and economic capital. This is different from Ethereum based applications that can piggyback off Ethereum’s security with high guarantees of assurance due to the size of its network and the total capital already at play underpinning it. 

We believe the tradeoffs incurred by Thorchain, as an application specific blockchain, was a sound decision based on the utility provisioned (cross chain liquidity pools).  Such logic is expounded upon below:

MEV and Front Running Attacks

Miners ultimately hold discretion over transaction ordering within a block they produce, and are not bound by any time-related sequential properties (FIFO, for example). In bitcoin, miners are incentivized to prioritize transactions with the highest transaction fee to extract the most economic value for themselves. This property holds in Ethereum as well but with far greater complexity as DeFi–related transactions hold additional (and oftentimes considerable) financial value within the transaction logic. The problem is that the details to this transaction are transparent to the entire ecosystem, allowing for front running, arbitraging, manipulation, etc. by the miners who are in charge of the ordering process. For example, say you were to issue a market buy order of token X @ $50 on a decentralized exchange. A frontrunner could see your transaction enter the mempool, and in response, copy the transaction’s financial details, attach a slightly higher transaction fee to get included in the block before yours, resulting in a poorer execution price at your expense, and an instant gain for their position. These attack vectors have become increasingly problematic with procedures like sandwich attacks and other sophisticated techniques.

These frontrunners initially emerged as arbitrage bots run by general traders, with miners acting as indirect beneficiaries due to competition between bots bidding up gas fees, but has recently devolved into the miners running the arbitrage strategies themselves. As the Flashbot team describes, this is particularly dangerous as such infrastructure “erodes the neutrality, transparency, decentralization, and permissionlessness of Ethereum today.” 

Thorchain tackles this dilemma by altering protocol rules for transaction sequencing and execution by using the SDK toolkit. By protocol rule, all transactions enter the swap queue where they inevitably will be processed by the network. As a brief overview, transactions in the queue are ranked by potential fee and slip incurred, and executed by highest rank. Higher ranking slip-fee TX’s will be executed before lower ranking. Slip-based fees just force a participant to share the profits of an arb op with LPs. If they can make 100 BP on an op, they can profitably arb all the way up to a 99BP fee (to LPs) and walk away with 1 BP. Market competition drives this. These forces ultimately prevent arbitrageurs (both general trading bots, as well as nodes) from front running transactions. It also is a driving mechanism that reduces impermanent loss for LPs. More on that later.

Another point of consideration is that Thorchain ultimately serves as a middle layer between two independent blockchains (BTC and ETH when a user swaps, for example), which allows many of the valuable features built on general purpose VMs like Ethereum to be harnessed to their full potential.  Strong settlement assurances (no rollbacks, double-spends, etc.) can be attached to a blockchain that encompass a tremendous amount of economic value; however, in order for the strong assurances for a proper cross-chain swap, you need both assets in question to carry such features. What happens if you are swapping ETH for Coin X, your ETH TX settles, Thorchain processes the logic of the swap exactly as it should, but down the road Coin X is reorganized and never ends up reaching you? At the end of the day, a portion of the integrity of the swap is out of the hands of the Thorchain protocol (though they do their best to mitigate this issue, as we describe later), and thus the tradeoff for other application/consensus optimizations (throughput, propagation, transaction ordering, etc.) makes sense. Additionally, the team has been able to bootstrap considerable economic security thus far, due to a clever tokenomics design, as described below.

Token Model

The RUNE token is intrinsically baked into both the liquidity provisioning of the protocol. It also underpins the economic security model that allows the system to function. 

Node Bonding - As discussed previously, nodes play a pivotal role in asset custody. Both LP pooled capital, as well as traders swapping assets in the system, ultimately end up in the vaults of the private keys that the nodes manage. In addition, nodes validate Thorchain blocks, which is the state transition mechanism that ultimately moves capital from party A to party B. The RUNE token is interwoven into the economic security model. To deter nodes from colluding and stealing LP/swapper capital that is locked up in the vaults, nodes are required to stake RUNE collateral in an amount proportional to that of the total value locked in liquidity pools. For example, if there was $1M of total value in the pools, nodes would need to collectively bond, at minimum, an additional $1M of RUNE, leaving the total economic value within the system at $2M. This deters any financial incentive for nodes to collude, because the EV of the attack would net out to 0.

Liquidity Provider Pooling - RUNE also acts as the base pair against all external assets in the trading pools. If a user wants to swap BTC to ETH, they do so by trading BTC for RUNE in the BTC/RUNE POOL, then taking the RUNE proceeds and selling against RUNE in the ETH/RUNE POOL. This means that in the liquidity pools specifically, 50% of the total capital is RUNE and 50% external assets. Referring back to our analogy above, if $1M of RUNE is bonded by the nodes, and $1M in the liquidity pools, then of that $1M of the LP capital, $500k will exist as RUNE and $500k as external assets. 

In the end, for each $1 of non-RUNE assets tied up in pools, $3 of RUNE will be bonded alongside it. 

System Income

Like any blockchain system, transactions in the Thorchain network are bundled into blocks, and these blocks added to the chain tip where they are then attested to by validators. Thorchain works the same, except these transactions encompass various system logic that ultimately alter network state. A thorchain transaction essentially is a historical archive of protocol activity. Every swap, every LP deposit, every single activity in the system is transcribed somewhere in the ledger, allowing full auditability of system events since inception.

Monetary rewards are attached to the creation of each block, just like in bitcoin. However, instead of rewards being captured solely by miners, rewards in Thorchain are split between LPs and nodes. At the heart of these capital flows lies the system reserve. We can think of the reserve as a quasi-balance sheet for the RUNE protocol.

The reserve generates income: fees and charges generated from various services that the protocol provides. It also has expenses: costs that are accrued when producing that service.

Digesting the above diagram, it’s important to note that after a node generates a new block, the only ‘expenses’ paid out from the reserve are the swap fees from that particular block, and the inflationary block reward. All other income (outbound TX fees, node slashing penalties, etc.) remain in the reserve. Likewise, alternative ‘expenses’ are not regularly recognized, as they are variable costs rather than reoccurring. This means that the total size of the reserve can grow over time if the alternative ‘income’ source is greater than the alternative ‘expenses’. 

Turning to our regularly realized expenses, swap fees and inflationary block rewards, swap fees are distributed to pools on the basis of swap activity that occurred in that particular pool during that particular block. For example, if the RUNE/BTC pool generated 50% of the swap fees in block #500, then the reserve will pay out the pool 50% of the accrued fees from block #500. Scheduled inflation rewards are paid out pro rata to each pool, depending on the depth of the pool across the total depth of the network. So, if the RUNE/BTC pair comprised 20% of Thorchain’s total liquidity, the pool would get 20% of the scheduled reward.

Under normal conditions, nodes will receive 2/3rds of system income of total block rewards, while LPs will only receive 1/3rd of block rewards.

Slashing points are assessed on nodes when they violate various protocol rules (don’t process outgoing transactions, vote against consensus, refuse to vote during consensus process, etc.).

LPs can never incur slashing points, as they do not maintain a position of responsibility within the network. They will only accrue system income, and are never subjected to slashing. LPs are susceptible to impermanent loss, but the protocol offers impermanent loss protection on a sliding scale up to 100 days for symmetrical deposits. This means that after day 1 the LP would have 1% insurance protection, on day 2 they would have 2% insurance protection and so on up to full coverage after 100 days. This guarantees that LPs will never be better off holding their assets in cold storage versus taking their idle capital and tendering it as protocol liquidity. The insurance program is backstopped by the reserve, but the team is so confident in their slip-fee CLP algorithm that expectation of having to apply coverage to any particular LP is very low.  As we will discuss later, the slip-based fee is a feature pioneered by Thorchain which maximizes transaction fees paid to pools, and reduces impermanent loss more so than the common fixed-fee model exhibited by Uniswap, Sushiswap, etc.

Incentive Pendulum

The incentive pendulum is a self-regulating security mechanism baked directly into the protocol. The bitcoin protocol can internally assess and modify the difficulty adjustment in order to respond to changes in aggregate hashrate. Thorchain performs a similar internal processing feature with its subsidy allocation from the reserve. There are 5 potential states that the system can exist in:

1. Steady state

2. Under-bonded

3. Insecure

4. Over-bonded

5. Inefficient

As mentioned earlier, the ‘steady state’ exists when for each $1 of external assets in the system, $3 of RUNE is locked up alongside it (50% RUNE bonded by nodes, 25% RUNE matched with 25% external assets by the LPs). 

If the amount of RUNE bonded trends into insecurity range (e.g. there is more capital staked in the pools than bonded by the nodes), the system is considered insecure and potentially vulnerable to attack, as nodes could have more to gain by colluding and stealing external assets under their custody. So, the protocol will algorithmically begin diverting block rewards away from LPs and allocating the difference to node operators. This increases the yield to node operators, incentivizing them to stake more RUNE and bring the security back into equilibrium. Simultaneously, it diminishes LP yield, deterring new LP capital from allocating into the protocol, and even pushing existing LPs to withdraw funds, again bringing the system back into equilibrium. 

Likewise, if the amount of RUNE bonded trends into an inefficiency state, the system is considered inefficient, because the capital securing pooled assets is greater than those assets are actually worth. The protocol will perform the reverse mechanism described above (pull yield from node operators and allocate it to LPs, incentivizing new LP inflows and deterring new node inflows).

Nodes will receive 2/3rds of system rewards and LPs will receive 1/3rd when the system is in steady state. Again, if the value diverges from this threshold, the protocol will algorithmically divert rewards accordingly:

Below lies an example of the algo calculation under steady state parameters:

Fees

Various fees are levied on swappers when they transact through the Thorchain network. While users look to minimize costs on their traders, fees are a critical component to maintaining AMM protocols, as they are the mechanism that keeps LPs locked in to provide liquidity to the system. A well designed protocol looks to maximize revenue for its agents who are providing this valuable service.

If we think about it at a high level, a DEX is no different than a traditional business model, where one entity provides a good/service and another entity receives that good/service, with the receiving party providing a monetary payment in exchange. With a DEX, traders are consuming various services:

1. They consume liquidity which is provided by the Thorchain LPs.

2. They utilize Thorchain computational resources to issue transactions on the network (witness, sign, produce blocks, etc.), which is provisioned by the Thornode operators.

3. They utlize the computational resources provided by *external* blockchains (e.g. gas on the Ethereum network).

Three separate fees are levied on traders to compensate the service providers listed above: an inbound fee, an outbound fee, and a dynamic slip fee. The inbound/outbound fees pay for Thorchain network resources and external blockchain gas, while the slip-based liquidity fee pays for demand of liquidity.

In this section, we will break down the 3 different fees paid by a user when they swap an asset, and dive into the models comprising how these fees are structured. 

Inbound fee - 1*avg network cost. It’s merely the cost of transferring native coins from a personal wallet into a Thorswap wallet (or any similar UI), which generates the transaction memo + move the funds into the Asgard vault to initiate the swap

Outbound fee - the network cost of moving the outgoing asset onchain. This is the same fee Coinbase pushes to the user when withdrawing BTC off the platform into a personal address. It exists to compensate the exchange when they pay the miner/network fee. It is debited from the total outbound value the user receives to their personal wallet, and typically is not a profit mechanism for the exchange. 

However, Thorchain utilizes this outbound fee in a particular way that does add to system income by levying an additional tax. Like any wallet service, the Thorchain protocol monitors onchain gas fees, calculating a cost/transaction weight for that particular chain and saving a trailing average. The protocol will instruct the node in question to relay the outbound transaction using a multiple of that trailing gas cost. Note that it is the LP’s capital who ultimately pays this gas cost (i.e. BTC/RUNE pool pays outgoing BTC TX fees, ETH/RUNE pool pays outgoing ETH TX fees) because the node is merely a custodian of the private keys for the LPs. The LPs aren’t going to operate on altruism, so the protocol needs to reimburse them for this service. 

Thorchain thus charges the user 3x the going market rate of gas cost, instead of the typical 1x. For example, if the average BTC network fee is $10, the swapper will be charged $30, with the value being debited from their outbound transfer. This $30 surcharge is then distributed amongst various system agents:

1. $10 repaid to the BTC/RUNE pool that provided the BTC to make the onchain transfer.

2. ~$10 to the Liquidity Providers in that BTC/RUNE pool, as a profit generation mechanism for these actors. Note: while the system distributes $10 of RUNE to the pool (on top of the reimbursement), because of the impermanent loss that stems from the rebalancing process, it comes out to a little less.

3. $10 to the system reserve, which sponsors various programs (liquidity mining rewards, Impermanent loss protection, fixed rate synth interest payments, etc.)

Total Slippage - the last fee that makes up the aggregate cost of a swap. Total slippage can be broken down into 2 parts: price impact, and the dynamic slip-fee. Both these components can be computed via the following equations:

Undeniably the CLP output slippage and slip-based fee are the most complex parts of the aggregate fee structure. We will break them down in great detail. But to fully grasp these concepts, we need to review some backdrop on capital provisioning within an AMM based module. 

Capital Inefficiency and Impermanent Loss

Let’s quickly summarize the issues AMM models face. An AMM offers liquidity on a deterministic basis, according to a predefined algorithm. The variables that the algorithm uses in its calculation are a function of the quantities of assets comprising the pool. Thus, to alter the pricing algorithm, you need to alter the composition of the pools, by either adding or removing liquidity. 

AMMs are disconnected from reality of broader markets. For example, when the price of ETH on Coinbase spikes from $1,000 to $1,500 (suppose an ETH ETF is announced) the AMM will continue offering ETH for sale at $1,000 as there are no independent market makers who can digest the news, and raise their offers accordingly. This creates an arbitrage opportunity where bots can buy ETH at a discount on the AMM marketplace, and sell it for a premium on Coinbase. The buy pressure on the DEX pushes the price of ETH up locally, and the sell pressure on the CEX pushes it down. Bots will iterate this process repeatedly until the two prices converge to parity. 

Bots are capturing risk free profit from the system, at the expense of the liquidity providers. These LPs are essentially agreeing to sell their ETH below the prevailing market price, thus getting bled out in the process. Now, LPs ultimately collect trading fees when the arbitrageurs perform the arbitrage, so they get back some of the lost capital. But in aggregate, they lose more than they are rebated. If they weren’t, the arbitrager wouldn’t perform the task, as they’d be operating at net loss. This is how it’s possible to allocate capital as an LP, and at the end of your tenure, have less assets when you withdraw, than if you were to merely buy and hold. This phenomenon is commonly known as ‘impermanent loss’. 

Any rational actor’s expected value of being an LP must be greater than a simple buy and hold strategy, otherwise they’d refuse the prospective service. LPs are the backbone of DEXs and without them the system would cease to exist. Simultaneously, impermanent loss is an unavoidable, and even necessary evil to some degree, as it allows for the DEX pricing to re-converge towards the broader market, without relying on fragile mechanisms like oracle modules. So how do we reconcile these challenges? 

The optimal solution can be boiled down to accommodating for capital leakage from the deficiencies of AMM curve pricing by recycling as much capital leakage as possible back in as protocol income. This is accomplished by identifying the arbitrager's lowest reservation price to perform the arbitrage with the protocol paying as close to that rate as possible.

Let’s break down what that means…

By capital leakage, we are broadly speaking about economic value within the Thorchain network that is drained from the system (more specifically, the LPs) and transferred into arbitrager’s hands during impermanent loss. Capital leakage specifically refers to what’s happening when price divergence occurs within the pool and the broader market, causing short term dislocation. It’s a natural feature of AMM systems that cannot be avoided, and creates arbitrage opportunities for the arbitrage agents. 

Imagine you are walking down the street with $100 in your pocket and the bill happens to slip out without you noticing. Shortly after, a runner strolls by, sees the money and picks it up. They’re up $100, you’re down $100. 

Now suppose a huge conglomerate (let’s call it Megacorp) installs security cameras all across the city. Megacorp’s technology is so good that whenever a bill falls into the street, they spot it right away. Megacorp makes its money by selling leads to runners: they’ll announce a ‘free money’ opportunity and the value associated with each job. Then an auction will prevail. The runner that pays the most money for the lead will have the information delivered to them, and be able to run and grab the cash. These runners have costs and risks associated with their business (e.g. fuel to get their car to the area, risk of getting mugged by another bystander) so a $100 job might only fetch $98 in lead revenue for Megacorp. The lowest profit margin a runner is willing to accept to perform the job is called the reservation price. 

This analogy holds fairly well with early iterations of Uniswap, with LPs being the unlucky pedestrians dropping the bill, arbitrage bots being the pedestrians performing the jobs, and the Ethereum blockchain being Megacorp. The primary takeaway here is that the pedestrian losses are a profit mechanism for a) runners b) Megacorp, with Megacorp receiving the bulk of the gain. 

Now suppose an alternative, more benevolent system is constructed. Instead of the security systems being operated by Megacorp, they are owned by a coalition of unlucky pedestrians, who can’t seem to stop dropping money from their pockets. The system is fully automated, so whenever money drops on the ground, the job is created and runners start bidding until the lowest reservation price is hit. If a runner bids $98 for a $100, the net loss incurred by the pedestrian goes from $100 to $2…a drastic improvement. With enough competition between runners, we can get this reservation price quite low. The end state is that value accrual ends primarily in the hands of LPs, not ETH miners.

While not a perfect example, this demonstrates the obstacle every AMM protocol is trying to mitigate—we cannot avoid certain forces of capital leakage due to the natural features of an AMM (just like we can’t stop the wind from blowing money out of people’s pockets). So how can we tweak our modules so that the majority of the capital leakage gets recycled back in as system income (and thereby to LPs), rather than it accrue to economic agents outside of the system (e.g. ETH miners)?

Water never exits the impossible waterfall, outside a few splash droplets at the base. Similarly, the gold standard AMM is one where majority of capital leakage from impermanent loss is recycled back into system income (protecting LPs), with minor value accruing to external beneficiaries (arbitrageurs).

Let's return back to our previous topic, calculation of total slippage in the CLP…

Price Impact - is the difference between the quoted market price and the expected fill price. Also commonly referred to as slippage (price impact is a narrower term that defines a single factor of slippage, as more variables affect its overall rate). If you’ve ever market bought on a CEX, you know that typically your average fill will be different than the price flashing on your screen in big bold lettering. This is because the last quoted price only accounts for the next marginal buy/sell of that coin. And in most situations people are buying/selling numerous coins, thus each marginal buy/sell in their order is subject to a different rate. This same dynamic holds for AMMs. While price impact is a cost to the trader, it is not a fee paid out to a service provider; rather it is a natural function of altering liquidity structure. 

Impact calculation:

The y-output is the mathematical formula that will determine how much output token we receive. It is a function based on how much input token we bring to the table, as well as total liquidity of both tokens already existent within the pools at the time of trade. The relative difference between our x-input and y-output will determine the price impact.

So for example, suppose there were 10 ETH and 10,000 USDC in an ETH/USDC pool. A trader comes to the pool with 100 USDC looking to purchase ETH. The following variables would be:

x: 100 USDC

y: ?

X: 10,000 USDC

Y: 100 ETH

To solve for y (how much ETH they get for a given amount of USDC) we would use the equation:

With y, we now know how much ETH we will receive out of the pool. Now we need to compare the value of what we put into the pool (x) and what we got out (y), and calculate the difference, which we call ‘slip’. To do that, we use the following formula:

Slip-fee - is the second factor that contributes to total slippage. Unlike price impact, slip-fee is a compensation from the entity consuming the resource (liquidity) to the entity providing the resource. 

Slip fee is arguably the most profound innovation in the Thorchain system, as its ability to reduce impermanent loss burden on LPs is significantly greater than in the fixed-rate fee model. The slip-fee is designed to scale the ‘commission fee’ paid by traders so that it roughly matches the impact that their trade has on the pool. Due to the nature of how an AMM tenders liquidity, the higher the price impact that a trader’s order has on the pool, the higher the impermanent loss LPs of that pool tend to suffer (which may run contrary to intuition). So, large trades with material impact on the pool in a fixed-fee AMM system end up reducing LP yield rather than adding to it. The slip-fee helps rebate these LPs at a higher proportion, reducing their IL burden and keeping their yield positive.

Heading back to our formulas, remember that we just calculated the slip, which shows the difference between the value of the token that we put in (x), and the value of the token we got out (y). All the slip-fee is doing is taking that calculated slip value, and multiplying it by the y output. Once we have the slip-fee, we simply subtract that value from the y-output we calculated earlier, to get the final cost.

The formula behind the slip-fee looks like:

Below is an example of a trader coming with 100 USDC to a 100ETH/10,000 USDC pool: 

x: 100 USDC

y: ? ETH

X: 10,000 USDC

Y: 100 ETH

y-output: 0.990099 ETH
slip (as %): 0.99010%
slip-fee: 0.009802 ETH
final output (y output - slip fee): 0.980296 ETH

A dynamic fee that scales with price impact is quite logical because it helps throttle demand for fixed resources (liquidity), allows for pools to bootstrap network effects better, and most importantly allows LPs to recognize where demand for liquidity exists so they can respond to said demand. The tendency for LP pools in Uniswap is for the big to get bigger, with no incentive for profit maximizing LPs to allocate to small pools, because the fee ratio is the same, and there’s typically more trades and less IL happening in the big pools. But with Thorchain, if traders in small pools are paying large slip fees it signals demand for that liquidity and offers them higher yield, which incentivizes LPs to transition their capital into those pools and maximize returns. 

One of the challenges that the CLP model faces is the lack of path independence. With a fixed-fee based system like Uniswap, arbitrageurs looking to close a price gap will always face the same commission rate of 30bps, whether they need to alter the pool 10% or 1%. Thus, the optimal trade is to close the gap with a single transaction. Thorchain however, due to the slip- fee which is a function of price impact, loses this characteristic. If an arbitrageur notices a 10% price discrepancy in the broader market, they are better off closing the gap in many separate small trades where the slip-fee rate will be smaller. This creates an interesting dynamic in a competitive environment where arbitrageurs must model both time and impact when attempting to execute a trade. As touched on earlier, protocol rules mandate that validators order transactions by the basis of slip, so larger trades are always ordered before smaller, thereby maximizing revenue for LPs. So, Bot A might attempt to close a 10% dislocation with ten separate 1% impact trades, but he risks getting front-run by Bot B, who performs two 5% trades. Bot B then risks getting front ran by Bot C who performs an even larger order etc. until the lowest reservation price is hit. The beauty of this scheme is that the protocol is the end recipient of value accrual, not external agents to the protocol like ETH miners in Uniswap. Ultimately, this additional protocol revenue is kicked back to the LPs which reduces their IL burden. The problem here though is that measuring the anticipated IL is more difficult in the Thorchain system, especially early on where competition between arbitrage agents is low, and their models relatively primitive. Depending on the circumstances of the general market and competition amongst miners, LPs might suffer higher IL on some trades, and lower IL on others.

CLP Takeaways

• Fixed-rate AMMs tend to have lower total slippage cost for traders dealing with larger orders, as the total slippage is smaller.

• Thorchain’s CLP has higher costs for traders, but less IL for LPs.  In the short run, liquidity mining incentives distort natural equilibrium rates, but in the long run when those incentives dry up, it likely leads to higher relative LP yields. Higher yields drive more liquidity to the platform, increasing the depth of the pools. Increased depth means less price impact on orders, allowing traders to transact with more size at lower cost, kicking in this feedback loop of higher platform volume, increasing total platform revenue, etc.

  ---

Technical Design

Threshold Signature Scheme (TSS)

Threshold signatures are one of the foundational building blocks that allow the Thorchain protocol to function. In fact, when the Thorchain team began actively working on the protocol in 2018, they were essentially halted by key management/ key signing issues that halted development of the protocol. It wasn’t until threshold signatures were introduced in 2019 that they finally had all the components enabling them to facilitate cross chain swaps. 

At a high level, we can think of TSS as a better iteration of multisig. Within the script of a P2SH multisig, the creator must reference all potential public keys of the multisig counterparts. For example, if it was a 4/5 keysign, the transaction would need to embed all 5 public keys as transactional metadata. Then, when the encumbrance is removed in the unlocking script as the coins are spent, the unlocking script must reference all 4 signatures within the transaction. This creates heavy transaction logic, which significantly increases the transaction fee as a result of the increased byte-space. Furthermore, that transaction logic must be stored by all nodes into perpetuity, increasing blockchain bloat.

Threshold signatures like TSS signatures provide a massive cryptographic advantage because they look like ordinary P2PKH transactions. The committee of participants coordinate in an off chain, interactive, trustless procedure to both generate keys and sign transactions. First, a threshold value that is required to create a valid signature will be established by committee members (for our example, say it’s 20/30). Committee members then generate ‘keyshares’, which are essentially analogous to a private key. That keyshare is stored locally and known only by each individual member. Members will combine individual keyshares in sequence, creating a group private key, from which a group public key can be derived. This private key doesn’t really exist in singular form, nor is it known by any particular entity, as it is an amalgamation of all the individual keyshares. 

To create a valid signature, a TX message is passed around to the committee members, where each member ‘partially unlocks’ the encumbrance utilizing their keyshare. When enough of the quorum members have signed (in this scenario, at least 20), the cryptographic signature will be valid, and the transaction can be broadcast to the network.

Overall, the benefits can be summarized as:

1. Significant improvements to transaction size

2. Flexibility in committee signers

3. Increased privacy- because it looks like a regular P2PKH transaction it is impossible to tell which committee members engaged in the signing process

Vault Types

Asgard - TSS vaults that are managed by the committee of nodes, and we can think of them as somewhat analogous to CEX ‘cold wallets’. Require 66% of existing nodes to come together and sign via their keyshares to produce a valid transaction. Asgard vaults receive all incoming deposits (both trader swaps and liquidity provider capital) to the network. These funds are then sent as ‘top offs’ to various Yggdrasil vaults. Currently, there is only 1 Asgard vault per asset that is supported by the Thorchain network

Yggdrasil - Non-TSS vaults that we can think of as somewhat analogous to CEX ‘hot wallets’. Each node manages its own Yggdrasil for each asset supported by the protocol. The protocol will delegate a particular node to send tokens out of its Yggdrasil to a certain address when processing the outbound portion of a swap. Nodes are only allocated 25% of the value of their total RUNE bonded when they were selected to become a node. So, if Node A had 1M RUNE bonded, it would only have 250k RUNE worth of capital across all assets in their Yggdrasil wallets. Theoretically speaking, nothing prevents a node from running off with the capital in their Yggdrasil wallet. However, if they did so, their bond would be slashed and they would only receive ¼ of the bonded capital, making it a highly negative expected value for the enterprise. 

Anatomy of a Swap

We now understand the roles of the actors facilitating an asset swap (nodes, LPs and traders), but what does the execution look like step by step?

1. Swapper sends BTC into Asgard Vault from Thorswap (which embeds the relevant swap memo) 

2. Every Thorchain node is concurrently running a full node for each asset supported in the thorchain network, along with a Bifrost client. Bifrost is the module that connects Thorchain network to the external networks. It is comprised of a few features: a blockscanner that monitors the external network activity and relevant transactions into the Asgard vaults, external asset chain clients which facilitate the actual interaction on the external blockchain (the component that performs the execution of outbound transactions), and a bridge which parses and converts data coming in and out of the Thorchain network into its relevant language.

3. The blockscanner notices an incoming BTC deposit into Asgard. The node then applies the ‘confirmation wait time’ protocol to ensure that the deposit properly settles and cannot be rolled back. The wait time will vary from blockchain to blockchain as it is a function of the total value of the swap vs. the value of each block reward. Below is an example for Bitcoin:

4. Blockscanner relays the BTC details to the Bifrost. Bifrost parses the BTC transaction, and translates its details into an equivalent thorchain witness transaction. Witness TX is passed into the Thorchain network via the bridge.

5. All 33 nodes are doing the above steps (monitoring the Asgard vault and submitting witness TX) in parallel. So 33 witness TXs should enter the network. Because they are all observing the same information, their transactions should look identical. Nodes then engage in a 66% BFT consensus protocol to accept the common witness TX into a Thorchain block. Once consensus occurs, it is appended to the blockchain.

6. With the external processing complete on the deposit side (processing related to activity outside the Thorchain protocol, i.e. the BTC deposit into Asgard), the system turns to internal processing (asset swap, outbound delegation etc). The system requires multiple messages being passed within the Thorchain blockchain, each message needing to pass through BFT consensus. This is where the application , consensus and networking layers all come into play with one another. The application layer defines the state transition process and ensures proper protocol rules are followed, the networking passes these external/internal messages from node to node, and the Tendermint protocol ossifies consensus amongst the group.

7. Part of the state transition function is delegating one of the Yggdrasil vaults to send out the outbound token (in this case, ETH). The selected node's Bifrost/chain client will create the appropriate 1/1 outbound ETH transaction to the swappers recipient address, according to the specification passed to them by the swap handler in the previous step. The node will use their 1/1 Yggdrasil vault to carry out this outbound TX, rather than having it come from the Asgard vault and require a TSS signature.

Flowchart courtesy of Grassroots Crypto

Yggdrasil performs the transfer because TSS is computationally expensive and takes considerable time to perform. If each outbound transaction was subject to a 22/33 signature, throughput would be drastically reduced. However, economic incentives still guarantee security of the protocol. Yggdrasil vaults are only allocated a maximum of 25% of their bond deposit. So if a node has staked $1M of RUNE, the maximum value of assets inside their Yggradsil vault will be $250k. There’s nothing stopping these nodes from running off with the external assets, but if they do, their EV from the scheme is -$750k as their bond will be slashed. 

Yggdrasil vaults are periodically ‘topped off' from the Asgard vault as their reserves are drained over time. Again this condenses the total number of TSS signatures needed to be performed by the protocol increasing throughput capacity. Below is a full list of circumstances in which TSS is utilized in the Thorchain network:

1. Topping off Yggdrasil vaults 

2. Sending outbound transfers for swaps that are too big for any single Yggdrasil to handle

3. Executing outbound transfers for a swap when the designated Yggdrasil vault goes offline or refuses to perform the transfer

4. Network churn/ vault migration

Synths

Synths are anticipated to be a principal feature of Thorfi, a suite of DeFi applications embedded on top of the Thorchain network. Currently, the only opportunity to generate yield in the Thorchain network is to operate a node, or become an LP. Nodes are extremely capital intensive, and becoming an LP requires asymmetric capital deposit, meaning they must allocate 50% RUNE, 50% non-RUNE token. Users can deposit 100% non-RUNE token but the protocol will automatically rebalance them into 50% RUNE once becoming an LP. This becomes problematic for individuals that desire 100% concentrated exposure to non-RUNE assets at all times.

Synths were launched as a solution. Using BTC as an example, an individual would deposit 1 BTC worth of RUNE onto the platform (or they simply deposit 1BTC, and the protocol automatically swaps their 1 BTC into 1 BTC worth of RUNE), and correspondingly 1 sBTC would be minted against it. Synths are guaranteed by the protocol to maintain parity with their native counterpart, so 1sBTC will always equal 1BTC. Under the hood, Synths are backed by their respective pools, so in this case the BTC/RUNE pool would be responsible for collateralizing the 1 sBTC. However, as one might notice, the RUNE/BTC pool is 50% RUNE and 50% BTC….meaning that the sBTC composition is backed by 50% RUNE, 50% BTC, but must collateralize 100% of BTC position. So what happens if the price of RUNE falls against BTC? Now the pool is ‘in debt’ to the sBTC holder by the proportion of the drop, since it must always guarantee the full value of the sBTC synthetic. So where does this money come from? It is siphoned from the yield LPs are generating in the BTC/RUNE pool. On the flip side however, if the price of RUNE increases in value against BTC, the pool has now experienced capital appreciation, and is richer off because of it.

Now, what’s happening under the hood is that capital deposit by the synth minter (i.e. the 1 BTC) is being taken by the protocol and allocated into the BTC/RUNE pool. This increases the depth of the pool, meaning less slippage for traders. Less slippage leads to a better trading experience, which increases total trading volume. Increased trading volume leads to more fees for LPs, boosting their yield. So, the pool is getting more liquidity added to it, but the LP tokens are not being diluted, because synth minters waive their rights from collecting fees from the pools.

There are two important incentives for minting a synth:

1) Arbitragers - typically when there is an imbalance in the pool (say the pool is top heavy RUNE and short BTC) arbitrageurs will have to initiate an onchain BTC transaction. Which means they will have to wait at least 1 BTC confirmation (sometimes more depending on size of the arb) for the funds to settle in the Asgard vault and take advantage of  the opportunity. However with synths, the BTC is already ‘credited’ inside the Thorchain system, meaning it doesn't require the above procedure on settling within the Asgard vault. Furthermore, synth owners can swap directly from synth to synth, which will settle as quickly as Thorchain blocks are produced (5 seconds). This means that arbitrageurs in synths can arb the pools considerably faster and more efficiently than a non-synth arbitrageur.

2) Yield Opportunity - outside of arbitragers, normal individuals may want to mint synths against their native token, and take those synths and stake it in the synth vault, where it can generate fixed yield. This fixed yield on synth deposit comes from the yield generated by transaction fees from the pool. We can think of it like a bank; a bank receives capital from depositors and pays them some level of interest on that deposit. On the flip side, it loans capital to borrowers, who pay a borrow rate. If the interest the bank collects on that capital lent to borrowers > the interest it pays to the original depositors, they capture the spread. In a similar way, say the LPs can make 20% yield in commission fees off that new liquidity from the synth minters, but only pays out 10% to the synth vault, then the LP’s net out an additional 10% yield. Thus, a correlation is to be expected between the rate of interest the synth vault pays out, and the annual yield that LPs are generating in the pools.

There’s a bit more complexity to the synth model (as well as various fees associated with minting/interacting with synths) that is out of the scope of this article. Other Thorfi applications are in early stage production as well. The Greymatter team is likely to release future updates to this report as more information about these projects materialize.

---

Token Value Model

Our model ascribes a notional value of $281 per RUNE token by 2025. Factoring a 30% discount rate, that projects a present value of $98.44. While such values may seem lofty, we believe them to be relatively conservative, if Thorchain is able to accomplish its objectives and become the premier cross chain DEX. Part of the logic behind Greymatter’s bullish thesis for Thorchain stems from the clear and concise value accrual of the RUNE token within the ecosystem. Common valuation metrics like MCAP/TVL or FDV/TVL  are not applicable due to the fundamental structure of RUNE as the security collateral of the network, along with the fact that it acts as the base pair against all assets in the pools. As a hand waving overview, the ‘intrinsic value’ for RUNE equals 3 * non-RUNE TVL locked in pools. Certain caveats and assumptions to this formula exist (synths, productivity ratio, etc.), which we account for in our model below:

Full model can be viewed here

Assumptions

• Discount Rate: 30% (standard benchmark for venture investing).

• UNI/SUSHI TVL: we backed out the monthly CAGR for both UNI and SUSHI since crossing the $1B TVL threshold, rather than finding monthly CAGR since inception. We believe this will help provide more realistic forward projections by filtering out the exponential (and unrealistic) growth of these projects during their early mainet stage.  Next, we took this CAGR calculation and applied it to extrapolate respective TVL by 2021 year end. We then applied assumptions of monthly CAGR for 2022-2025, at a decaying rate of 7% for 2022, 5% for 2023, 3% for 2024, and 1% for 2025. Lastly, we took the AVERAGE(UNI,SUSHI) TVL values to find the ‘proxy mean’ as to what the TVL of Thorchain at maturity would be comparable.

• TVL Proxy Rate: TVL proxy rate simply takes the ‘proxy mean’ calculated in the step above, and multiplies it by the percentage variable. In our model, we chose a 50% proxy rate. In lay terms, we are basically saying that we believe the winning cross chain DEX (which we are assuming to be Thorchain) will be at least 50% the TVL of the winning single chain DEX. We consider this assumption conservative given that the total addressable market for cross chain protocols is considerably larger, especially as applications structured on L1s continue to trend towards a multichain approach.

• Productive RUNE Ratio: % of RUNE in circulation that is being ‘productively’ applied (e.g. RUNE being bonded by nodes, staked in pools by LPs, or staked by standby nodes that are waiting to be churned in as nodes). As the total value of non-RUNE staked in liquidity pools expands over time, the demand for RUNE by nodes and LPs increases, in order to bond the system properly. We estimate this to be 90% at system maturity. More on productive RUNE can be found here.

• Synth Cap as % of Pool: The total amount of synths that can be minted against a pool. Currently, that parameter is maxed at 33%.

• Synth Utilization: Of that 33% max threshold, what percentage is actually getting utilized by minters? Currently there is no possible way to achieve yield on native BTC without going through a centralized lender. Simultaneously, the demand for yield on BTC is huge, with $10B+ in wBTC alone. Billions of dollars more are being lent out through centralized custodians such as Blockfi, Nexos etc. Thorchain synths will provide the first avenue to achieve yield on native BTC in a trustless, decentralized fashion, and in our opinion, provide a more attractive alternative. Thus we applied a 90% utilization rate.

• Year of TVL Maturity: By 2025 we believe Thorchain TVL will hit parity with 50% of AVG(UNI/SUSHI) TVL.

  ---

Disclaimer

We do not endorse or recommend any investment action in the Thorchain token (RUNE). This document should not be regarded as investment advice, offering document, or as a recommendation regarding a course of action.