Una divulgación sobre vesting y un contrato desplegado son dos piezas de evidencia independientes. Para considerar verificado un calendario, comparo las condiciones publicadas con el código y el estado que rigen las liberaciones, y marco como desconocido todo lo que no puedo observar. Esta comprobación puede establecer si la mecánica declarada coincide con la evidencia accesible. No puede demostrar que un desbloqueo provocó un movimiento del precio o cambió la retención de usuarios. Esas son preguntas distintas que requieren datos y diseños de investigación diferentes.
Encuentra la divulgación y define lo que afirma
Guarda la fuente exacta donde el proyecto presenta sus condiciones de vesting. Da preferencia a una página actual de tokenómica, una propuesta de gobernanza, un registro legal o un documento del proyecto con fecha, por encima de una republicación o un resumen de la comunidad. Registra la URL, la fecha de consulta, la versión o fecha de publicación y el texto que describe la asignación. Identifica qué cubre el calendario: un destinatario concreto, una clase de destinatarios, un fondo de tesorería, una asignación para inversores o todo el suministro circulante. Un porcentaje sin denominador no es una afirmación completa.
Convierte la divulgación en campos que puedas comparar: beneficiario o clase de destinatarios, activo, asignación total, condición inicial, cliff, duración del vesting, frecuencia de liberación, posibilidad de revocación y cualquier control de transferencia o gobernanza. Conserva el texto original junto al campo normalizado. Si el proyecto dice «los tokens del equipo se liberan durante tres años», no lo conviertas silenciosamente en liberaciones mensuales. La frase no especifica una fecha de inicio, un cliff, una frecuencia ni si la asignación está en una sola cartera o en varias.
Separa el calendario previsto del comportamiento observado. Un calendario publicado puede describir una asignación prevista. No demuestra que los tokens descritos estén en un contrato específico ni que ninguna vía administrativa pueda cambiar la liberación. Tus notas deben identificar la capa de evidencia de cada afirmación: divulgación, código fuente verificado, estado del contrato, evento de transacción o inferencia del analista.
Localiza e inspecciona el contrato pertinente
Encuentra la dirección del contrato en una fuente oficial del proyecto, un registro de despliegues o un registro de gobernanza. Confirma la red y la dirección del token. Después, revisa el código fuente verificado del explorador y compara su compilador y el contexto del constructor con la dirección desplegada. Que coincida el nombre del contrato no basta. Los proyectos pueden desplegar contratos modificados, proxies o sistemas de vesting personalizados que comparten etiquetas conocidas.
OpenZeppelin documenta VestingWallet como un contrato con control de propiedad que puede liberar activos nativos o tokens ERC-20 a un beneficiario conforme a un calendario personalizable. Su documentación también señala que los activos enviados después del inicio del vesting pueden ser parcialmente liberables de inmediato y que la propiedad puede transferirse. Estas mecánicas importan al evaluar un despliegue construido a partir de ese componente. No demuestran que un proyecto concreto use un contrato de OpenZeppelin sin modificaciones. Lee el código desplegado y la configuración de la dirección que estás comprobando.
En un proxy, identifica el proxy y la implementación, la autoridad administrativa o de actualización y cualquier cambio de implementación aplicable al periodo que describes. En un contrato personalizado, sigue las funciones que calculan los importes liberables y autorizan la liberación. Si no puedes verificar el código fuente o resolver la implementación, no afirmes el calendario exacto. Marca el comportamiento del contrato como desconocido o parcialmente verificado.
Compara las reglas de liberación con el estado observable
Compara un campo cada vez. ¿El contrato identifica al mismo beneficiario? ¿El activo es el mismo token? ¿La hora de inicio configurada coincide con la indicada en la divulgación? ¿Coinciden las reglas de duración y cliff? ¿Puede el destinatario o propietario cambiar el calendario? ¿Existe un mecanismo de pausa, revocación, administración o actualización? Una respuesta positiva en un campo no verifica todo el calendario.
Usa lecturas y eventos en cadena para confirmar lo ocurrido. El importe actualmente liberable de un contrato es una observación del estado en un bloque o momento concreto. Un evento de transferencia demuestra que hubo una transferencia, pero puede no explicar la asignación completa del proyecto. Las etiquetas de carteras en los exploradores son indicios de atribución, salvo que el proyecto u otra fuente sólida las confirme. Si varias carteras reciben tokens, no supongas que pertenecen a la misma clase de destinatarios divulgada sin evidencia.
Registra cada comparación como respaldada, contradicha, parcialmente observable o desconocida. Incluye el número de bloque o la hora de consulta para las lecturas del estado. Conserva los enlaces de las transacciones originales y el método utilizado para identificar el contrato. Si un indexador o explorador no está disponible, no sustituyas el resultado por una suposición. La documentación para desarrolladores de Ethereum explica los contratos inteligentes como programas en una cadena de bloques, pero una explicación general no puede verificar el despliegue o el estado de un contrato concreto.
Informa de las brechas sin inferir intenciones
Una discrepancia es un hallazgo sobre la evidencia, no una prueba de conducta indebida. El documento publicado puede estar desactualizado, el despliegue puede haber cambiado o la atribución de la cartera puede estar incompleta. Expón el conflicto exacto y los límites de la comprobación. Pide al proyecto que aclare cuál es la fuente de verdad cuando un término central no pueda conciliarse. No escribas que los tokens están «desbloqueados» solo porque haya pasado una fecha; confirma que el contrato permite liberarlos y distingue eso de una transferencia efectiva.
Mantén el análisis del vesting separado del análisis de retención. Para comprobar si el comportamiento de los usuarios cambió alrededor de un desbloqueo, define la cohorte, el periodo de observación, el resultado y los factores de confusión. Un calendario por sí solo no puede establecer abandono de usuarios, venta de tokens ni impacto en el precio. Mis guías relacionadas sobre el [diseño de calendarios de vesting](guía de calendarios de vesting de tokens) y la [retención tras incentivos](guía de retención tras incentivos) cubren esas preguntas por separado.
El informe debe permitir que otro analista reproduzca la conclusión. Incluye el extracto de la divulgación, la dirección del contrato, la red, el estado de verificación de la fuente, los campos comparados, el bloque del estado, los enlaces de eventos, las incógnitas y la fecha de la comprobación. Si la evidencia está incompleta, el resultado honesto es una verificación parcial, no una aprobación binaria.
OpenZeppelin describe como lineal la implementación predeterminada de vestedAmount, aunque también permite personalizar la fórmula del calendario. La curva siguiente normaliza el tiempo y la proporción adquirida para facilitar la lectura de ese comportamiento predeterminado. No contiene una dirección de proyecto, el tamaño de una asignación ni datos reales de liberación. Un contrato desplegado puede usar un calendario personalizado, una extensión del cliff, un proxy u otro comportamiento. Inspecciona el código y la configuración específicos antes de utilizar esta forma para describir un proyecto.
Registro de evidencia
| Área de evidencia | Registro | Regla de decisión |
|---|---|---|
| Fuente | Página oficial, dirección o configuración | Conserva la URL y la fecha de comprobación |
| Comportamiento observado | Respuesta, estado, función o evento | Separa la observación de la divulgación |
| Incertidumbre | Campo desconocido o parcial | No completes las brechas mediante inferencias |
| Responsable | Persona responsable de resolverlo | Vuelve a comprobarlo tras cualquier cambio material |
Preguntas frecuentes
¿Puede una divulgación de vesting demostrar que se liberaron tokens?
No. Una divulgación presenta condiciones o intención. Para confirmar una liberación efectiva, inspecciona el estado y las transacciones del contrato pertinente, verificando que la dirección y la atribución del destinatario sean correctas.
¿El código fuente verificado demuestra que el proyecto siguió su calendario publicado?
No. El código verificado ayuda a inspeccionar lo que hay en una dirección. Aún debes identificar el despliegue correcto, su configuración, el estado actual, cualquier implementación proxy y el alcance de la divulgación.
¿Puede un calendario de vesting explicar el precio del token o la retención de usuarios?
No por sí solo. Las afirmaciones sobre precio y retención necesitan datos separados, periodos definidos y un diseño que aborde otras causas. Un calendario no establece causalidad ni resultados.
¿Qué ocurre si el beneficiario o la regla de liberación no están claros?
Registra ese campo como desconocido o parcialmente observable. No infieras una coincidencia basándote únicamente en una etiqueta de cartera, una declaración del proyecto o un nombre de contrato conocido.
Referencias
- https://docs.openzeppelin.com/contracts/5.x/api/finance, consultado el 2026-11-09.
- https://ethereum.org/developers/docs/smart-contracts/, consultado el 2026-11-09.
Toma la próxima decisión a partir de la evidencia.
Analizo sistemas de crecimiento Web3 en producto, distribución y medición.
Explora la auditoría de crecimiento Web3