What REX Means for Token Holders
by Haley Thomson, Head of Strategy at EOS Cafe Calgary
Dan Larimer shook things up last Thursday with his “Proposal for EOS Resource Renting & Rent Distribution”. The proposal includes sweeping changes to EOSIO software and many complex concepts. It left even the most astute EOS enthusiasts with many questions and much is still unclear about the proposal.
While this proposal centers around adding a rental market for EOS bandwidth (CPU), the near term implications for the average token holder actually have nothing to do with CPU at all. Even if you assume that the rental price of your CPU is $0, token holders should still be very excited about this proposal.
Don’t get me wrong, the ability for dApps to rent bandwidth for a fraction of the capital cost of owning is great for adoption, and the prospect of all token holders being “landlords” will be very valuable long-term. But a price of $0 for CPU in the near term isn’t a crazy assumption (given the limited demand and near endless supply).
What really matters to token holders short term is the Resource Exchange (REX). REX is a bucket that collects all EOSIO resource fees including RAM sales, fees, and name auctions. The future price of CPU rental may be uncertain, but revenue from RAM and Names are very significant. Currently these resource fees are unallocated but this proposal changes that, and that’s big news.
At the current price, $1.50 of RAM is created and sold with every block. That adds up to over $250,000 a day of unallocated revenue that could soon flow to REX. Forget the CPU market, how does a token holder get a piece of that?
The mechanics of REX are actually pretty simple; to receive network rewards a token holder has to lend their EOS to REX, in exchange for REX tokens (T-Rex), at a 1:1 ratio.
These tokens are non-transferable, there will be no market for them, they are simply an “accounting artifact” that can only be exchanged between REX and an account holder.
While you hold T-Rex you collect your proportional share of all revenue that flows to REX over that period. So if you hold 50% of all T-Rex tokens for a day, and 40,000 EOS in RAM sales are collected in the REX bucket that day, you will receive 20,000 EOS (50%) in rewards when you exchange your T-Rex tokens, plus the original EOS you lent.
There is NO RISK to the token holder in lending EOS to REX. REX will, at a minimum, always hold the EOS that was lent to it. Since T-Rex is distributed at a 1:1 ratio there will never be fewer EOS in REX than there are T-Rex held by account holders. T-Rex can be exchanged back for EOS at anytime.
There will however always be MORE EOS in REX than what was lent to it. This is simply because fees slowly trickle in block by block. If you held T-Rex for one block that included a eosio.ramfee transaction, you are entitled to a portion of that fee. Token holders who lend to REX for any significant amount of time will ALWAYS receive some reward.
From a token holder’s perspective it’s really quite simple.
Completely ignoring CPU all together this proposal gives token holders means to collect significant rewards that are currently unallocated, without taking any extra risk. Since all token holders are facing a 5% annual inflation this is welcome news. So what’s the catch?
The first catch is pretty simple, as you can see in the diagrams above the CPU staking power of the token holder drops when they lend their EOS to REX. Since this proposal does include the rental of CPU bandwidth, this makes sense. This means holders who are using their bandwidth for transactions might choose not to lend to REX because they are using their resource. If you send your EOS to REX you will have fewer moves on EOS Authority’s Space Invaders game available to you, for example.
Since 99% of token holders are not using their bandwidth for transactions this shouldn’t be a big drawback. But what about voting?
One of the most important elements of Dan’s proposal is that you can only lend EOS to REX if you are voting at least 21 BPs. Not only does T-Rex contribute to voting power (as shown in the diagram), but voting is a prerequisite to owning T-Rex at all. While this may seem like a “catch” for some, it is a very elegant requirement that concentrates the “dividends” of the EOS network into the hands of the token holders actively participating and voting in beneficial ways.
This voting prerequisite is one of the simplest parts of Dan’s proposal, but likely the most important. The network benefits greatly from fair and thoughtful voting, and suffers in its absence. Combining REX and this voting requirement will either ensure that most token holders are acting beneficially, or that those who are reap all the rewards.
Bottom line is this proposal is a win/win/win. Token holders gain access to rewards that were currently unallocated. Incentives get created that improve the value of the network as a whole. And, although we didn’t emphasize this point, dApp developers gain access to network bandwidth at rental rates that will be a fraction of the ownership cost.
If it seems a little complicated to you, don’t worry, it won’t be for long. In practice, collecting rewards from REX will be a simple one-click operation in a wallet. It will be some time before this proposal is formalized and approved. In the meantime you can prepare by researching 21+ top notch BPs and voting for them, or finding a proxy to do it for you. While you’re at it, don’t forget to vote for eoscafeblock.
