Create Smart Contract for Governance Voting using MYB

[mybit-bot]

Introduction: In a move to decentralise network governance, we want to make the first step towards migrating control away from the core team. To do this, we want to enable anyone to propose a new task for the MyBit DDF and allow holders of MYB to vote on the proposed tasks. This voting module should be agnostic and usable to other network voting events outside of solely the DDF.

Design relies on task:

17 https://github.com/MyBitFoundation/MyBit.design/issues/17

Requirements:

1. Quorum and other voting related logic will be implemented on the smart contract side. For the sake of testing let's require a minimum quorum of 20%. So 20% of MYB must be used to vote before anything can pass.
2. 51% votes and 20% quorum required to pass any vote.
3. Voting will only be enabled for 15 days, then the voting closes and if Quorum was not reached then the vote is inconclusive and no more voting is available.
4. Lock tokens to vote to verify ownership and be eligible to vote. Are there any preventative measures to stop someone from voting, withdrawing tokens, moving to a new address, and voting again with the same ones? Another option is to hash snapshots of token balances instead of requiring everyone to lock to vote.
5. Implement a multiplier where if tokens are locked for 6 months 1 MYB gives 1.5 Votes, and if locked for 12 months 1 MYB gives 2 Votes. If no locking for an extended period is done then 1 MYB gives 1 vote.
6. In this version, passed votes will not trigger any actions automatically. This will be added in after testing is completed.

Resources: https://files.mybit.io/files/

To submit please initiate a pull request.

Disclaimer: All work completed via the MyBit Decentralised Development Fund is property of the MyBit Foundation (CHE-177.186.963) and may be used, re-used, and/or distributed, re-distributed by the MyBit Foundation for financial gain. The contributor holds no warrant nor claims for any future payments resulting from monetisation schemes originating from the MyBit Foundation or any of its affiliates. Where law permits outside of open source regulations, the contributor is not permitted to distribute any work completed via the MyBit Decentralised Development Fund (DDF) for personal gain.

[status-open-bounty]

Current balance: 0.0 ETH Tokens: MYB: 0.00 Contract address: 0x9351d58932750a68c84043dde711f3c51997e952 Network: Mainnet To claim this bounty sign up at https://openbounty.status.im and make sure to update your Ethereum address in My Payment Details so that the bounty is correctly allocated. To fund it, send ETH or ERC20/ERC223 tokens to the contract address.

[georgiemathews]

I'm on it, any further details?

[0xjjpa]

Hi @georgiemathews, this particular task is not ready for development quite yet. I suggest you to subscribe to the issue, and you'll be notified when we update it ☺️

[cryptnotiq]

Hey @georgiemathews more details have been added and the task is ready to be completed. Please feel free to ask any questions.

[hieple7985]

I'm on it also.

[0xjjpa]

@hieple7985 @georgiemathews We don't have an assignation mechanism for tackling this with multiple submissions, so it's going to be on a first come first serve proposal. Whoever comes with a proposal that's approved gets the assigned bounty.

[bookmoons]

bookmoons/voting has some groundwork toward this. Compare. Passing tests for the initial pieces are in.

A central Governance contract can lock/unlock MYB tokens. Method createProposal creates a Proposal contract, 1 for each item. Voting is not in yet. The Proposal can manage the votes and have a limited lifespan. Does this seem like a reasonable direction?

I've built on the MyBit-Network.tech repo. Is that the right place?

Are there any preventative measures to stop someone from voting, withdrawing tokens, moving to a new address, and voting again with the same ones?

Wonder if it would work to postpone voting rights for eg 15 days after locking, the duration of a single vote. So you have to put them toward voting and not touch them for a while. It would ensure you're really committing the tokens. It would also mitigate people not involved in the community who make a huge buy in to cast 1 vote, then sell off. You have to tie up resources for a while to get to the voting stage.

[bookmoons]

Will change direction if the above doesn't work. I have something implemented on that model. bookmoons/voting. Compare.

Proposal has a 15 day lifetime. Users with locked MYB can vote with #approve or #decline. Votes are multiplied depending on the time your MYB has been locked. After voting closes, #approved gives the result. It passes if >= 20% of the total supply voted, and approval is >= 51% of the total votes.

Need to figure out how to advance time so I can fill out the tests. But I think a decent outline is there. Experimentally implemented a holding period so that the first 15 days after committing MYB cannot be used for voting.

[0xdewy]

Hey @bookmoons thanks for the submission. Could you make a pull request against our network repo? You can merge it into the baseline branch. Just store the contract in contracts/ownership/TimedVote.sol and add a test called timedVote.js.

I wouldn't create a new proposal contract for every proposal as that could get quite expensive gas-wise. I think it's a good idea to require users to lock for voteLength and require them to wait for voteLength before withdrawing. This will ensure that they don't enter already created proposals, or leave while a proposal is ongoing.

If you could just make the proposalID a bytes32 id of your choosing (this will later be sha3(creatorAddress, methodID, contractAddress, parameterHash)

[bookmoons]

Thanks a lot @kyledewy. Will make these changes and submit.

[0xdewy]

Oh @bookmoons and to increase the time you can use this within the truffle test:

    web3.currentProvider.send({
        jsonrpc: "2.0",
        method: "evm_increaseTime",
        params: [86401], id: 0
    });

[bookmoons]

Got a patch prepared to base quorum on committed MYB, in case it's decided to go that route. Mentioned in MyBitFoundation/MyBit-Network.tech#179.

[bookmoons]

Not sure if there's something I should be doing here, since it's already merged. Are there changes I should be making? I could jump on them this weekend. @kyledewy @PeterMPhillips

[cryptnotiq]

thanks for all the work @bookmoons - looks like it's coming along great. @kyledewy could you make sure to ping me on slack when everything is finalised here so I can give it a final review?

[0xdewy]

@bookmoons I will merge the patch now. Everything looks great, it's really well documented and well tested. @cryptnotiq everything is finalised.

[bookmoons]

Thanks a lot guys. Appreciate the attention to it.

[bookmoons]

Thanks for closing this.

Not finding any docs, but it looks like the way claims happen on the bounty platform are through merging of a pull request that closes the issue. So I maybe should have done that in the PRs. How would you guys like me to handle this?

[bookmoons]

Proposing a way to handle the claim. Opened MyBitFoundation/MyBit-Network.tech#204. It has an empty commit that changes nothing. And it closes this issue.

If this issue is reopened, then that PR merged, I think it will trigger a bounty claim.

[bookmoons]

Shoot, that doesn't seem to have worked. I guess it needs push access and has to merge into the default branch.

When the pull request is merged into your repository's default branch, the corresponding issue is automatically closed.

If the commit is in a non-default branch, the issue will remain open

Proposing to do this with a merge into the default branch in this repo. Opened #166 with that approach.

[bookmoons]

I see on Open Bounty that is now showing as a pending claim. Seems like the right direction. Maybe the platform only watches PRs in the same repo.

[bookmoons]

Not sure who I should be asking about this. Is it possible to have this empty PR merged to close this out? @cryptnotiq @jjperezaguinaga

[0xjjpa]

@bookmoons Yes! The open claim is there and now I just have to accept it, just a sec!

[0xjjpa]

@bookmoons The bounty payment should be on its way, thanks for all your work! Same to @kyledewy and @PeterMPhillips for the support ☺️

[bookmoons]

Received and happy. Thanks a lot everyone. Such a cool project. I'm holding onto as much MYB as possible.

If there's other smart contract that needs building, I'd be glad to do it with similar quality.

[0xjjpa]

@bookmoons Thanks for your kind comments! We have a Basecamp where we are trying to include as many community members as possible in order to share as much information about the company as possible. If you are interested, please send me an email to jj@mybit.io with your contact information. Thanks!