|
| 1 | +# Cosmos SDK Staked Balance Voting |
| 2 | + |
| 3 | +> **WARNING**: This contract is experimental and should not be used to govern |
| 4 | +> significant assets nor security-critical procedures. Due to the limitations of |
| 5 | +> the Cosmos SDK and CosmWasm, this voting module cannot provide the guarantees |
| 6 | +> needed by a fully secure DAO. More on this below. |
| 7 | +
|
| 8 | +A DAO DAO voting contract that uses Cosmos SDK staking for calculating voting |
| 9 | +power. This allows a DAO to mimic members' stake in the chain (and thus voting |
| 10 | +power in chain governance props). |
| 11 | + |
| 12 | +## Limitations |
| 13 | + |
| 14 | +Unfortunately, CosmWasm does not currently allow querying historically staked |
| 15 | +amounts, nor does it allow querying the total amount staked with the staking |
| 16 | +module. Thus, this module suffers from two primary limitations. |
| 17 | + |
| 18 | +### Voter's staked amount |
| 19 | + |
| 20 | +Voting power for a voter is always calculated based on the current amount staked |
| 21 | +(regardless of which block is requested in the query) since there is no |
| 22 | +historical info. Since proposal modules query and save this value when a voter |
| 23 | +casts a vote, the voting power used is frozen at the time of voting. |
| 24 | + |
| 25 | +If revoting is not allowed, a voter may be incentivized to wait for others to |
| 26 | +vote, acquire more voting power, and vote once the others cannot change their |
| 27 | +voting power. |
| 28 | + |
| 29 | +If revoting is allowed, voting power is updated when a voter changes their vote. |
| 30 | +This opens up the possibility for a voter to manipulate the perceived outcome |
| 31 | +while a proposal is still open, changing their voting power and revoting at the |
| 32 | +last minute to change the outcome. |
| 33 | + |
| 34 | +Cosmos SDK governance operates the same way—allowing for voting power to change |
| 35 | +throughout a proposal's voting duration—though it at least re-tallies votes when |
| 36 | +the proposal closes so that all voters have equal opportunity to acquire more |
| 37 | +voting power. |
| 38 | + |
| 39 | +### Total staked amount |
| 40 | + |
| 41 | +The contract cannot determine the total amount staked on its own and thus relies |
| 42 | +on the DAO to set and keep this value up-to-date. Essentially, it relies on |
| 43 | +governance to source this value, which introduces the potential for human error. |
| 44 | + |
| 45 | +If the total staked amount is ever set to _less_ than any voter's staked amount |
| 46 | +or the sum of all voter's staked amounts, proposal outcomes may erroneously pass |
| 47 | +or fail too early as this interferes with the passing threshold calculation. |
| 48 | + |
| 49 | +## Solutions |
| 50 | + |
| 51 | +There is no solution to the problem of freezing voter's staked amount at the |
| 52 | +time of a vote. This mechanic must be accepted by the DAO if it wishes to use |
| 53 | +this contract. |
| 54 | + |
| 55 | +For the total staked amount, the easiest solution is to set up a bot with a |
| 56 | +wallet that is entrusted with the task of updating the total staked amount on |
| 57 | +behalf of the DAO. The DAO needs to authz-grant the bot's wallet the ability to |
| 58 | +update the total staked amount, and the bot needs to periodically submit update |
| 59 | +transactions via the wallet it controls. |
0 commit comments