Please vote NO on EOS Mainnet launch until RAM issue is properly addressed

Issue: EOS currently appears to have an ineffective RAM policy which is hostile to all but the most trivial dApp developments.

Recommendation: Please do not approve the mainnet launch until these issues have been properly addressed.

Concern: Launching the mainnet with such a serious outstanding issue could render it very difficult to change or repair in the future, leading to a situation where EOS itself is simply forked into a new project which does not suffer from the deficiency. This may conceivably lead to a situation where all stakeholders in EOS lose.


A recent thread has started on the github discussion forum surrounding the apparently new requirements for staking RAM in order to create an account on the mainnet.

EOS is a smart contract platform, not an end user platform. It is the dApps built on top of EOS which will ultimately give the project value. Understanding this, it is important to properly address the needs of the smart contract and dApp developers. This means the contracts need to be the ones staking RAM and bandwidth, not the individual user accounts. The user experience is paramount. EOS should not get in the way of this, meaning a dApp needs to look and feel independent, with all aspects of the EOS chain hidden from the user experience.

The consequence of this is that most users should not even realize they are working on top of EOS, and they could have dozens of different accounts on the mainnet, each one belonging to a different dApp. Middleware may develop in the future to help end users manage these different identities, but in order to get marketshare, it is important that EOS be viewed by the development community as a tool, and not an obstacle to be worked around. The working philosophy should recognize that many end users will not hold EOS at all.

Failure to adopt this attitude will ultimately lead to a split in the nascent community, and a fork into a new community that does accept these principles. Such a community is likely to be ultimately more successful than EOS, as it is friendlier to the developers and to the end users.

Unless Dan or Blockone can explain why the issues raised in the above thread are incorrect, I recommend everyone hold off on approval of the mainnet until this very serious is resolved.


  • dwschumadwschuma Posts: 19 Jr. Member - 1/5 EOS Tokens
    edited June 19

    Afraid you may be too late to delay the mainnet at this point. You should know RAM is handled differently than bandwidth/CPU. In my opinion, this separation is done as fair as possible via a very clever method. May I ask, why you posted this in the governance forum as opposed to more technical oriented forums?

  • Chris_ZiomkowskiChris_Ziomkowski Posts: 4 Brand New

    This is a governance/philosophy question. Technically, the system as devised works for the very small marketplace that will be able to work within its constraints.

    The RAM model is simply a very bad idea as presently implemented, and has the possibility to very negatively affect the EOS project. Nearly every dApp will find it unacceptable and hostile. What is needed is a visionary change of what EOS is meant to be, not a low level technical bug fix. EOS is a platform for dApps, not an end user environment. Dan and Block One got this very wrong.

    If EOS continues with this RAM model, there could be very bad long term consequences. I propose that an appropriate action is to stop the mainnet launch and get the vision right and the issue resolved at the very beginning. Otherwise, there will likely be a fork, and a completely different project that does address this issue will have a substantial advantage.

  • dwschumadwschuma Posts: 19 Jr. Member - 1/5 EOS Tokens
    edited June 19

    Mathematically, the Bancor method works.

  • Chris_ZiomkowskiChris_Ziomkowski Posts: 4 Brand New

    Agreed. There is nothing technically or mathematically wrong. The way it is implemented in EOS (namely, based on user id instead of contract/dApp) is simply ill suited for the market. Only the governing community can require this to be changed. It is in all our best interests. It is important we delay launch of the mainnet until this issue is addressed.

  • Chris_ZiomkowskiChris_Ziomkowski Posts: 4 Brand New
    edited June 19

    BTW, since it appears that the 15% threshold has already been reached and we can no longer stop the mainnet from launching, I propose an amendment to stop issuing blocks and shut down the mainnet until the RAM issue can be resolved to the community's satisfaction.

Sign In or Register to comment.