Bridging the Waters
An In-Depth Analysis of THORChain and the Case for Cross-Chain Liquidity Infrastructure
“It’s hard enough to find an error in your code when you’re looking for it; it’s even harder when you’ve assumed your code is error-free.” — Steve McConnell
By Kirill Naumov, Research Analyst at HASH CIB (k.naumov@hashcib.com), and Misha Butov, Research Partner at HASH CIB (mb@hashcib.com).
Special thanks to Lorenzo Valente from the ChainFlip team for the feedback on THORChain and ChainFlip design features.
Project Overview
THORChain is a protocol that allows users to swap native assets without an intermediary of a centralized exchange. Until now, a user had to sign up with an exchange and complete KYC procedures to trade native assets like, for example, Bitcoin and Litecoin. Previous approaches to this challenge, like Wrapping and Atomic Swaps, didn’t achieve the goal of creating a trustless exchange or have been largely illiquid.
From the user’s point of view, they have to send their funds into THORChain’s native wallet, select what asset they want to swap for, and confirm the swap. Like for any other popular DEX, THORChain’s goal was to create a frictionless user experience. The only difference in the UX between THORChain and other AMM Decentralized Exchanges is the presence of their native wallet, which is required for swapping assets on THORChain. While the user controls their private keys, they either sacrifice the ability to select where they store their funds or must pay extra transaction fees to send funds through THORChain’s wallet before a swap.
THORChain promises a significant increase in liquidity over other Decentralized Exchanges. This is achieved by placing every native asset into a liquidity pool against RUNE, THORChain’s native token. This approach allows having only a single trading pair for each asset connected to THORChain. If a user wants to swap one native asset for another, the system swaps the first asset for RUNE and then RUNE for the second one. This type of transaction is called the doubleswap. At the same time, it should be noted that this increase in the liquidity of traded assets comes at a price of the reduced overall capital efficiency of the system as every asset needs to be paired with native RUNE token, which is unnecessary in Uniswap-like DEXs, where bridging assets emerge based on market dynamics and intercommunications between the pools.
THORChain utilizes network infrastructure that mimics that of centralized exchanges. There are two types of vaults: one ASGARD vault and 36 YGGDRASIL vaults. The ASGARD vault is collectively controlled by the validating nodes of the network, which utilize Multi-Party Computation technology to sign transactions. YGGDRASIL vaults are controlled by nodes and contain the inbound and outbound assets for user operations, similar to “hot wallets” in centralized exchanges. Because the nodes hold the private keys for their respective vaults, they must bond at least twice as much capital as is stored in their vaults to ensure they do not steal user funds.
To incentivize nodes to participate in the network and to bond such a substantial amount of capital, they get a share of the network rewards. Transaction fees and liquidity emissions are distributed between Liquidity Providers and Validating Nodes in a proportion determined by the Incentive Pendulum, THORChain’s innovative algorithm that keeps the network in a safe and balanced state.
To avoid the issue of transaction front-running which persists on other decentralized exchanges, THORChain introduced the Slip-based fee. This fee is proportional to the change in price which a given trade incurs and creates an order of transaction execution priority in the network; the transactions with higher Slip-based fees are executed first. Thus, if a user wants to complete a large trade quickly, they do it in one swap and pay a sizeable Slip-based fee. To reduce the Slip-based fee, a user can complete a trade in several swaps, so each of them will have a more negligible effect on the price but can be subject to a front-run attack.
THORChain launched its MultiChain ChaosNet (MCCN) network in April. The MCCN is the final public beta test before releasing THORChain’s mainnet, which is planned to take place in several months. The previous stage of testing, Single Chain ChaosNet (SCCN), ran for eight months on the Binance Chain. Currently, more than two months into cross-chain compatibility, THORChain still sees a larger volume on BSC token pools rather than on native token pools like Bitcoin and Ethereum. BUSD is used as the stablecoin of choice in the THORChain ecosystem and thus sees the highest volume.
Fees, Fees, and More Fees
Fees on THORChain are divided into four categories, from which one or more can be present in each transaction: network fees, native asset transaction fees, slip fees, and affiliate fees. In a swap, these fees are deducted from the inbound or outbound asset automatically and do not require the user to hold any RUNE, simplifying the user experience.
The Network fee is a flat fee that the user pays for any transaction involving the THORChain network. The Network fee is fixed at 0.02 RUNE and is subtracted automatically from the user’s balance or the payment. In the event of a swap where the user does not own any RUNE, the Network fee is subtracted from the inbound asset in the asset’s currency.
The Network fee from each transaction automatically gets added to the Liquidity Emission Reserve. The reserve currently contains approximately 190 million RUNE and distributes 1/6 of the balance annually to Validating Nodes and Liquidity Providers in a ratio determined by the Incentive Pendulum. This distribution comes once per block. Nodes and Liquidity Providers receive 100% of the Slip fees paid by users and the Block Reward that comes from the reserve.
Native asset fees are used to pay inbound and outbound transaction fees on native blockchains such as Bitcoin, Ethereum, and Litecoin. The price for sending tokens into and from THORChain Vaults is calculated from the runtime gas fees of both the inbound and outbound assets.
Slip-based fees are the penalty for shifting the price in the AMM liquidity pool. Slip-based fees are unique to the THORChain platform and were conceived to allow the network to prioritize large transactions and prevent front-running. These fees are calculated as the percentage of the liquidity pool of the inbound asset which the swap constitutes. For a doubleswap, the Slip-based fee is applied twice.
Finally, affiliate fees allow ecosystem developers to benefit from the utilization of their front-end applications. Affiliate fees can be of any amount and are added to the memo of the transaction. Like the network fee, if the user does not own any RUNE, the fee is subtracted from the inbound asset.
Because the swap fees contain both fixed and variable components, there remains an area for execution optimization. A large trade can be broken down into smaller transactions to reduce the Slip-based fee and increase the output value received from the swap. For example, for the transaction shown above, if the trade is split into two swaps of 0.5 BTC, the user will pay twice as much fixed fees, but the total Slip-based fee will be reduced by approximately 50%. For the first swap (BTC to RUNE), the user will pay roughly $105. Similarly, for the second swap, the user will pay $133 (the fee is higher here because the ETH-RUNE pool has less liquidity, and thus the price impact is higher).
We saw this opportunity for optimization of transaction fees and developed a simple algorithm that allows users to find out in how many swaps they should split their trade on THORChain to minimize the associated costs. You can view and download the Python script from our GitHub. You can also consider how the calculation works here. What we cannot account for, however, is the possibility of a partial transaction front-run by someone monitoring the transaction pool of the protocol for large split-up trades.
The Incentive Pendulum
The cross-chain nature of the project requires a substantial amount of capital to be bonded by nodes (deposited into the system) to prevent them from taking the user-deposited liquidity. Per THORChain’s current design, bonded capital must be double the native assets in AMM liquidity and double the RUNE in liquidity (equal to the total liquidity in the protocol). To keep the network in this balanced state, THORChain’s team introduced the Incentive Pendulum, which distributes the fees proportionally to the urgency of capital requirement in either liquidity or bond.
When the number of staked RUNE (in liquidity) is equal to the number of bonded RUNE, the network is in a dangerous state. In this case, the total staked assets in liquidity (RUNE and native assets) are double the bonded RUNE, which puts the network at risk where nodes may withdraw capital and make a profit even with the RUNE price collapsing. In this state, all the rewards coming from the liquidity emission reserve go to nodes, incentivizing them to bond more capital. Thus, nodes will increase the capital bonded and secure the network assuming the perfect competition.
In the case of irrational behavior from network participants, nodes can refrain from increasing bonded capital. When the number of RUNE bonded is equal to the RUNE in liquidity, nodes already are earning 100% from all the network’s liquidity emission incentives, while Liquidity Providers are earning 0%. Thus, if the nodes can collude, there is no reason for them to increase bonded capital as the total reward will only substantially decrease. In case of such collusion, we can expect that Liquidity Providers will pull out their assets from the pools, which will rebalance the Pendulum but will have a detrimental effect on the THORChain’s performance as an exchange.
It is critical to point out that bonded capital is crucial for network security. It cannot be delegated or lent to nodes, making the amount of capital bonded less flexible than liquidity due to the constrained number of participants. Effectively, many nodes may not be able to provide additional capital in a timely manner, breaking the system’s rationality and perfect competition assumptions.
If the value of RUNE experiences a flash-crash, the value of the bonded RUNE will fall much more than the value in the protocol’s liquidity. Due to the human factor and network congestion, rebalancing the assets can take several hours. For these several hours, the network could be in a vulnerable state where the bond is worth significantly less than the assets in the protocol, allowing the node owners to profit from withdrawing users’ funds.
Competition in Cross-Chain Swapping
The challenge of swapping native assets without the medium of a centralized exchange has been approached numerous times in the past several years by different projects. Atomic swaps were the first with a viable solution in 2017. Using Hash Timelock Contracts (HTLC), the system allowed two users to swap funds at an agreed exchange rate. Atomic Swaps required users to acknowledge receipt of their funds within a specified timeframe or the entire transaction would be canceled. This solution did not gain much traction because it lacked liquidity due to the peer-to-peer nature of each transaction.
With the rapid development of Decentralized Finance on Ethereum, we saw the emergence of wrapped native assets like wBTC, tBTC, wZEC, and wXLM in 2019 and 2020. These could be swapped on DeFi exchanges through AMM pools. However, solving the liquidity problem, wrapped tokens failed to preserve the qualities of the native assets like decentralization and privacy. Many users did not want to swap native assets for their wrapped counterparts on other exchanges due to a lack of trust and critical properties specific to the native chain. For example, privacy coins like Monero and ZCash lose their entire value proposition when wrapped.
Similarly, Fantom’s approach to the challenge of cross-chain swapping also fails to operate exclusively through native assets and resorts to wrapping. Fantom, an established DeFi platform, recently announced cross-chain compatibility through their partnership with RenVM. Despite this claim, they are fundamentally not a cross-chain exchange but a single-chain DEX with bridges that wrap assets from other blockchains.
THORChain seemingly solves the challenge of trading native assets without a centralized intermediary but has several shortcomings in its implementation. ChainFlip is a direct competitor to THORChain and claims to address its core issues. One significant difference in user experience, for example, is that to swap native assets, a user will not have to send them to a wallet on the platform first. Instead, they will just have to specify which address the inbound funds will come from, allowing nodes to attribute the received funds to the specific customer. While this is a minor detail, this solves the core problem that separates THORChain from being easily integrable into AMM aggregators on other chains.
Additionally, ChainFlip boasts faster signing of transactions on native blockchains than THORChain by knowing the nuances of each connected chain and adhering to tailor-made cryptographic primitives of each integrated chain. Instead of using their native token as the medium for liquidity, ChainFlip will use USDC as a base asset for all pairs, reducing the exchange’s reliance on its token and reducing friction for network participants. Compared with THORChain, this will significantly simplify the hedging of positions for professional investors and liquidity providers. ChainFlip developers referred to the dominance of Uniswap over Bancor (who initially introduced the AMM) achieved by their choice to dismantle the project’s token from the trading pairs, when we inquired about this difference.
ChainFlip will be bui1lt on the Substrate framework but will not be a parachain of Polkadot. All the core logic of the exchange will be implemented in the Substrate’s runtime. It will enable several important features such as Uniswap V3 style concentrated liquidity provision and transaction batching to prevent front-running opportunities. ChainFlip will also be one of the first DEXes to enable RPC calls to the exchange API, making it even more friendly for professional users (source).
While an implementation fully based on Polkadot is infeasible due to the requirement of collateral staking from validators, we see a great opportunity in ChainFlip utilizing the Shared Security of Polkadot through the Relay Chain to raise the capital requirement for attacking the platform and to improve user trust. Essentially, in our view, being a parachain of Polkadot would reduce the risks of the platform. However, because the team is unsure whether nodes and quoters will need to stake tokens and how much, this issue is still being debated. By our estimates, ChainFlip is roughly 1.5 years behind THORChain in its development.
Community Projects
THORChain has a highly active community with many teams of developers building innovative applications on THORChain’s platform. The most notable projects include xDeFi, BrokkrFinance, THORSwap, and Thorstarter.
xDeFi is a cross-chain wallet that will allow users to swap native assets cross-chain within its interface and interact with any other decentralized applications irrespective of the blockchain. In essence, xDeFi is creating an application very similar to Metamask but cross-chain, which was made possible by the technologies pioneered by THORChain. xDeFi secured a $1.2 million seed investment in March 2021 and the project is currently in the private beta stage.
BrokkrFinance is developing a large-scale project made possible by THORChain, which aggregates all the largest Decentralized Finance applications and allows users to access all of them from a single dashboard. Additionally, BrokkrFinance will calculate the most optimal routes for swapping assets through all commonly used AMM protocols. Finally, BrokkrFinance will compile data for all Liquidity Provision, Staking, Farming, and Lending in Decentralized Finance, assess their individual risks, and give its users the ability to invest in the most profitable option based on their risk tolerance.
THORSwap is an alternative main interface for THORChain. Both are front-end applications designed to swap native assets through THORChain, but ASGARDEX was developed by the core team behind THORChain, while THORSwap was created by a separate developer team from the THORChain’s ecosystem. Neither of the front-end applications charges affiliate fees. THORSwap is much more comprehensive and complex than ASGARDEX in terms of available information and features, which gives it the edge in customer experience.
Thorstarter is a decentralized protocol that relays liquidity from THORChain for smaller projects and tokens. Because THORChain has a complicated network approval process and a limited number of possible pools, it is infeasible for a new small-cap token to be listed on THORChain. However, it can be listed on Thorstarter, which will act as an incubator for long-tail crypto assets and new projects seeking to trade their token across native assets. Thorstarter will complement and extend the reach and liquidity of THORChain, allowing small-cap tokens to be exchanged for well-known native assets like Bitcoin and Ethereum.
The ability to manage asset pools on different blockchains opens up a wide variety of novel financial applications that otherwise would not be possible for Script-based blockchains. For example, starting with cross-chain swaps, the THORChain ecosystem can evolve into cross-chain money markets, yield aggregators, and derivative platforms. While currently, such assets need to be wrapped on Ethereum to become a part of the DeFi movement, THORChain and ChainFlip will bring DeFi directly to these chains.
A low-hanging fruit for the THORChain platform could be a protocol that would allow for single-sided asset provision into a liquidity pool. This could be achieved by matching liquidity providers of a given native asset with aggregated RUNE liquidity providers and, through some clever mechanics, dividing the Impermanent Loss into two pools and weighting it depending on the effect of isolated price action in the two pools. A protocol like this would allow traditional liquidity providers to remove the friction of buying and holding RUNE tokens while at the same time creating a stable value flow for RUNE holders who do not want to take on the risks of exposure to other assets.
Navigating the Security Assumptions of THORChain
A long-lasting battle for the ultimate “Ethereum killer” is still struggling to produce a worthy alternative. The prohibitive gas costs on Ethereum gave birth to a generation of Ethereum clones. The hardcore Ethereum supporters may prefer to view them more as a short-term bandage for scalability problems or even as decoys for low-quality projects and scams. Nevertheless, a significant portion of users has signaled their preference for scalability and low transaction fees over decentralization and stronger security assumptions. The words “security assumptions” are blatantly thrown in any conversations on scalability and decentralization. But what do they actually mean from the users’ perspective? In the end, it will be their decisions that will direct the entire market.
Security assumptions are the cornerstones of the blockchain ideology. At the same time, this field is extremely tricky and, in many ways, misunderstood. Many potential attack vectors often have opposite directions and are valued differently by various user groups. Some may prefer a soothing comfort of centralization, sacrificing a little bit of censorship resistance; others do not feel safe outside their cold wallets. Additionally, for the same user group, various types of transactions may imply different security requirements. The main front line of this opposition currently lies between the promised trustless scaling with sharding and roll-ups, and trusted sidechains with their ready-to-go solutions. Another interesting angle to look at security assumptions is through cross-chain communications/transfers, as in this case, the users would have to exchange the risks between various layer-1 platforms.
THORChain and ChainFlip can be viewed as yet another exciting experiments on how the users and developers value the basic security assumptions of native blockchains and cross-chain infrastructure. One of the core value propositions of such cross-chain liquidity platforms is that you do not have to wrap assets on Ethereum if you want to access DeFi. While one can argue that WBTC is not BTC, there are no effective price premiums on BTC, so the market clearly views them as the same asset. Of course, when talking about WBTC, there is still a centralized custody provider involved, which is against the fundamental nature of both Bitcoin and Decentralized Finance. But let us look more broadly at the spectrum of security assumptions.
Let’s try to put different combinations of protocols and intermediaries on the “Risk of Failure” scale. By Risk of Failure we understand all sorts of possible risk vectors, including malicious behavior of actors, government attacks, failure of the protocol, cryptographic failures, mechanism design failures, smart contract vulnerabilities, hacks, etc. The idea is not to strictly quantify these risks but rather to present a perceived scale, which can be different for various user groups. At the moment, it is impossible to compare the actual risks of PoW versus PoS systems, cryptographic systems vs. game-theoretic. A user can have their own heuristic behind this comparison — e.g., PoW is more battle-tested, cryptography does not need to account for strategic behaviors. But these heuristics cannot be treated as universal.
For the sake of argument, let’s say that Bitcoin holds its position on the lowest parts of the scale, centralized third parties occupy the region with the highest risk of failure, and every other protocol and application is in between. The exact position of each point on the scale is completely arbitrary and does not intend to hurt anyone’s feelings.
Each time your assets touch any sort of financial party, either centralized or decentralized, you expose yourself to its underlying security risks. Moreover, the risks accrue over a period of time while your assets are sitting on their ledgers or balance sheets. On top of that, if you are interacting with several parties, like in the case with WBTC, you face both risks. Let’s say that the risk of holding BTC over a period of time T is P(B), holding an ERC20 token is P(E), and operating with BitGo is P(BG). Then the risk of holding WBTC over the period of time T would be:
The aggregate risk would be the union of each component’s individual risks. You can see how this would be even worse than interacting with BitGo alone. The risks would be even higher if you choose to provide WBTC liquidity into any AMM pool, adding smart-contract failure risks to the mix.
When the user interacts momentarily with any smart contract, he takes on the risk of smart contract malfunction. In the case of Uniswap, this risk would exist only for a single block. Let’s assume that this momentary risk of interacting with a protocol like Uniswap equals p(U).
So, where does THORChain fit into this system, and what exactly is THORChain? When the user swaps ETH to BTC on THORChain, he exchanges Ethereum’s security risks to Bitcoin’s security risks. Additionally, he momentarily takes on THORChain’s security risks during the process of a swap — p(TC), which would span over several blocks as swaps in THORChain take longer to confirm.
Let’s also assume that we have a bridge with the same technical security assumptions as THORChain; we will call it THORBridge. It uses the same tech, is supported by the same community, and is actually the extension of THORChain’s functionality. The overall security risks of THORBridge would be slightly lower than THORChain as AMM functionality inherently creates more complex cryptoeconomic logic. If we isolate this discrepancy as P(AMM), then the risk of failure for THORChain would be p(TC) = p(TB + AMM).
The purpose of THORBridge is to receive BTC on a Bitcoin address controlled by THORChain’s validators and mint thorBTC on Ethereum and other blockchains. In this case, the atomic transaction of swapping ETH to thorBTC on Uniswap and immediately sending thorBTC to the Bitcoin network would be p(TB + U). The risks of holding ETH and then holding BTC remains the same. So in terms of the users’ perspective, if they trust Uniswap more than THORChain, it would be preferable for them to use THORBridge plus Uniswap instead of native swap THORChain. Additionally, we omit the topic of execution efficiency and trading fees. Still, one can argue that due to excess liquidity on Ethereum, the ETH/thorBTC pool on Uniswap can be much more liquid and capital-efficient than ETH/RUNE and BTC/RUNE pools on THORChain. We also prefer not to focus on the UX tradeoffs, as it is primarily a function of developers’ mindshare.
Let’s move one step further and introduce another entity — trust minimized Ethereum to Bitcoin bridge. By saying the bridge is trust minimized, we understand that it inherits its security assumptions from the bridged chains and does not create new significant risk vectors. A good example of trust minimized bridge is NEAR to Ethereum Rainbow Bridge:
“To trust the bridge, you need to trust (1) that Ethereum blocks are final after X confirmations … currently decided by the bridge for the app developer, but soon app developers will be able to determine X for themselves, (2) that at no time, 2/3 of the validators’ stake on NEAR blockchain is dishonest…, and (3) that it is not possible to exponentially increase the minimum gas price of Ethereum blocks by more than 2x with every block for more than 4 hours”.
At this moment, there is no trust minimized Ethereum to Bitcoin bridge, but we can expect such innovation to be available after the Taproot update. Additionally, we already have a resemblance of trust minimized Bitcoin to Ethereum bridge in KEEP. Due to our definition, we cannot call it truly trust minimized as it creates a new category of game-theoretic risk. Nevertheless, if the user perceives these risks as negligible (or at least less prominent than THORChain’s), the decision to use THORChain instead of a combination of Uniswap and the trust minimized bridge becomes even less convincing.
Given all the above rationale, we can deduce that THORChain is basically a generalized bridge with native AMM support. It can serve as a useful interlayer between two Non-Turing-Complete blockchains, like Monero and BTC, but it can struggle with adoption for smart-contract enabled blockchains. To the point of this interlayer, we can also expect that Ethereum, Polkadot, or another prominent layer-1 smart contract enabled blockchain itself can be a much more appropriate candidate for this task.
The topic of security assumptions for cross-chain infrastructure becomes even more relevant in the light of recent THORChain hacks. You can read the details on the hacks here (hack 1) and here (hack 2). Almost all the cross-chain infrastructure creates additional attack vectors stacked on top of the existing security assumptions of native blockchains. The more complex and untested this infrastructure, the higher the risks that users will lose their funds. It is true that “innovation leads to exploitation.” It is also true that the code that controls nine figures should not be rushed. And users operating with such pieces of infrastructure should be mindful of their implicit risks. We believe that such complex endeavors should come with an extra level of scrutiny. The fewer moving parts and real money are affected by an untested implementation, the better. The game of blockchain infrastructure development is in many ways the game of trust, which is quite hard to earn and very easy to lose. We hope that THORChain would be able to get out of this challenging situation even stronger.
Cross-chain DeFi is just making its first moves. Creating reliable ways for blockchains to transfer value will inevitably come with new risks, vulnerabilities, and exploits. The exact role of THORChain and its alternatives in the cross-chain DeFi space is yet to be determined. But we believe that it is crucial to examine such implementation not only on their face value but also on the plane of underlying core principles.
Network Value Flow
Instead of searching for the fair fundamental value of RUNE, we will be evaluating its Value Accrual mechanism and highlighting the key assumptions which affect this mechanism and the fair token price. The goal of the exercise is to deduce the required average annual growth rate in the projected period based on selected assumptions and the specified Value Flow model. We are not completely confident that the outlined mechanism will always work as described as THORChain is still in its experimental stage. Many things can still go wrong or significantly change the way token value is accrued in the protocol’s design. Therefore, the results of this exercise should not be considered price targets or investment advice but instead should be used to better understand the platform and its underlying mechanics.
For our valuation, we will be using the volume and liquidity data seen on THORChain before the vulnerabilities were exploited and the network was halted as we are sure that the platform will quickly return to its original performance figures upon emergence from maintenance. We base this assumption on the high network volume on July 15, 2021, after emergence from the first vulnerability maintenance.
Evaluating THORChain and finding the fair value of RUNE is relatively straightforward. While there are way too many unknowns, we can combine comparable project analysis and our own assumptions to build out a value accrual model based on HASH CIB’s Discounted Value Flow methodology. Ready for the inevitable critique of our assumptions, we propose a derivation of the annual network growth needed to justify the current RUNE price of $7 derived by solving the Discounted Value Flow model in reverse.
We based our assumptions on the information supplied by the team, data found on THORChain block explorers, and generally assumed values in the industry (discount rate). Annual network growth (after mainnet launch) is a number we arrived at by reverse solving the model using a price estimate of RUNE at $7. Effectively, our model shows that a very realistic 31% annual network growth is necessary to arrive at the current value of RUNE. As a sidenote, Uniswap’s volume grew 15,000% in 2020.
First, we project the project’s transaction volume and Total Value Locked (TVL) for ten years into the future. Because of the underlying assumption that the amount of rune locked in liquidity and bonding (TVL) must be 3x the amount of native assets in the liquidity pools, we can calculate the total minimum demand for RUNE in dollars for Liquidity and Bonded capital. Here we assume that the ratio of volume to TVL remains constant over ten years. Our analysis of comparable projects demonstrates that THORChain’s Volume / TVL ratio is slightly higher than that of other Decentralized Exchanges. We decided to not adjust for this as THORChain has a unique cryptoeconomic design where all traded pairs are pooled against RUNE. For our analysis of comparable projects, we removed Uniswap V3 as an outlier (its Volume / TVL was 170.3) because of the capital-effective design of liquidity in the DEX and its early adoption stage.
For supply (tokens in circulation), we compiled data from CoinGecko, THORChain’s monthly treasury reports on Medium, its Binance listing proposal from June 2019, and its blockchain explorers. The most noteworthy points are the unlock of 80 million tokens for seed investors and the team at the release of their mainnet and the calculation of the liquidity emission over ten years. In inquiring about the progress and the time to mainnet, the team’s answer was “months,” without any clarification. Subsequently, we used an assumption of six months for our model. We assumed no refilling of the reserve from network fees for liquidity emission due to their insignificance on the grand scale and for simplicity of the model. By adding rewards in circulation, seed and team tokens in circulation, and base circulation (tokens already in circulation), we arrive at the total RUNE in circulation for each year after the launch of the mainnet.
After arriving at the token demand and supply, we can calculate the implied token price by dividing one by the other. This allows us to calculate the minimum price of the RUNE token for that year to satisfy liquidity in the protocol. After accounting for RUNE bonded in standby nodes (50% of RUNE bonded in active nodes) and assuming a 20% free float (RUNE not locked in bond or liquidity), we arrive at the final total demand for RUNE for any projected period. To arrive at the Additional Current Utility Value (ACUV), we find the difference between consecutive years. Like in the Discounted Cash Flow (DCF) model for valuation of equity, we calculate a Terminal Value and then discount the ACUV with a factor of 40%, which corresponds to the high risk of the investments suitable for crypto projects. By adding up the discounted ACUV, we arrive at the current value of the token of $7.
While this is an unconventional approach, it has remained as the cutting edge in cryptocurrency valuation for the last two years. While THORChain is too early in its adoption cycle to value it properly, our model demonstrates that the growth assumption necessary to justify the current token price is attainable for the project. This valuation relies on the fact that the protocol’s cryptoeconomic assumptions of token demand and supply remain the same throughout the projected period. You can read more about our valuation approach on our Medium and see our complete valuation model for THORChain here.
Disclosures
This article relates to instruments the access to which may be restricted in certain jurisdictions. If this article is viewed by a person who is not considered to be an eligible investor under applicable local laws in the respective jurisdiction or is obtained in a jurisdiction where dissemination of this article would be unlawful, this person should not review it and should disregard it. This report may be used as general information only and is based on current information that HASH CIB considers reliable, but HASH CIB does not represent it as accurate or complete, and it should not be relied on as such. Neither the information nor any opinion expressed constitutes a recommendation, an offer, or an invitation to make an offer, to buy or sell any securities or other instruments. This article does not constitute investment advice. HASH CIB accepts no liability whatsoever for any direct or indirect losses, damage, or other consequences of any kind that may arise out of the partial or full usage of this article, and investors are invited to obtain their own financial advice. HASH CIB is not licensed to carry out any banking or broker services or similar activities anywhere in the world, is not a regulated entity in any jurisdiction, and does not hold any licenses or other permits from any regulatory bodies of any jurisdiction. This article shall not be considered as advertising the instruments mentioned herein. HASH CIB, its shareholders, affiliates, and associates may hold positions in the instruments covered by this article or perform services to the issuers thereof.
