EOS Town Hall — February 4, 2019

Agenda:

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

Guests:

Tim Lewis — LibertyBlock

Luke Stokes— eosDAC

Josh Kauffman — EOS Canada

David Packham — EOS42

EOS DAC:

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

Tools:

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

https://steemit.com/dac/@eosdac/tutorial-launching-your-own-dac-on-the-jungle-test-network-with-eosdac

https://www.youtube.com/watch?v=AvM0sA07IME

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)