Voting Power DAO

[michaeljklein]

Clarification and motivation

The instructions VOTING_POWER and TOTAL_VOTING_POWER allow us to query the individual, total amount of rolls staked by bakers, respectively.

As with the BYO token DAO (https://github.com/tqtezos/baseDAO/issues/170), the (un)freeze entrypoints can be modified to consider the amount staked to be the amount of governance tokens held. In other words, a user with VOTING_POWER = N is considered to hold N governance tokens.

Acceptance criteria

Note: proposal and voting cycles must be aligned with the actual on-chain baking cycles. This allows the results of VOTING_POWER and TOTAL_VOTING_POWER to be cached until the next voting/proposing cycle.

Changes to BaseDAO

• The quorum becomes a fixed ratio or percentage of TOTAL_VOTING_POWER
• The duration of proposing and voting cycles are exact multiples of baking cycles (and must fit within 7 cycles)
• The proposal and voting cycles must also be synchronized with the baking cycles, since the VOTING_POWER can change at the end of a baking cycle
• There is no ledger of unfrozen governance tokens
• Regarding frozen tokens:
  • Users are only allowed to freeze exactly their VOTING_POWER number of tokens
  • This operation (freezing) must do nothing or fail if it’s called more than once before the end of the proposal cycle
  • All frozen tokens are invalidated at the end of the proposal cycle and must be re-frozen (triggering additional calls to VOTING_POWER, etc)

[sras]

@michaeljklein We have some queries regarding the requirements.

The proposal and voting cycles must also be synchronized with the baking cycles.

Since Michelson does not provide instructions to query the cycle or cycle position, it appears that we have to use the level instruction along with network constants, such as cycle length, to compute/detect cycle transitions.

Since these constants can change between protocols, it also seems that we need some way for the admin to set these constants in storage.

Does this make sense?

[michaeljklein]

@sras This contract shouldn't have an admin once it's actively accepting proposals: any required constant updates should be performed through proposals.

[sras]

Some updates to this issue based on past discussion.

1. Where the description says, "The duration of proposing and voting cycles are exact multiples of baking cycles (and must fit within 7 cycles)", it should fit in 5 cycles instead of 7

2. The limitation that only frozen tokens that were frozen in previous periods can be used to propose or vote is lifted.

[pasqu4le]

I wanted to mention that there are changes in jakarta that might affect this issue:

The VOTING_POWER of a contract is no longer rounded to rolls. It is now instead the full staking power of the delegate, currently expressed in mutez. Though, developers should not rely on VOTING_POWER to query the staking power of a contract in mutez: the value returned by VOTING_POWER is still of type` nat and it should only be considered relative to TOTAL_VOTING_POWER. (MR !4265)