Written by Pablo Gómez
Founder & CEO at Metlabs · Reviewed on October 11, 2026
A governance token adds voting rights to a fungible token. The ERC20Votes extension introduces a checkpoint system that records each account's voting-power history by timepoint, allowing getPastVotes lookups at a proposal's snapshot. A key detail: voting power is not the raw balance, only what has been delegated counts. A holder must delegate, even to themselves, to activate their vote, which prevents double counting. The ERC-6372 standard sets whether the clock used is block number or timestamp.
It distributes control and aligns incentives. Those who bear the protocol's risk decide on the parameters that affect its value, permissionlessly. The per-timepoint snapshot freezes voting power, so transfers made afterward do not alter that proposal's outcome. Many designs also use the token as a participation incentive.
OpenZeppelin's ERC20Votes extension derives from Compound's COMP token, which pioneered the pattern. ERC-5805, on voting with delegation, and ERC-6372, on the contract clock, are the standards that codify delegation, checkpoints and the clock. Real examples include COMP, Uniswap's UNI, ENS, AAVE and MakerDAO's MKR. In the European Union, it is worth analyzing case by case whether a governance token sits outside the MiCA perimeter or whether its features bring it closer to another regulated category.
Also known as
- Governance token





