[Update: (2019-11-15) EOSIO namebid issue was fixed, but CPU resources are still tight. Some sellrex orders could not be completed, resulting in the inability to rent CPU.]

On 11/1, enumivo team announced on their website that they’re airdropping free EIDOS tokens if you send any amount of EOS to the EOS address eidosonecoin. This resulted in a mining mania for EIDOS right after the announcement was released for one week so far. Also, the CPU resource of EOSIO network was forced into the saturated state, in which users need to stake enough EOS to utilize the portion of CPU time based on the staked amount. PeckShield researchers monitored and analyzed the transactions on EOSIO network as well as the CPU rental mechanism based on REX by the time the airdrop started. Here’re some interesting findings we’ve got.

Figure 1: https://enumivo.org/get-free-eidos


At 16:00pm 11/1 (UTC+8 time), we started a robot sending 0.0001 EOS to eidosonecoin in an infinite loop for monitoring the mining mania. The first thing came into our radar is that there’s not enough RAM in the eidosonecoin account so that new miners cannot get into the ballpark. Fortunately, the RAM crisis was resolved in around 10mins.

At around 16:30pm 11/1 (UTC+8 time), our robot ran out of CPU time. As shown in Figure 2, the CPU price was raised to 0.2 ms per EOS. It means you get only 200 us after staking 1 EOS but one typical EOS transfer takes more CPU time than that. Moreover, the CPU price was raised to 0.1 ms per EOS two hours after the airdrop was launched. Compared to the CPU price in last 4 weeks as shown in Figure 2, the price reached historical high in last 7 days.

Figure 2: CPU Time (ms) per EOS (Source: https://labs.eostitan.com)

The historical high CPU price dramatically affected the EOSIO network users. As shown in Figure 3, the number of active users dropped from 80k to below 20k in one day (blue line). We believe it was caused by the fact that the CPU price was not affordable to many users.

Figure 3: Number of Active Users in Last 30 Days (Source: https://dapptotal.com/)

However, the number of transactions raised as shown in Figure 4. It looks a little bit weird here because we have fewer and fewer active users using the EOSIO network. After analyzing the actions in each transaction issued in that time period, we know that the minority of active users, EIDOS miners, worked really hard to send out as many as possible transactions, which used up most of the CPU time and indirectly kicked out normal users.

Figure 4: Number of Transactions in Last 30 Days (Source: https://dapptotal.com/)

As shown in Figure 5, the actions related to EIDOS consumed 56% of all CPU consumption as of 11/6. The unaffordable CPU price made users start to rent CPU/NET from REX instead of staking their EOS tokens. In particular, the top 5 EIDOS miners rent millions of EOS equivalent CPU time for mining. The secret is that those top miners rentcpu before the airdrop started, which allows them to get much cheaper rental CPU (i.e., 1 EOS can rent for ~3,000 EOS CPU time for 30 days).

Figure 5: CPU Consumption Breakdown

Although they can rent CPU from REX, only few users know how to do it such that the miners and rich services providers were the only users on EOSIO network. As shown in Figure 6, a CPU/NET renter needs to deposit some EOS tokens into the REX fund before performing rentcpu. This is somewhat complicated for normal users such that many of them cannot use the EOSIO network because of CPU crisis.

Figure 6: EOS REX Operation Flow Chart

As more new miners started to rentcpu, the rental CPU price raised to around 1 EOS for 180 EOS. That’s not a good sign for making profit from EIDOS mining. The worse thing was that the REX system ran out of money for CPU/NET rental as well as sellrex at 6pm 11/4 (UTC+8 time). Figure 7 is a screenshot of running this command: cleos system rex rentcpu myeosaccount myeosaccount '0.0001 EOS' '0.0000 EOS'

Figure 7: REX Loans Not Available

As programmed in the REX smart contract, the loanable EOS is calculated as follows: available_unlent = total_unlent - 2 * total_lent / 10 It means all rentcpu actions are suspended when around 83 % of the pool is consumed: available_unlent = 16.66666666% pool - 2 * 83.33333333% pool / 10 = 0 We need some EOS whales to deposit more EOS tokens into the pool to make the REX system function normally!

On November 15th, the EOS of the REX system is insufficient, so some sellrex orders could not be completed and the rentcpu is still not available. This can lead to two situations. One is that there is still not enough EOS in REX in December. In this way, after the low-cost CPU is expired, the returned EOS will be used to prioritize some of the sellrex orders. In the other case, if a large number of EOS are deposited to REX, there will be no blocked sellrex orders. The expired low-cost EOS will be preferentially rent to returnees.


As most users were looking for cheap CPU resources, some bad actors started to exploit the CPU resources of DApps. At 7pm 11/5 (UTC+8 time), the gambling DApp, BigGame, was first exploited since BigGame was one of the DApps which pay CPU resources for their players. Specifically, the attacker hijacked the transfer receipt and embedded inline actions in the onTransfer handler. Since BigGame pay for the CPU time, the attacker could deposit some EOS into BigGame for 0 CPU cost and hijack the transfer receipt sent by eosio.token for embedding malicious inline actions.

The transfer receipt hijacking could actually happens in any EOS token transfer. At 3am 11/7 (UTC+8 time), BetHash was attacked in an alternative way. Specifically, BetHash has a dice game which allows players to guess the number from 0 to 100. After each run of the dice game, the dicereceipt() function of BetHash’s smart contract would be invoked to notify the player. Therefore, a malicious player can hijack the notification and embed malicious inline actions. But, she need to pay for the bets. The interesting part is that the attacker kept putting 0.1 EOS bets on under 97, which made her always get 0.1011 EOS back and successfully hijack the notification. Figure 8 illustrates a successful attack.

Figure 8: Successful CPU Resource Exploit (Source: https://eosq.app)

Until 3pm 11/8 (UTC+8 time), not only BetHash, but also other dice games including EOSBet, EOSMMM, Trust-Dice, WinPlay etc. were attacked. For example, EOSBet was attacked by several players (e.g., hotsexygames, cyscyscys235, and juyhgdf1234u) continuously. After analyzing those transactions, we found that almost 38 seconds of CPU resource was exploited in EOSBet in last two days. Typically, a malicious transaction consumes 52 ms of CPU on average while a normal transaction only consumes 2 ms. Although EOSBet claimed that they would raised the bet amount to increase the cost of an attack, while the reality is that it’s under attack all the time. Figure 9 shows EOSBet CPU consumption which is always 100%.

Figure 9: EOSBet CPU Consumption (Source: https://bloks.io/account/eosbetcasino#keys)

Starting at 3am 11/11 (UTC+8 time), bad actors found that the bidname function of the system contract, eosio, could be exploited to obtain the airdrop without CPU cost. This is how it works. If you want to get a short account name, for example, baaa, you place a bit greater than 0.0001 EOS to start. When someone places a 10% or higher bid on that short account name, you’re overbidded and the 0.0001 EOS would be refunded. Specifically, eosio::bidrefund would be invoked by eosio to send the refund back, which could be hijacked while notifying the receiver as mentioned earlier. The worse thing is that eosio account has unlimited CPU time. This could make the EOSIO network run a heavy workload with no staked or rental CPU resource. Figure 10 shows an attack transaction. As an opinion from the community, this issue could be easily solved by raising the minimum bid price.

Figure 10: Exploit eosio's CPU Resource (Source: https://eosq.app)


Right after the BetHash hack for embedding EIDOS mining actions, more and more DApps, DEXs, and even Exchanges were exploited or identified to have such issues. An ultimate solution is checking if the destination account is a smart contract before sending EOS tokens, notifications, etc. out. Unfortunately, there’s no such API for checking the state of an EOS account in the smart contract on EOSIO network. We suggest smart contract developers to use services such as DAppShield to filter out contract accounts.

About us

PeckShield Inc. is an industry leading blockchain security company with the goal of elevating the security, privacy, and usability of current blockchain ecosystem. For any business or media inquiries (including the need for smart contract auditing), please contact us at telegram, twitter, or email.


08 November 2019