The current contracts for Governance seem to implement delegation at the token contract level (ERC20Votes / ERC721Votes), which means only one delegatee can be selected for all Governor contracts that rely on this token for votes.
But for some usecases, where multiple governor contracts rely on the same token contract for votes, it would make sense to have one specific delegatee per governor contract.
Which means a second delegation system would likely be implemented at the governor contract level, in addition of the one in the token contract.
I would like to know if :
- it's a bad idea ?
- it's already been discussed/implemented by OpenZeppelin or other projects ?
- it should be implemented in a different way ?
Thank you for your help.
It's not conceptually a bad idea but there are technical challenges in implementing delegation outside the token, related to the fact that you have to avoid iterating over an unbounded number of delegators.
There are workarounds to make it bounded, but my guess is that will impose an overhead that may make a large number of delegations impractical.
Thank you for your reply.
I'm not sure to understand what would be unbounded if :
- token supply is limited
- one delegatee per token, on token contract side
- one delegatee per (delegated or not) token, on governor contract side
Am I missing something ?
Yes it's true that it is technically bounded by the token supply. But in practice this is still no good if the bound is something like 100,000,000¹⁸. It's "unbounded" in the sense that the bound is very large, because block gas is limited.
Additionally, the number of iterations needed will be attacker-controlled because an attacker can generate many delegates and increase the gas needed to vote.