Escrito por Pablo Gómez
Founder & CEO de Metlabs · Revisado el 11 de octubre de 2026
Un token de gobernanza añade derechos de voto a un token fungible. La extensión ERC20Votes incorpora un sistema de checkpoints que registra el histórico de poder de voto de cada cuenta por timepoint, lo que permite consultar getPastVotes en el snapshot de una propuesta. Un detalle clave: el poder de voto no es el balance directo, solo cuenta lo delegado. Un titular debe delegar, aunque sea a sí mismo, para activar su voto, lo que evita el doble conteo. El estándar ERC-6372 fija si el reloj usado es número de bloque o timestamp.
Distribuye el control y alinea incentivos. Quien soporta el riesgo del protocolo decide sobre los parámetros que afectan a su valor, sin necesidad de permiso. El snapshot por timepoint congela el poder de voto, de modo que las transferencias posteriores no alteran el resultado de esa propuesta. Muchos diseños usan además el token como incentivo de participación.
La extensión ERC20Votes de OpenZeppelin deriva del token COMP de Compound, pionero del patrón. ERC-5805, sobre votación con delegación, y ERC-6372, sobre el reloj del contrato, son los estándares que codifican delegación, checkpoints y reloj. Ejemplos reales son COMP, UNI de Uniswap, ENS, AAVE y MKR de MakerDAO. En la Unión Europea, conviene analizar caso por caso si un token de gobernanza queda fuera del perímetro de MiCA o si sus características lo aproximan a otra categoría regulada.
También conocido como
- Governance token
- Token de voto





