Future Enhancement: Add a referendum system for DAC users

[lukestokes]

The details (and merits) of this proposal still need to be worked out, but here's a starting point to have the discussion based on this comment in Discord:

Hoa Truong Yesterday at 10:10 PM Besides WPS, can we have a referendum system? More DAC activities make the DAC tokens more active.

1. Any members can make a referendum, it will also lock a certain amount of tokens in a period of time (costs fee)
2. Custodians will review it before bring it live onto the blockchain
3. Members vote on and lock their tokens in a period too (no fee)
4. A referendum can need 5 or 10% of the total tokens voted to be approved (ex.)

The above is just my thought on how to make the DAC tokens more acitve. Further, in a country scale, referendum is needed for a DAG.

Ideally, we can explore using existing referendum code that has already been developed and customize it for our needs.

[dahacouk]

Linking to the comment (and subsequent chat) in Discord for historical purposes: https://discordapp.com/channels/435916207162654722/441004169319677952/610294100713013268

[eosdacvietnam]

Values that referendum could bring to the DAC:

1. More decentralized
2. Voice from members
3. Bigger impact on the DAC than WP, so a referendum should cost fee. 3.1. Fee save costs like RAM, CPU, NET 3.2. Fee makes members think more and be responsible for the referendum before submitting. Help avoid spam, harmful or bad referendum.

Values could come to the DAC Factory through voting and hosting:

1. More voting options when setting up a DAC: based on token voting, human voting, or both (KYC options)
2. More network setting selections: 2.1. Running on EOS or BOS: KYC is optional 2.2. Running on WORBLI: KYC is required (saves costs of KYC process)

The process of rereferendum:

1. Integrated to the DAC like MSIGs
2. Custodians review first before bring it live on the blockchain 2.1. Certain amount of tokens required (higher fee) achieved to bring it live first, custodians do not need review
3. Members start to vote
4. If the referendum reach a certain amount of tokens, it will get approved or declined

P/s: Members must vote for eosdacserver to raise a referendum.

[michaeljyeates]

Technical plan for referendum

There are 3 types of possible referendum

1. Binding referendum where the referendum contract uses a custom permission to automatically execute certain pre-approved actions. Custodians would not be able to prevent the on-chain execution of this action (unless they remove permission of the referendum contract). The authority account will add an extra permission called referendum which will be linked to the approved actions. Thresholds for passing of these referenda will be fixed based on the action which is being sent.

2. Semi-binding. If the action that the token holder wants to be sent is not on the list of approved for a binding referendum then they can propose a semi-binding referendum which, if approved, will automatically create an msig proposal which will be presented to the custodians. Currently, only custodians or admins can propose msigs so this will provide a route for token holders to get a proposal in front of the custodians. The threshold for this type of proposal will be lower than a binding proposal, unless high-risk actions are involved such as setauth, linkauth, setcode and anything involving transfer of value (eg. token transfer or RAM purchase).

3. Opinion. This type of proposal is just a way for token holders to voice their opinion about a particular subject. It will not include an action which should be executed on chain and the token holders should understand that this is not binding at all (the custodians are free to respond however they like).

The new observers pattern in the contracts should allow us to only count staked tokens, or even allow liquid voting for any particular referendum.

[michaeljyeates]

We can add an option to either use stake based voting, or per-account voting.

There should be a major warning saying to only use per-account voting if you are on a chain which has KYC, even then if there is enough value at stake then it is possible to game. Account based voting should never be configured when there are approved binding actions which can transfer value.

[michaeljyeates]

https://github.com/eosdac/eosdac-contracts/tree/referendum/referendum

[michaeljyeates]

Referendums are deployed here for testing, only opinional referendums supported now

http://light.dev2.dacfactory.io/