EOS has had a rough time of it lately. Not only was it downranked by Weiss Crypto Ratings in their December 6 report (from B to C-), a consequence of the centralization implied by 0.01% of token holders controlling over 68% of the blockchain’s voting power, but projects have begun leaving its ecosystem.
DApps such as EarnBet have cited a combination of network congestion, dApp outages, spam and rising transaction fees, while social media app Karma jumped ship after complaining about “major points of friction” such as account creation cost, user experience, the cost of CPU/bandwidth and lack of access to funding from the ecosystem.
Recent events have led some to wonder whether Dan Larimer’s smart contract platform will be able to overcome the backlash, satisfy its large user base and network of developers, and fulfill its considerable potential. As it stands, there is a danger that more dApps will go the way of Karma and migrate chains unless EOS’ well-publicized problems are ironed out.
EarnBet serve EOS notice
The aforementioned casino EarnBet held nothing back in its recent article, whose title – “EOS 30 Day Notice” – left nothing to the imagination. Explaining one of the reasons for a blog that more closely resembled a broadside, EarnBet pointed out that “the network requires around 30 EOS staked to an account in order to perform a single transaction each day. Once billed as “free transactions for all,” effective EOS transaction fees now surpass even those of BTC. Instead of needing to pay $0.25 to transfer BTC, EOS users need to stake over $100 of EOS to make a single transaction on the network.”
The recent inability of EOS to process transactions for users who don’t happen to have a substantial amount locked up and staked is, according to Weiss Crypto Ratings, a result of the platform attempting to favor a feeless structure. As a result, the EOS platform seems ill-suited to new users who wish to make double-digit transactions on a daily basis, as they would need to buy thousands of dollars worth of EOS from an exchange and stake into their new account.
Attempting to grapple with this issue, EOSIO 1.8 enabled dApps to essentially pay for their users’ CPU. On the face of it, this was a nifty solution: since dApp developers are invested in and committed to the EOS ecosystem, they could improve the onboarding experience for users by covering their CPU costs. Alas, the unfortunate reality is that dApps don’t have sufficiently deep pockets to subsidize a user base potentially numbering in the thousands. Thus, neither users nor dApps are reliably able to cover CPU costs, with are – to add insult to injury – on the rise.
In the case of EarnBet, the casino has been forced to repeatedly raise its minimum bet to decrease betting volume. Moreover, at key times during the day it has experienced high levels of bettor traffic and, as a result, maxed out the CPU in its smart contracts. Worryingly, the dApp says it can only support 3-4 simultaneous bettors at any one time; any more and its contracts cease to function. Given that their ambition is to sustain over 10 bets per second, it’s no wonder they’re contemplating ditching EOS altogether.
The utility of secondary solutions
It is not uncommon for mainnets to utilize bespoke sidechains to address network strain. Ethereum dApps have done exactly that with options like Matic Network, a Plasma-based layer two scaling and performance solution which has taken some of the strain. Solutions of this ilk represent lifelines for dissatisfied EOS dApps, too.
LiquidApps is one example. With the goal of promoting mass adoption of dApps, the company engineers technical solutions to make developing easier and more affordable. To this end, LiquidApps provisions vRAM, a decentralized complementary memory solution for EOS dApps running on its DAPP Network. Earlier this year, freelancing marketplace Moonlighting availed itself of the DAPP Network tolbox to store substantial amounts of data off-chain, at low cost. And it’s not the only project to have done so: LiquidApps have been solving many EOS bugbears for over a year.
Of course, it’s easy to forget that EOS is less than two years old. Bumps in the road are all part of the journey. But if the network is to succeed, it must address the concerns of developers and, when needed, rely upon complementary projects that provide valuable services and fixes. More specifically, there needs to be a reduction in resource load and better pooling of resources for companies operating on EOS. dApp developers will wait with bated breath.
Vladislav Sopov