Feature/dao proposals

[IanMendozaJaimes]

Contracts to be deployed:

• [ ] Dao
• [ ] Escrow
• [ ] Onboarding

Other considerations:

• [ ] Permissions need to be updated

This pull request doesn't interfere with the current behavior of escrow nor onboarding. It can be deployed safely.

---

This is a description of what it is implemented in this Pull Request. I left some Notes in italic to highlight changes that I made with respect to the original contract. If you feel any of those changes are incorrect please let me know.

Voice

There are four voice scopes so far:

• campaign
• alliance
• milestone
• referendum

Note: in the original contract, the campaign and referendum scopes had the values funds.seeds and rules.seeds respectively. I changed them because I thought the scopes were better with those names as those contracts are not involved anymore.

More scopes can be added by simply extend the scopes vector in the dao contract.

Voice update, decay, delegation, voting and revert vote work for all the scopes in the scopes vector.

All the proposals that inherit from the Proposal class use the same voting system. So if a proposal wants to be added the voting mechanism doesn't have to be changed. It will work as long as the proposal inherits from Proposal class.

DAO proposals

This refactor tries to replicate the behavior of the proposals contract.

The idea is that all the proposals inherit from Proposal class. This class implements methods that are common for all proposals:

virtual  void  create(std::map<std::string, VariantValue> &  args);
virtual  void  update(std::map<std::string, VariantValue> &  args);
virtual  void  cancel(std::map<std::string, VariantValue> &  args);
virtual  void  evaluate(std::map<std::string, VariantValue> &  args);
virtual  void  callback(std::map<std::string, VariantValue> &  args);
virtual  void  stake(std::map<std::string, VariantValue> &  args);

virtual  name  get_scope() = 0;
virtual  name  get_fund_type() = 0;

virtual  void  check_can_vote(const  name  &  status, const  name  &  stage);
virtual  bool  check_prop_majority(std::map<std::string, VariantValue> &  args);
virtual  uint64_t  min_stake(const  asset  &  quantity, const  name  &  fund);

virtual  void  create_impl(std::map<std::string, VariantValue> &  args);
virtual  void  update_impl(std::map<std::string, VariantValue> &  args);
virtual  void  cancel_impl(std::map<std::string, VariantValue> &  args);
virtual  void  status_open_impl(std::map<std::string, VariantValue> &  args);
virtual  void  status_eval_impl(std::map<std::string, VariantValue> &  args);
virtual  void  status_rejected_impl(std::map<std::string, VariantValue> &  args);

uint64_t  cap_stake(const  name  &  fund);

The methods create, update, cancel, evaluate, callback, stake are the main methods that all the proposals must have and are implemented in the Proposals class. So to implement a proposal, if the proposal adjusts to what the Proposal class does, one can only override the methods with the suffix _impl to implement the particularities of that specific proposal. If the proposal is too different like a referendum, one can override directly the main methods.

The following is a description of the behavior implemented for proposals in the dao.seeds contract, although they should work like in the original this brief description could help to spot any mistakes made.

Proposals base

All the proposals that inherit from this class will share the common behavior of:

• stake
• when pass proposal, addrep and refund stake
• when fail, burn stake or punish creator, depending on the state of the proposal
• max/min stake
• support table
• last prop table
• votedproposal table
• fund type
• scope

Each proposal has to implement only its particularities.

Alliances

Description

This proposal creates a lock in escrow contract with the 100% of the requested amount when it passes the voting period. It runs forever in evaluate status until the proposal is voted down and finally rejected or the lock is claimed or migrated to pool.

Organizations and residents can create this type of proposal as well, not only citizens.

Note: In the original contract, an alliance proposal runs for a year, but I remember that it was a solution for making the alliances run longer until golive so I think this prop fixes that running forever out of the box.

Campaign funding

Description

This proposal pays out the funds using the payout_percentages vector. The default vector is [25,25,25,25] but a custom vector can be provided. It validates the vector using the same method than the original contract. If the proposal is voted down, then funding gets cancelled.

Campaign Invite

Description

This proposal creates a public campaign in the onboarding contract with the 100% of the requested amount. It runs in evaluate status for 6 cycles (the counting starts from the moment the proposal is approved). If the proposal is voted down within this evaluation period, the campaign will be canceled.

Milestones

Description

This proposal runs for only one cycle, it pays out 100% of the requested amount. It doesn't have an evaluation period. Only seeds.hypha can be the recipient.

Referendums

Description

This proposal can modify a setting from the settings contract. It has different statuses than a normal proposal:

• open: the proposal was created
• voting: the voting period is running
• test: the referendum has passed, but the setting still unchanged
• evaluate: the setting now has changed

The referendum can be voted down in test and evaluate. In the case of evaluate if the referendum is voted down the setting is changed to its original value. Also theses two statuses can have different duration in cycles, it isn't fixed and is has to be selected at the moment the referendum is created.

[n13]

This is really cool - spec sounds perfect

[IanMendozaJaimes]

Closing because the pull request #393 was merged and that pr already contained all the changes made here.