EOS Town Hall — February 4, 2019
- EOS DAC
- Remove vote decay for proxy if proxy votes regularly
- Discuss next steps for a monthly or quarterly vote on the eos.savings bucket.
Tim Lewis — LibertyBlock
Luke Stokes— eosDAC
Josh Kauffman — EOS Canada
David Packham — EOS42
- eosDAC is an evolving Decentralised Autonomous Community (DAC) focused on becoming a leading EOS.IO Block Producer serving the EOS communities worldwide.
- eosDAC creates the tools and smart contracts it needs to function and shares these with the EOS community.
- There’s potential for the DAC model to function as a mechanism for multisig control.
- Tim’s initial thought was that every block producer should be a DAC to avoid collusion. He’s extremely excited to see development around this concept.
Part 1: Membership Client (https://members.eosdac.io/)
- The client includes voting and proposal system.
Part 2: DAC Factory
- Takes existing functionality and makes it easy to deploy other DACs.
Tutorial: Launching Your Own DAC on the Jungle Test Network with eosDAC
Remove vote decay for proxy if proxy votes regularly
- Luke’s proxy has around 2.9M EOS staked.
- Ash runs another proxy and is in favor of keeping vote decay to prevent creating two hierarchies of voters.
- Problem is not that people are voting and leaving. It’s that they are not voting. Luke thinks we could remove vote decay but hasn’t voted yes.
- Let people automate their vote to increase voter participation. Should we have a time limit? (ex: 3 month)
- Josh doesn’t think removing vote decay will draw people out but agrees there should be a limit on automated re-voting.
- Follow up from eos.savings discussion last week. https://medium.com/@eostownhall/agenda-be58876f5c81
- Savings could be drawn from mainnet community if they decide to take control of the development of the codebase.
- The community is looking for a degree of leadership and structure around this.
- Luke would like to explore worker proposal system (smart contract based) within the microcosm of EOS DAC. Next evolution could be a sidechain on EOSIO for system level DACs. From there a long-term solution could be ported into mainnet.
- Lack of clarity creates a need for a structured on-chain mechanism for transparent burns.
- More flexibility around creating burn and initiating fee to raise funds when necessary.
- Just one pull request to do code change on eos.savings can spark conversations.
- Outline code changes and impacts on the economy for more focused discussions. If there are multiple pull requests, weigh the pros and cons of each.
- Josh to reach out to Block.one to get eeps.io under github.com/eosio.
- Create multisig contract to burn January’s inflation on the savings account. (Jae Chung from HKEOS has been working on WPS)