Como verificar vesting de tokens com evidências do contrato

Uma divulgação de vesting e um contrato implantado são duas evidências distintas. Para considerar um cronograma verificado, comparo os termos publicados com o código e o estado que controlam as liberações e classifico como desconhecido tudo o que não consigo observar. Essa verificação pode estabelecer se a mecânica declarada corresponde às evidências acessíveis. Ela não pode demonstrar que uma liberação causou uma variação de preço ou alterou a retenção de usuários. Essas são perguntas diferentes, que exigem outros dados e desenhos de pesquisa.

Encontre a divulgação e defina o que ela afirma

Salve a fonte exata em que o projeto declara seus termos de vesting. Prefira uma página atual de tokenomics, uma proposta de governança, um documento jurídico ou um documento do projeto com data, em vez de uma republicação ou resumo da comunidade. Registre a URL, a data de acesso, a versão ou data de publicação e o texto que descreve a alocação. Identifique o que o cronograma abrange: um destinatário nomeado, uma classe de destinatários, uma reserva do tesouro, uma alocação de investidores ou todo o fornecimento em circulação. Uma porcentagem sem denominador não é uma afirmação completa.

Converta a divulgação em campos que possam ser comparados: beneficiário ou classe de destinatários, ativo, alocação total, condição inicial, cliff, duração do vesting, frequência de liberação, possibilidade de revogação e quaisquer controles de transferência ou governança. Mantenha o texto original ao lado do campo normalizado. Se o projeto disser que “os tokens da equipe entram em vesting ao longo de três anos”, não converta isso silenciosamente em liberações mensais. A frase não especifica uma data de início, cliff, frequência ou se a alocação é mantida por uma carteira ou por várias.

Separe um cronograma planejado do comportamento observado. Um calendário publicado pode descrever uma alocação pretendida. Ele não prova que os tokens descritos estão em um contrato específico nem que nenhum caminho administrativo possa alterar a liberação. Suas anotações devem identificar a camada de evidência de cada afirmação: divulgação, código-fonte verificado, estado do contrato, evento de transação ou inferência do analista.

Localize e inspecione o contrato relevante

Encontre o endereço do contrato em uma fonte oficial do projeto, em um registro de implantação ou em um registro de governança. Confirme a rede e o endereço do token. Em seguida, verifique o código-fonte verificado no explorador e compare o compilador e o contexto do construtor com o endereço implantado. Um nome de contrato correspondente não é suficiente. Os projetos podem implantar contratos modificados, proxies ou sistemas personalizados de vesting que compartilham nomes conhecidos.

A OpenZeppelin documenta o `VestingWallet` como um contrato próprio que pode liberar ativos nativos ou tokens ERC-20 a um beneficiário de acordo com um cronograma personalizável. A documentação também observa que ativos enviados depois do início do vesting podem estar parcialmente liberáveis de imediato e que a propriedade pode ser transferida. Essas mecânicas são importantes ao avaliar uma implantação construída com base nessa primitiva. Elas não provam que um projeto nomeado usa um contrato OpenZeppelin sem modificações. Leia o código implantado e a configuração do endereço que está verificando.

Para um proxy, identifique o proxy e a implementação, o administrador ou autoridade de atualização e quaisquer mudanças de implementação aplicáveis ao período descrito. Para um contrato personalizado, rastreie as funções que calculam os valores liberáveis e autorizam a liberação. Se não conseguir verificar o código-fonte ou resolver a implementação, não afirme o cronograma exato. Classifique o comportamento do contrato como desconhecido ou parcialmente verificado.

Compare as regras de liberação com o estado observável

Compare um campo por vez. O contrato identifica o mesmo beneficiário? O ativo é o mesmo token? O horário inicial configurado corresponde ao início declarado? As regras de duração e cliff estão alinhadas? O destinatário ou proprietário pode alterar o cronograma? Existe um mecanismo de pausa, revogação, administração ou atualização? Uma resposta positiva para um campo não verifica o cronograma inteiro.

Use leituras na blockchain e eventos para confirmar o que aconteceu. O valor atualmente liberável de um contrato é uma observação de estado em um bloco ou horário específico. Um evento de transferência é evidência de uma transferência, mas pode não explicar a alocação total do projeto. Os rótulos de carteiras nos exploradores são indícios de atribuição, a menos que o projeto ou outra fonte forte os confirme. Se várias carteiras receberem tokens, não presuma que pertencem à mesma classe de destinatários divulgada sem evidências.

Registre cada comparação como sustentada, contradita, parcialmente observável ou desconhecida. Inclua o número do bloco ou o horário da consulta para leituras de estado. Preserve os links das transações brutas e o método usado para identificar o contrato. Se um indexador ou explorador estiver indisponível, não substitua o resultado por um palpite. A documentação para desenvolvedores da Ethereum explica contratos inteligentes como programas em uma blockchain, mas uma explicação geral não pode verificar a implantação ou o estado de um contrato específico.

Relate lacunas sem inferir intenção

Uma divergência é uma descoberta sobre as evidências, não uma prova de má conduta. O documento publicado pode estar desatualizado, a implantação pode ter mudado ou a atribuição da carteira pode estar incompleta. Declare o conflito exato e os limites da verificação. Peça ao projeto que esclareça a fonte de verdade quando um termo central não puder ser reconciliado. Não escreva que os tokens estão “desbloqueados” apenas porque uma data passou; confirme que o contrato os torna liberáveis e diferencie isso de uma transferência efetiva.

Mantenha a análise de vesting separada da análise de retenção. Para testar se o comportamento dos usuários mudou em torno de uma liberação, defina a coorte, a janela de observação, o resultado e os fatores de confusão. Um cronograma sozinho não pode estabelecer churn de usuários, venda de tokens ou impacto no preço. Meus guias relacionados sobre [design de cronogramas de vesting](guia de cronogramas de vesting de tokens) e [retenção após incentivos](guia de retenção após incentivos) abordam essas perguntas separadas.

O relatório final deve permitir que outro analista reproduza a conclusão. Inclua o trecho da divulgação, o endereço do contrato, a rede, o estado da verificação do código-fonte, os campos comparados, o bloco do estado, os links dos eventos, as incógnitas e a data da verificação. Se as evidências estiverem incompletas, o resultado honesto é uma verificação parcial, não uma aprovação binária.

A OpenZeppelin descreve a implementação padrão de `vestedAmount` como linear, embora também permita personalizar a fórmula do cronograma. A curva abaixo normaliza o tempo e a parcela adquirida para facilitar a leitura desse padrão. Ela não contém endereço de projeto, tamanho de alocação ou dados reais de liberação. Um contrato implantado pode usar um cronograma personalizado, uma extensão do cliff, um proxy ou outro comportamento. Inspecione o código e a configuração específicos antes de usar esse formato para descrever um projeto.

Registro de evidências

Perguntas frequentes

Uma divulgação de vesting pode provar que os tokens foram liberados?

Não. Uma divulgação declara termos ou intenção. Para confirmar uma liberação efetiva, inspecione o estado e as transações do contrato relevante, verificando se o endereço e a atribuição do destinatário estão corretos.

O código-fonte verificado prova que o projeto seguiu seu cronograma publicado?

Não. O código-fonte verificado ajuda a inspecionar o código em um endereço. Ainda é necessário identificar a implantação correta, sua configuração, o estado atual, qualquer implementação de proxy e o escopo da divulgação.

Um cronograma de vesting pode explicar o preço do token ou a retenção de usuários?

Não por si só. Afirmações sobre preço e retenção exigem dados separados, janelas definidas e um desenho que considere outras causas. Um cronograma não estabelece causalidade nem resultado.

E se o beneficiário ou a regra de liberação não estiver claro?

Registre esse campo como desconhecido ou parcialmente observável. Não infira uma correspondência apenas com base em um rótulo de carteira, uma declaração do projeto ou um nome familiar de contrato.

Referências

1. https://docs.openzeppelin.com/contracts/5.x/api/finance, acessado em 2026-11-09.
2. https://ethereum.org/developers/docs/smart-contracts/, acessado em 2026-11-09.