EOS Town Hall — January 28, 2019
– Should future EOS tokens sent to eosio.ramfee and eosio.names accounts be allocated to REX?
– Should we burn accumulated un-used inflation (4%) in eosio.saving?
– Delete ECAF Referendum
– NET Updates
– Lost Key Updates
– LiquidEOS scaling solution feedback
Tim — Liberty Block
Kedar — Liberty Block
David — EOS42
YVES — EOS Nation
Should future EOS tokens sent to eosio.ramfee and eosio.names accounts be allocated to REX?
– Initially, fees would be burned and was curious about the rationale behind moving tokens to REX instead of burning them.
– They would offset the costs of BPs on the network. Solely linked back to encouraging and incentivizing users to participate in the REX.
– Most tokens are consolidated within exchanges. Through REX and having better dividends or more pools within REX users would be incentivized to take coins off-exchange which possibly encourages voting.
– Within REX you have to vote for 21 BPs. Are people looking at just top 21, all BPs, or proxies?
Should we burn accumulated un-used inflation (4%) in eosio.saving?
– Unused inflation just ballooned to around 24.8 million (~$60 million) tokens in the savings account. Potential security risk and it’s still being refilled.
– Non-use of tokens in a large bucket isn’t helping anyone.
– Do we want to see a system that utilizes the fee and has it destroyed.
– Destroy fee and savings and hit 0% inflation.
– Community sentiment is leaning towards burning 4%.
– Reduce the inflation to 1%, so tap is turned off.
– The initial idea was to fill up WPS pool, but there’s no system in place.
– Burn current tokens and turn it back on when there’s a system to allocate usage. This number will be a much smaller number than currently.
– Savings account was merely meant to be set aside for mass infrastructure level work. If the community decides it wants to remove the dependency on Block.one the eos.io savings account could be used for hiring a dev team.
– It’s intended for significant investments, but no one has come up with any use-cases.
– Monthly or quarterly vote on the eos.saving bucket. (encourages voting)
Delete ECAF Referendum:
– 15% came about because of 10% Block.one owns. Remove 10% from Block.one and make threshold 5%.
– Sliding scale for participation. (2/3+1 of # of votes to become BP)
– BPs can signal intent, and the community can take a set time to vote in agreement/disagreement.
– Deleting without an alternative for arbitration is irresponsible.
– Not sure it’s a bad thing that we won’t reach 150 million.
– The referendum can reach 5% if proxy’s participate and communicate with BPs.
– Igor from EOS RIO helped with analysis.
– Enough info at this point to make a decision.
– Settled on a number that they want to change the net parameters to.
– Block size is too permissive and can get too large.
– Has to happen before REX comes out or else it’ll be extremely inexpensive to spam the network.
Lost Key Updates:
– Finished testing and should have something out within 3–4 weeks.
LiquidEOS Scaling Solution Feedback:
– Yves heard some dApps aren’t joining the network cause of high costs. Airdrops cost too much, and there’s a shift in people building their own chains rather than using mainnet.
– vRAM is an alternative storage solution for developers building EOS dApps that is RAM-compatible, decentralized, and aims to enable storing & retrieving of potentially unlimited amounts of data affordably and efficiently.
– Through Dapp Service Provider (DSP) you get access to RAM and have proof that transaction is valid and can deploy on the mainnet. Has the potential to create a new marketplace.
– Testnet is already working. According to LiquidEOS, this can reduce RAM cost by 1,000,000x current price. Can have externalities to RAM value.
– RAM usage is way more optimized than LiquidEOS states.
More on vRAM below:
– Identify next steps for monthly or quarterly vote on the eos.savings bucket.
– Identify next steps for sliding scale for referendums.