EOS Town Hall - February 4, 2019

Notes Created By: LibertyBlock


  1. EOS DAC

  2. Remove vote decay for proxy if proxy votes regularly

  3. Discuss next steps for a monthly or quarterly vote on the eos.savings bucket.



- 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.

Eos.savings bucket

- 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.

Follow Up:

- 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)