In this case the voter can “trick” the snapshot into thinking they hold the tokens over a longer period of time than they actually do.
I think this sentence is useful in revealing the underlying design goal here. It indicates that the length of time that the user holds the tokens is relevant to whether or not their vote should count.
In particular, it suggests that user's vote should count only if they have "skin in the game" -- as measured both by how many tokens they have, and how long they hold them.
I don't think that simply preventing flash loans addresses this concern. For example, a whale can buy a lot of tokens, vote, and then sell the tokens a few blocks later. Such a whale would not really have much "skin in the game" either -- barely more than the flash-borrower did.
One solution to this "skin in the game" problem that I've seen proposed many times over the years is to weight votes by "token days destroyed". In other words, the votes are weighted by a function that considers both how many tokens the user holds, as well as how long they've been holding them.
However, this approach is deeply flawed and provides only a false sense of "skin in the game", because it is purely backwards-looking. It measures only how much skin in the game the user had before the time that is relevant to the current vote. It does not encourage longterm thinking on the part of the voters (as the proponents of this method often suggest), because the voters can sell immediately after the vote.
An approach that I think is promising is this one:
When the user votes, they say how long they are willing to lock up their tokens for the vote in question (this is their locktime
). Then the user's vote is weighted as non-decreasing function the number of tokens they hold and their chosen locktime
.
In this way the weight of the vote is a direct measure of the amount of "skin in the game" the voter has.
Note that this trivially solves the flash-loan problem, because flash-loan voters have a locktime
of 0
, and so their vote will have a weight of 0
no matter how many tokens they hold.
I want to make clear that I have NOT done a formal analysis of this approach. But it is a direction that seems promising to me.
EDIT/UPDATE:: I'm sure this has already been mentioned, but I want to repeat it again here: This type of timelock (that is used for incentive alignment) can be bypassed via binding agreements. In the blockchain setting, this kind of binding agreement can be coordinated via smart contract. See Bypassing Smart Contract Timelocks for more info.