AIP 20: Protocol Configurations Weighted Voting

[agriimony]

• by VladislavW

Summary

Goal is to make the protocol configuration propositions to be voted and accepted in a more fair way. The proposal is to create an ACP (Airwap Configuration Proposal) voting system that will help to vote for changing of Smart Contracts configurations like SCALE, MAX, throttlingPercentage, throttlingDuration, throttlingBalance etc. in the same way as we vote for AIPs. A correct implementation should result in a fair voting considering each staker vote power and rise the turnout.

Also each configuration change should stay same for a minimum of 2 voting cycles before it can be changed again.

Specification

The ACP voting proposals may be added to the same page near all other AIPs on Activate Governance page "clickable link"

The vote mechanics should be the same as for AIP voting with one change: as those votes may be not structured in time and can be voted more often that usual AIPs the points scoring amount received for this voting should be reduced to 0.

Rationale

Protocol configuration changes are no less valuable as any other AIP and should be voted in the same mechanics as usual AIPs.

We can also attract new voters because according to the last SCALE and MAX rates change vote we had only 11 votes total, which is quite low turnout. Also 100k staker vote should not have the same weight as 10k staker vote like we saw in Discord during the “smiles voting”.

Problems

1. Low turnout
2. Unequal vote weight relative to the stake in the project

Credits

Thanks to BeDreamin83 for their contributions to this AIP

Copyright — All proposals are public domain via CC0.

[agriimony]

agrimony Feb 20

thats a good idea! however, if we are going to redesign the payout and staking systems, I suggest we wait till we fix the actual protocols in place before having the ACP system to tweak the parameters.

we could also do a regular monthly or quarterly vote on this system to define the parameters for the next month or quarter so that we regularly revise and refine the system Possible problems

Current voting system is based on yes/no. You will need to think about how to structure a vote around many different variables.

---

VladislavW Feb 20

Possible problems

Current voting system is based on yes/no. You will need to think about how to structure a vote around many different variables.

Just one vote = one parameter.

---

mptl Feb 20

In total it seems good have a voting system in place for changing reward parameters. As I already suggested in a discord channel we could introduce a prevoting phase before every scheduled vote where we can change parameters. The parameters should only be changed in a fixed range [-x, x] for every period. E.g. in future we set voting to be on the beginning of every month. The prevote could then be at the end of the previous month.

To change the scale which is currently at 9 everyone has 1 vote and he can vote to change the SCALE to either 8, 9 or 10.

For the MAX it could be in the range of [-5, 5] so there are votes for 45, 46, …, 55 if the current MAX sits at 50.

IMO the reward should be way less than the actual voting.

---

don Feb 20

I like this and think that we can achieve it with one-off Snapshot votes to signal configuration changes in a new Snapshot space e.g. config.airswap.eth 2.

The choices do not have to be yes or no, they can be alternative options. Because this is “meta” governance, in my opinion, we shouldn’t get caught up in rewards and should focus on getting thoughtful configuration changes up and carry on with AIP.

---

20 days later BeDreamin83 Mar 13

I like the idea, my only thought would be how are these new APCs raised? Because I imagine the main purpose will be adjusting the weighting for payout %s.

However as staking increases the rewards for everyone will decrease (assuming volume remains the same) so there will be more people rolling forward their claim points after each vote to save gas fees. How can they plan ahead if someone keeps calling for an APC each week.

There would also be nothing to stop the bigger stake holders from stating they want to change the payout to be weighted massively in their favour.

I’d like to see a little detail on the criteria required for how these APCs can be called. But it’s a good idea