Escrito por Pablo Gómez
Founder & CEO de Metlabs · Revisado el 11 de octubre de 2026
El estándar define dos funciones requeridas. clock() devuelve el timepoint actual según el modo del contrato, debe ser una función no decreciente de la cadena y retorna un uint48, suficiente para valores realistas y apto para packing de almacenamiento. CLOCK_MODE() devuelve una cadena legible por máquina en formato query-string que describe el reloj: mode=blocknumber&from=default para número de bloque por defecto, mode=blocknumber&from=<CAIP-2-ID> para otra cadena, o mode=timestamp para tiempo real.
El número de bloque es un reloj poco estable, porque el tiempo entre bloques varía y difiere entre redes L2. ERC-6372 nació dentro de la discusión de ERC-5805 (votación con delegación) y se separó como estándar propio; ERC-5805 declara dependencia de él. La regla de compatibilidad es clave: un contrato de gobernanza que no implemente ERC-6372 debe operar como si CLOCK_MODE devolviera número de bloque por defecto. Implementarlo es lo que permite migrar de número de bloque a timestamp de forma explícita y autodescrita.
ERC-6372 se creó el 25 de enero de 2023, sigue en proceso de estandarización en Ethereum, todavía no Final, y lo firman Hadrien Croubois y Francisco Giordano. El voto basado en timestamp que formaliza, junto a ERC-5805, llegó a OpenZeppelin Contracts v4.9: los módulos Governor, ERC20Votes y ERC721Votes implementan clock() y CLOCK_MODE(). Existe además una petición abierta para añadir la interfaz a VestingWallet de OpenZeppelin, señal de su adopción más allá de la gobernanza pura.
Fuentes
También conocido como
- ERC6372
- Contract clock





