Comment on page
Add a Governor to an existing token
Add a DAO to an existing ERC20 token or NFT
If a token may someday be useful for running an onchain DAO, deploy it with a voting interface for future Governor compatibility! If the token is already deployed and it cannot be upgraded, the best workaround is to deploy a wrapper token contract that adds the voting interface to an existing token.
A token wrapper does come with tradeoffs. Users will have to wrap their tokens to vote, and then unwrap them to use them in places that expect the unwrapped version. They may also be confused about where their token went after wrapping if their wallet doesn’t know about the wrapped version.
One thing to note is that setting up voting already requires setup: token holders have to delegate their votes – even to themselves – before voting. The wrapping step could be combined with delegation to keep the process simpler for tokenholders.
The `ERC20Votes`/`ERC721Votes` logic on the token contract is responsible for voting power bookkeeping that can’t be done on another contract. That bookkeeping involves several things: updating voting power when there’s a delegation or transfer, taking a snapshot of the voting power at the start of each proposal, and emitting event logs for indexers whenever there’s a change in delegation or voting power.
Each `transfer()` and `delegate()` call updates the counts of voting power, so that it’s computationally cheap to save a voting power snapshot for a proposal. Governor needs a voting power snapshot to prevent double-voting. It would be too computationally expensive for an external contract like Governor to keep track of which tokens have already voted without a snapshot, because an attacker could move around tokens to vote multiple times with the same token.