Introduction

Narwhal’s token experienced two considerable drops within a two day period leading to an overall slippage of approximately 99%. The project’s official X account @Narwhal_fyi, announced that they had experienced an exploit, but did not give any specific details. Initial indications pointed to a private key compromise, however on-chain links suggest this incident was an exit scam. Approximately $1 million worth of funds were deposited into Tornado Cash with a further $410,000 sitting in two wallets. In this blog, we will outline the suspicious links that indicate that this incident is an exit scam.

Event Summary

On 7th January, the Narwhal X account posted that they had experienced a hack which resulted in the theft of NRW tokens. The post doesn’t go into any specific details, such as the attackers wallet address, transaction or even the method of attack such as a private key compromise.

When looking at the NRW chart, we observe that there are two major slippages within two days of each other, one on the 5th January and the other on the 6th January. Combined, these slippages accounted for a 99% price drop.

From the two slippages, we have accounted for approximately $1.5 million worth of assets that were removed from the project. Of the $1.5 million, $1.09 million was deposited into Tornado Cash with the remainder $410,000 being transferred to two wallets on the Ethereum Network.

Whilst the Narwhal post does not mention an incident on the 5th January, CertiK has confirmed a link between these two slippages to a single wallet that is linked to the Narwal deployer. This indicates that instead of being hacked, the slippages on Narwhal are the result of an exit scam.

The Two Slippages

On the 5th January, the price of NRW dropped approximately 63%. The drop was caused by externally owned address (EOA) 0xEa55BAEF29dc70799fAec4E2896b4D16A750E568 who sold over 422,000 NRW tokens for 591,877 USDT. EOA 0xEa55 had received NRW tokens from 802 individual wallets. These wallets, which purchased the NRW tokens via PancakeSwap, were all directly or indirectly funded by 0x28B38A8B0b5AbEcE315a5064495056ad158DDDfF.

$293k USDT was bridged to the Ethereum Network from 0xEa55 on the 7th January who then transferred approximately 131.2 ETH to EOA 0x9481b7c8f83A7BB3E8e3648b453d6Eb59dFFcC30 which deposited the funds into Tornado Cash.

The second slippage that occurred on 6th January was due to 0x9481b7c8f83A7BB3E8e3648b453d6Eb59dFFcC30 on BSC calling a withdraw on unverified contract 0x814304B1e200b4D36B26f53358BbBA6D6136B2F5 which was deployed by the Narwhal Deployer.

During the withdraw call 0x9481 passed in a signature which was accepted and allowed the withdrawal of 988,687,039 NRW tokens.

Digging deeper into the withdraw function we can see that the 0x9481 called proxy 0x8143 which called the implementation 0xfb76 and then, after recovering a public key address 0x9661b306622720d7103f572f087e14dfd5cf576c with ‘ecrecover‘, they directly transferred NRW tokens from 0x8143.

In the withdraw function, NRW tokens can be directly transferred to ‘msg.sender', from 0x8143, as long as the v1 variable is authenticated by __signer. The value of v1 comes from function 0x322a.

In function 0x322a, ecrecover is used to recover the incoming parameters into a public key. The attacker needed to obtain the signature of 0x9661b306622720d7103f572f087e14dfd5cf576c and recover it on-chain to pass the verification.

We also found that, on 5th Jan approximately 11 hours before the incident occurred, the creator changed __signer to 0x9661b306622720d7103f572f087e14dfd5cf576c by calling setSigner.

The NRW tokens were then swapped for USDT and then ETH before being bridged to the Etheruem Network and then deposited into Tornado Cash from EOA 0x9481b7c8f83A7BB3E8e3648b453d6Eb59dFFcC30, the same wallet that received funds from the sell off of NRW tokens

From just the Tornado Cash deposits, we can see a link between the two slippages that occurred despite the circumstances of the two price drops being different. CertiK analysts have also been able to tie these two slippages to a wallet linked to the Narwhal deployer wallet, indicating that this incident was an exit scam.

The Suspicious Links

When tracing the wallets involved in the two slippage events (highlighted in the red box below), we can see that both have links to EOA 0xfc8Cd26F86E6169e95A0256004B5c8FD1a6EFdDF which funded the Narwhal deployer wallet as well as 0x28B. This demonstrates to us a likelihood that Narwhal was an exit scam since both slippages can be traced back to 0xfc8Cd26F86E6169e95A0256004B5c8FD1a6EFdDF.

Further Tracing

By applying temporal analysis to the FixedFloat transactions, it is possible to trace funds through FixedFloat and identify further wallets owned by Narwhal. Wallets associated with the project received funds from the exchange in numerous transactions, and we have determined that they originated from the Tron blockchain.

By examining the following transaction, which saw EOA 0xfc8Cd26F86E6169e95A0256004B5c8FD1a6EFdDF receive 0.491039 BNB which was valued at $133 at the time of purchase, we can see that the sending wallet was TWEN5DejzyJbqshgVtUAcLaZNGqZzZYurL which was funded by Binance.

Conclusion

With exit scams we often see the deletion of social media accounts and websites which confirm an exit scam has taken place. However, there are situations in which a project claims to be the victim of an exploit of some kind with the on-chain facts telling a different story. This has been the case with Narwhal, who didn’t disclose any details of the hack that they claim to have suffered. On-chain evidence links two slippages to a single wallet related to the deployer of Narwhal. The two slippages occurred on different dates, linked to the same wallet that funded the Narwhal deployer, and the proceeds bridged to a wallet that deposits the funds into Tornado Cash.

Importantly, the two slippages are caused by different actions. With the first occurring due to a consolidation of purchased tokens, and the other as a result of tokens stored in a project’s smart contract. Whilst the second slippage could have been the result of a private key compromise, the first cannot. This indicates an exit scam, rather than an exploit.