search

near-daos / sputnik-dao-contract

Smart contracts for https://app.astrodao.com
https://astrodao.com/
MIT License
107 stars 79 forks source link

Consider updating all votes from a user after an un/delegation #53

Open swfsql opened 2 years ago

swfsql commented 2 years ago

Even though this issue is known and that the staking contract prevents this issue from happening, I believe it's good to have an issue for it.

Currently the stacked-token weighted votes only consider that user's weight/balance at the time when the users makes the action of voting itself, which is a potential threat to the voting system if some users collude in concentrating delegations/tokens for one user voting (to then proceed to re-delegate to another user to vote, and so on), since the users' undelegation doesn't affects their previous votes.

It should be noted that the staking implementation prevents this problem by defining a next_action_timestamp state which gets placed when a user undelegates, preventing them from delegating it again (or withdrawing the token) during the time in which any proposal will be alive.

So I believe that, ideally, the DAO wouldn't depend on that kind of behavior from the staking contract, because a bad change on the duration of the proposals on the DAO or on the period in which the users can't delegate/withdraw on the staking contract could enable this threat to the voting system.

Although a change in this would probably require indexing of votes and a lot of increase in gas usage for the overall system (each vote, each un/delegation), perhaps it's good to have an issue for this.

TrevorJTClarke commented 2 years ago

@swfsql I like the thinking here. It does seem like more research is required on how to best address this issue as the governance models supported in sputnik evolve. Marked for further discussion.