Select Page
Addressing the EOSIO REX Exploit

Addressing the EOSIO REX Exploit

The EOS network recently experienced an exploit where a small number of accounts purchased a large amount of REX resources for about 300 EOS and used that to extract 30,000 EOS in manufactured winnings from the EOSPlay gambling app. EOSgo has an article that explains this. In short, by buying a very large amount of EOS CPU resources cheaply, the exploiters were able to essentially shut down the EOS network to nearly all transactions but their own and exploit the process that EOSPlay used to generate random numbers, essentially ensuring that their bets would be winners. Because the EOS network became clogged and the cost of CPU resources grew very large, the EOSPlay app was not able to pause its contract to stem its losses.

While this represents a large loss for EOSPlay, this exploit poses a more substantive threat to EOSIO blockchains. If the chain can be made generally unusable for all by a single user or small cabal, then it greatly limits the value of these chains, particularly for enterprise users or IoT devices. EOSIO creator Dan Larimer has commented on Twitter that the EOS network operated correctly, and that similar types of clogging attacks have been seen on Bitcoin and Ethereum networks. While this is factual, it does not alleviate the fact that such exploits severely diminish the value of these networks as vehicles of the future economy. Bitcoin and Ethereum likely have no clear ways to resolve their issues, but EOSIO networks have greater tools at their disposal. Exploits capable of rendering a chain unusable for most users need not be accepted as proper operation. I propose the following avenue of exploration for resolving this issue. The Telos Core Developers will undertake this exploration for addressing this exploit on Telos and will share our findings with other EOSIO chains. We welcome any interested EOSIO developers to join us as we seek workable solutions.

A Proposed Solution for the EOSIO REX Exploit

No doubt, many factors contributed to the exploiters using this attack vector to syphon off funds from EOSPlay. Among them:

  • EOSPlay used a method of random number generation with inherent risks
  • EOSPlay did not adequately stake resources for its own usage but relied on free “overflow” resources
  • EOSPlay did not provide themselves a lightweight or alternative way to pause their contract
  • EOS has abandoned dispute resolution, therefore reducing the risk to the exploiter of tokens ever being recovered once taken

Addressing any or all of these factors will alter the risk/reward calculation for any future users of this exploit. Nonetheless, we must accept that as long as this exploit remains viable, it may be used by bad actors whose goal is not solely to steal tokens from an EOSIO chain but to render it unusable to many. Therefore, no amount of reducing these contributing factors alone will adequately eliminate the risk. This exploit must be addressed in order to ensure each chain’s ongoing viability and attractiveness to developers as a platform.

The simplest way to address this exploit would seem to be capping the amount of REX that any single account can buy. For example, limiting any single account to purchase no more than 0.3% of all REX for CPU at any one time would mean that about 300 accounts would need to be coordinated in order to purchase an amount of resources able to clog the network. While this could certainly be automated, the limitation of REX purchase by any one account would have an additional benefit.

In terms of usage, 0.3% of network CPU should allow nearly 1 million transactions per three-day period if the chain is capable of 89 million transactions per 24 hours, which is the current EOS record according to Blocktivity.

If no single account could purchase more than 0.3% of the available CPU through REX, then apps with greater needs would be incentivized to stake system tokens for the portion of their resources needed above this. With an upward limit on CPU resource purchases from REX, large apps would better able to sustain operations during periods of network attack. This may actually be the more powerful component of this solution. Providing rules to help enforce the use of good practices, such as not relying on free network resource, is a bit like a seatbelt law: some people will see it as intrusive, even if it is effective. Ultimately, the community should decide if preserving the right for a single account to capture the bulk of network resources by purchasing cheap REX is an acceptable practice on the network. At this stage, the TCD is only exploring the feasibility of such a solution.

In tandem with this limit, a small resources reserve maintained by the Telos Foundation or a similar entity on other EOSIO chains would enable apps under attack similar to EOSPlay to at least pause their operations to halt an ongoing exploit. The threat of action to reclaim tokens through on-chain dispute resolution may serve as further disincentive to attempt such an exploit in some cases. Some EOSIO chains will more easily be able to implement some of these approaches than others. Because any such changes have the potential to alter some aspects of token value or app operational plans, chains should ensure that their communities support such changes.

REX is an important tool for dapps and users. However, over-reliance on REX exacerbates the potential of this exploit. Telos may have a particular vulnerability because its very high staking reward has caused a greater percentage of available system tokens to be staked to Telos REX than on any other EOSIO chain.

Next Steps

The Telos Core Developers will begin exploring this possible solution to this exploit to determine what benefits and costs it may have. Naturally, the limit amount of 0.3% is only a jumping off point in exploring this possible solution.

The TCD will welcome input and participation from others interested in exploring solutions to this exploit. Upon achieving a better understanding of the feasibility and ramifications of such a change, the TCD will make a recommendation to the Telos block producers and community and will share its findings with the broader EOSIO community. If the TCD ultimately recommends such a change, the block producers and community may decide whether the situation demands immediate action, a governance amendment ballot, or some combination thereof.


About the author: Telos architect and whitepaper author Douglas Horn leads the Telos Core Developers. He is the founder of

Telos Users Guide: Understanding Telos REX

Telos Users Guide: Understanding Telos REX

Telos REX is a way to receive a high yield on a cryptocurrency with strong technical development and leading blockchain features. The current annual percentage rate yield for Telos REX is over 30%. Remarkably, this high yield is not earned at the expense of inflation. In fact, Telos is currently the only third-generation blockchain with 0% inflation.

Understanding Telos REX

Telos is a third-generation blockchain based on the eosio platform. It has fast block times, fee-less transactions, powerful smart contracts, and high capacity. In fact, Telos has the second highest record for the most transactions per 24 hours of any blockchain, according to leading industry benchmarking site

Telos is based on delegated proof of stake (DPOS), where instead of costly and inefficient proof of work calculations, the blockchain is secured by the votes of its stakeholders delegated to the validating nodes, called block producers, that they like or trust the most. The block producers receiving the highest number of votes, as measured by staked tokens, are placed into a schedule to produce blocks on the chain. Freed from performing proof of work calculations, these block producers can instead use their high-end infrastructure to validate more blocks, faster, and with higher capacity. They are paid for providing this infrastructure and the selected block producers change constantly based on continuous user voting.

By staking their tokens, DPoS chain users not only receive the right to vote for their validating nodes, but also reserve usage rights (resources) on the blockchain. An account with 1% of the staked tokens on a network may control 1% of the network resources. This is important to dapps and other users. However, not every person staking tokens will require all of the resources their staked balance will reserve for them. Similarly, not every dapp will have the required balance of tokens to reserve the network resources that they require.

The imbalance between users with more or less resources reserved than they actually need creates the opportunity to have a Resource EXchange (REX) so that these users can more efficiently use the system. Users who need more network resources than their staked balance allows can purchase the temporary rights to use the unused resources of other users.

Block explorers like track Telos REX statistics.

How Telos REX works

Telos users can stake their TLOS tokens to the REX resource exchange, which puts their resources up for sale to others who need them. This is true of many EOSIO-based blockchains such as EOS. However, because of the very high capacity of EOSIO relative to current needs, REX rewards are quite meager across most chains. Telos is the standout exception to this rule.

When Telos launched, it reserved a group of tokens to distribute to EOS genesis buyers whose tokens were stuck on exchanges at the time of the EOS snapshot. Any such exchange could request these tokens back for their users, but only exchanges, not users could do so. Unfortunately, few exchanges participated in this program and a large amount of tokens stood idle.

As the third-generation blockchain with the lowest token supply by far, Telos could not afford to simply dispose of or burn these tokens. TLOS tokens have only four digits of precision meaning that if a TLOS token had a value of USD $10, then the smallest payment amount possible with TLOS would be 1/10th of a cent. This may sound small, but for a blockchain that will be used by IoT devices to perform micropayments, this is a fairly large figure. Reducing the token supply would exacerbate this problem by driving up the value of the remaining tokens. Therefore, burning these tokens was not a good option.

Instead it was decided to use this supply of tokens to first end inflation on Telos and pay block producers and other chain functions like Telos Foundation administration and worker proposals from this pool of funds. It was also decided by the Telos community to distribute a portion of these funds to any current users who were actively participating in the Telos chain through voting and use. (This occurred in a historic smart contract-controlled and on-chain tracked governance vote called the Telos Economic Development Plan or TEDP.) REX staking allowed this distribution. A secondary benefit of this is that, because some blockchain investors are very interested in staking rewards, a respectable staking reward for Telos REX would attract additional users to Telos, many of whom may become regular users.

So, Telos REX receives funds from users renting the use of resources just like on any other EOSIO chain — but it also receives an additional 1 million TLOS each month from the TEDP. This 1 million TLOS, plus any others from resource rentals, are shared on a pro rata basis among all users who have staked their TLOS to REX. If one user has contributed 3% of the TLOS in the REX pool for a given period of time, then that user will receive 3% of the funds paid into REX during that same period.

With 1 million TLOS being paid into REX each month, the staking rewards are quite significant. For example, if 40 million TLOS are in the REX pool and just 1 million are paid in, then every 100 TLOS token in REX would earn 2.5 additional TLOS in that month. Over 12 months, that becomes 30 TLOS per 100 TLOS or a 30% annual yield. If more TLOS are paid into the fund, then the return will be lower. If less, then higher.

The Consequences of Staking TLOS to REX

When a user stakes TLOS tokens from their account into REX, they no longer receive the benefit of the network resources for those tokens. For that reason, it’s wise for users to reserve an amount of TLOS to support their network needs. Usually this will be quite small for users not running large dapps.

TLOS staked to REX are still counted towards a user’s voting weight for block producers. In fact, voting for at least 21 individual block producers or a voting proxy are required to qualify for staking to REX. However, in the initial version of Telos REX, these TLOS no longer count towards voting on Trail Voting ballots such as worker proposals, ratify/amend ballots, or arbitrator elections. The Telos Core Developers and block producers are working on correcting this so that soon these votes will work more like block producer voting.

How to Stake to Telos REX

A step-by-step tutorial for Telos REX staking is coming soon, however, REX staking is fairly simple. Using the Sqrl wallet (version 1.0.12 or higher) or the REX interface on a block explorer like, Telos users can easily add their TLOS tokens to the REX pool to earn rewards.

Liquid TLOS tokens can be staked directly to REX. This is also referred to as “lending” TLOS to REX. TLOS tokens already staked for network resources (CPU and NET) can be instantly unstaked directly to REX without needing to wait for 3 days to unstake, as is otherwise required. This option is called “unstake and lend” on most interfaces.

Once TLOS have been lent or staked to REX, there is a maturity period of four days before they can be removed again as liquid tokens. When they are removed from REX staking or lending, they also receive any additional rewards they earned during the staking period. TLOS tokens may also be left in the REX staking pool after maturity for any period of time and instantly unstaked as desired. Any TLOS remaining in the staking pool will continue to earn rewards throughout the time the are staked with no need for additional actions. There’s no benefit to regularly unstaking and restaking tokens.

About the author: Douglas Horn is the Telos architect and whitepaper author, and the founder of GoodBlock, a block producer and app developer for the Telos Blockchain Network.

More about GoodBlock can be found at:

Join us on Twitter @GoodBlockio

Vote for GoodBlock on the Telos Blockchain Network @goodblocktls