Security team

The security risks of THORChain (RUNE)

According to THORChain’s Q1 2022 Cash Report released on April 1, the chain recorded revenue growth despite the dual impact of continued market sluggishness and highly unstable geopolitical factors. Public data shows that THORChain recorded $2.17 billion in revenue in the first quarter of 2022. THORChain, acclaimed as the “cross-chain version of UniSwap”, has gained a foothold in the cross-chain trading market. chains relying on its unique advantages and has won wide recognition among investors.

Behind all this glamour, THORChain is also deeply troubled by piracy. The chain has suffered frequent security breaches since its launch on Ethereum, which cast doubt on its security. On April 11, THORChain tweeted about phishing attacks, warning users not to interact with [DeTHOR] or other unknown tokens in their wallets, which once again raised concerns about its security issues.

While building a strong security system for CoinEx products, the CoinEx security team also tracks security incidents in the blockchain space to help users better understand the security of different projects from a technical security perspective. and to mitigate investment risk. In an effort to improve the security criteria for the blockchain industry, the CoinEx security team analyzed the security risks of THORChain (RUNE). The team hopes that THORChain can note and mitigate the following risks by optimizing relevant smart contract codes. Moreover, this article is also a warning for users, reminding them to be more aware of asset security and avoid asset loss.

How secure is THORChain (RUNE)?

Through analysis of the THORChain (RUNE) contract code and logic, the CoinEx security team discovered the following risks:

To start, let’s look at the contract code of THORChain (RUNE):

We can say that RUNE is a fairly standard ERC-20 token. Note that apart from the ERC-20 interface, THORChain (RUNE) offers an additional interface:

According to transferTo (as shown in the image above), THORChain (RUNE) uses tx.origin, which is one of the causes of its security risks. Here we should explain the difference between tx.origin and msg.sender:

The image below describes what happens when a normal address calls the smart contract:

In such cases, msg.sender = account.address and tx.origin = account.address, which means msg.sender is the same as tx.origin.

Here’s what happens when an account calls contract A and contract A calls contract B:

When contract A calls contract B (as shown above), we can say that msg.sender is equal to tx.origin in contract A.

However, in contract B, msg.sender = contractA.address, while tx.origin = account.address. Therefore, tx.origin is like a global variable that traverses the entire call stack and returns the address of the account that originally sent the transaction. This is the key issue: to date almost all known attacks against THORChain (RUNE) involve tx.origin.

Now let’s find out how attackers steal users’ RUNE tokens via tx.origin:

Attack n°1 : loot a goat in a herd

Addresses on Ethereum are divided into external addresses and contract addresses. The transfer of ETH to these two types of addresses via external addresses is fundamentally different. The official Solidity documentation states that a contract address must implement an Ether receive function before performing transfers.

In light of the features of tx.origin, hackers can construct an attack contract:

When the attack contract receives an ETH transfer from a user, it will “steal a goat from a herd” – the contract will steal the user’s RUNE tokens in the process.

Attack No.2: Internal Attack

An internal attack is a special type of attack. When attempting to steal a user’s RUNE through an insider attack, the hacker must have a medium token. Additionally, the token must also call third-party contracts. According to RUNE transfer records on Ethereum, some attackers hacked RUNE through AMP token transfers.

AMP Token uses the ERC-1820 standard to manage Hook registration and examine whether Hook is registered on each transfer. If Hook has been registered, then the Hook will be called.

The AMP Token contract code shows that the final transfer implementation is: _transferByPartition. Meanwhile, there are two calls involving transferHook: _callPreTransferHooks (before transfer) and _callPostTransferHooks (after transfer). In particular, _callPreTransferHooks is for the originating address, while _callPostTransferHooks is for the destination address (i.e. the receiving address).

For regular users, stealing tokens from themselves is useless. Therefore, attackers can exploit _callPostTransferHooks. Now let’s see the codes of _callPostTransferHooks.


We can say that the only callback attackers could exploit is IAMPTokensRecipient(recipientImplementation).tokensReceived()

Next, we’ll illustrate how this call can be used to transfer a user’s RUNE while performing an AMP token transfer.

Step 1: A calling contract is required (as shown below):

2nd step: Deploy the contract to get the attack address.

Step 3: Call the ERC-1820 contract interface (setInterfaceImplementer) to register the interface.

ERC-1820 address: 0x1820a4B7618BdE71Dce8cdc73aAB6C95905faD24

Contract interface: setInterfaceImplementer(toAddr address, bytes32 interfaceHash, address implementer)

In particular, toAddr is the receiving address of the AMP transfer,

interfaceHash”AmpTokensRecipient”hash :


interfaceHash is the hash of AmpTokensRecipient:


The implementer is the attack address obtained in step 2.

Step 4: Lure a user to transfer AMP to the toAddr to trigger a callback, and steal their RUNE at the same time.

Attack #3: phishing attack

As the name suggests, in a phishing attack, the attacker promises to give amazing benefits to trick users into performing certain contract operations. Here we will introduce a common phishing attack.

Step 1: The attacker issues an ERC-20 token and can write it to any contract interface involving signatures.

2nd step: Create a trading pair on Uniswap or any other swap;

Step 3: Offer airdrops to all users/addresses who hold RUNE tokens;

The initial work of the phishing attack is basically completed by the steps above. Then the attacker just has to wait for the users to swap on a swap, and the users risk losing their RUNE once they perform operations such as approval, transfer, etc.

Additionally, in order to further verify the security risk of the THORChain contract code, CoinEx spoke with the security team of SlowMist and PeckShield, two well-known security agencies in the industry. Confirmed by SlowMist and PeckShield, the security risk mentioned above does indeed exist.

So far, we’ve covered several types of attacks, as well as the security risks users are exposed to.

How should the project team optimize contract code to secure themselves and protect user assets?

The only answer is to be careful about using tx.origin.

How can regular users mitigate risk and protect their assets from attacks that seem inevitable? The CoinEx Security Team offers the following suggestions:

  1. For attack #1: While transferring, keep track of estimated gas consumption. For a regular ETH transfer, a gas fee of 21,000 is more than enough. Be careful if the gas consumption far exceeds this figure.
  2. For attack #2: isolate your tokens by adopting different wallets. You can store different tokens at different addresses. Extra caution is needed when it comes to the hot wallet address offered by exchanges.
  3. For attack n°3: greed is the source of all evil. Do not blindly participate in a parachute event.

Security has always been a major concern in the blockchain industry. All actors, including project teams and exchanges, should prioritize security during project operation, ensure the safety of user assets, and jointly promote the healthy growth of the blockchain industry.