Notes Created By: LibertyBlock
- Continue the discussion about eos.savings
- NET Optimization (Kedar)
- Continue discussion about the 15% “threshold” for referenda and define a meaningful but achievable level. (David)
- Discuss the case backlog for individuals who filed claims and cases under the interim constitution and suggest potential resolutions. (David)
Tim Lewis — LibertyBlock
Kedar Iyer — LibertyBlock
Kevin Rose — EOS New York
Luke Stokes — eosDAC
David Packham — EOS42
Congratulations to Luke for the official launch of eosDAC, a community-owned block producer!
Vote for custodians using the eosDAC member client.
Kevin: Development of the hardware wallet is still underway. Last week, the first proposed replacement to the current EOS constitution went on chain called the EOS user agreement. It currently sits at roughly 6 million votes. This is still not close to the requisite 15% vote of roughly 150 million. Kevin can’t wait to grow after months of stagnation and indecision.
The 15% Threshold is Arbitrary
David: 15% is an arbitrary number that was predicated on the assumption that there would be a high level of voter engagement. What we’re seeing is that engagement isn’t that high, and even the most popular referenda won’t reach 15%. The community needs to signal how to better adapt that to get things passed. We have to completely reassess if 100% approval is the same thing as a vote being popular. How does the group process this and concretely define what is an acceptable level of healthy level of voter engagement? Even 5% could work but is that really what we should be using as the basis?
Kevin: The threshold doesn’t matter. Permissionless voting doesn’t warrant forcing users to vote once something hits a certain threshold. Let’s say there is a 51 million vote threshold, but it only gets 50. If BPs don’t act, standbys can take votes. Once you think that through, any threshold becomes meaningless and becomes a personal threshold of every organization as a Block Producer.
Kevin Wrote about this a few weeks ago here:
Tim: Can we start talking to mainnet Block Producers that would signal yes so we can start taking action? Another referendum with signals of 15 of the top 21 Block Producers is enough to get started.
Do we have a polling system to see how Block Producers signal towards referendums?
Kevin: EOS Titan made a tool to filter Block Producers in a grid view to see what they support. These UIs will be the key to help voters understand who to vote for.
EOS Titan Heatmap:
How do we execute on some of the more significant issues?
Block Producers should vote and signal which referenda they support to spark action by letting people know where they stand.
The Trouble with Voter Engagement:
Luke: eosDAC put the 15% threshold in their constitution as well. Around 2500 member accounts took months to get to 15%. It took forever to get these votes and stakeholders were getting frustrated. The community block producer reached 14.5% and eventually they decided to launch on the 14th. Although eosDAC might have a harder time reaching a consensus, everyone should continue to further any ongoing conversations to push for community involvement.
Luke: The Telos DAC token airdrop for voter incentives was just enough to get people to vote; this could be a viable, temporary solution to increase voter participation in referendums.
Luke: It’s interesting to think of proposals as polls, but we should define what the quorum is for each proposal. For example, one could signal to block producers that they would like to vote when the referendum hits x %.
The 15% Threshold No Longer Makes Sense.
Kevin: We have a more mature blockchain, but we’re applying the same restrictions from launch to less important matters that actually hinder the progress of the ecosystem.
Kevin: People will wake up and realize the threshold doesn’t matter once the first time a block producer moves up 20 million votes because a referendum they support is what people want. It’s up to UI providers to show what block producers support and don’t. We need to communicate with block producers how important it is to voice who they support with the rest of the community.
What referendum item can we test this out on?
Kevin: It’s a good, but an unrealistic, idea to expect voters to go back after the expiration date and check what block producers supported. Eos.savings could be something to start with, but it’s probably the most complex issue to move on.
Kedar: It’s simple to print savings again if necessary. It’s not difficult to add EOS to the chain, but it is hard to reach a consensus on turning off inflation. Should we act on turning off the spigot and turn off inflation until actions start?
David: There’s an opportunity there to fund unforeseen future needs. That said, there isn’t any justification for the current buildup of token reserves. A controlled burn with referenda proposing burn limits on a quarterly basis could be implemented relatively quickly. Kedar has an existing proposal to get this started.
Kedar: The best way to get them to pay attention is to pose on-chain and include the result of the vote in the referendum. Let token holders know who supported and who didn’t.
Luke: The burn is a complex economic issue and that it might not be the best place to start. Scott from Greymass talks about how inflation is important in democratizing distribution of newly minted EOS to non-block producers.
Scott explained to Luke that the system is not well designed. If inflation to savings is higher than block producers, then it’s okay, but block producers are entrenching their positions due to the lack of structure around savings.
Tim: Maybe we should use savings to incentivize voters.
Luke: This sounds good but could introduce negative externalities. Eos.savings can be seen as insurance in case Block.one doesn’t fulfill its promises to the community.
EOS User Agreement
Kevin: The EOS user agreement might be a better place to start. It creates somewhat of a consensus on-chain to move in a direction and get signaling conversation going with token holders. If and when signaling looks right on the user agreement, we can address larger issues.
Kevin: Block producer incentives set a game theory of referendum. In this case, the threshold for EOS NY is low because they wrote it.
The user agreement poll:
What is Kevin’s expectation on when this could be implemented? How can we help?
Kevin is accepting help to translate the document into Mandarin and Korean. They did not include this in the referendum, but it’s a nice signal to anyone who doesn’t speak English. We should wait till it’s translated, so Block Producers in those regions have time to deliberate over it.
Next Monday’s call is specifically about starting a conversation with international block producers to create signals and pass the user agreement. Any change to the user agreement shows the community of action being taken, encouraging others to do the same.
Kevin will present the case to get the ball rolling on this so we can move towards action.
In the meantime, the group can push for rallying standby block producers and top block producers on the list.
NET Optimization Updates
Kedar has determined parameters they want to change. (from 1mb to 512kb)
The target is 10% and will go down by half. Kedar is hoping more staking is required, and that congestion is triggered 1–2x per day to get people staking NET tokens.
Passing a proposal on Kylin is tough. Kedar is looking to get it passed on Jungle and will submit a mainnet proposal to get things going.
How do we resolve the case backlog?
David: We’re in a situation where the interim arbitrator has not processed cases. The underlying issue is that good faith purchasers bought into missing features. One outcome is that block producers might get class action lawsuits filed against them. We must collectively decide what to do with the backlog of cases. We have a blacklist of accounts that are being frozen. We need to figure out, from a leadership perspective, what to do with these complex cases.
If we enter into a new constitution what do we do with the case backlog?
David: Let’s say agreement gets superseded in 6 months. It’ll be the user agreement that applies. We could choose to say it doesn’t matter, but there will likely be blowback from that. It’s imperative to discuss the unintended ramifications of the actions we take and what we base those ramifications on. Should it be by the present agreement or by the standard at the time?
This is an important issue, however, moving towards a new resolution of the user agreement is still the number one move.