Hi, I am trying to understand this statement from the ERC20Votes docs:
By default, token balance does not account for voting power. This makes transfers cheaper. The downside is that it requires users to delegate to themselves in order to activate checkpoints and have their voting power tracked.
This suggests that even though an address has the proper tokens for voting (received through any means), the address cannot perform a vote unless it calls delegate on its own address (internally calls _moveVotingPower).
However, from the _afterTokenTransfer internal function, it seems that an address can gain voting power if the tokens were transferred from another address with voting power, as it calls _moveVotingPower as well? Does this mean this address does not strictly need to call delegate on its own address to gain voting power?
I may be missing something, any clarification on this would be helpful thanks.
Hi @junhuang-ho. The code that you point out in _afterTokenTransfer takes care of rearranging voting power according to token transfers. But if the receiver hasn't assigned a delegate, that voting power doesn't get assigned to anyone.
Suppose account a has self-delegated, and it transfers n tokens to account b which has not set a delegate. Eventually the function _afterTokenTransfer(a, b, n) gets called, which as seen in the function body would then invoke _moveVotingPower(delegates(a), delegates(b), n).
delegates(x) returns the delegate for account x. So we have
delegates(a) = a-
delegates(b) = 0! (the zero address)
So the previous function call reduces to _moveVotingPower(a, 0, n). n units of voting power will be removed from a, but will not be assigned to anyone.
Later, b can set a delegate and its balance (which would include n) would become voting power.
Ok, I guess it makes sense that if a person has not registered to vote then them transferring an amount to another person should not make that person receiving suddenly gain voting power.
Thanks