
Um lançamento está pronto para distribuição somente quando a equipe consegue explicar quem pode participar, como as alocações funcionam, quais operações de liquidez são necessárias e quais contratos controlam cada etapa. Trato cada item como uma dependência documentada com um responsável. Um campo vazio ou sem suporte permanece desconhecido. Esta lista de verificação é um método de evidências, não uma previsão de demanda ou desempenho do token. A documentação do Uniswap v4 é um exemplo específico de arquitetura de pool, não uma especificação universal de lançamento.
Defina o caminho do participante e as regras de elegibilidade
Escreva a jornada do participante desde a primeira descoberta até uma ação de distribuição concluída. Identifique onde a pessoa toma conhecimento do lançamento, qual carteira ou conta precisa, qual rede deve usar, quais ativos necessita e o que acontece se não for elegível. Cite os termos oficiais para listas de permissão, restrições geográficas ou de identidade, janelas de reivindicação, limites e caminhos de recurso. Se o lançamento não tiver uma barreira de elegibilidade, documente isso também.
Teste a jornada usando uma carteira nova ou um ambiente de teste. Verifique a rede necessária, as aprovações de tokens, a sequência de transações, o ativo usado para taxas, as mensagens de erro e o caminho de suporte. Uma página inicial que diz “conecte a carteira” não documenta todas as dependências. Um contrato que aceita uma transação não prova que as instruções públicas estão completas. Compare o texto voltado ao usuário com a mecânica implantada ou configurada e registre qualquer diferença antes da abertura da distribuição.
Atribua um responsável a cada verificação operacional. Produto pode ser responsável pela jornada, jurídico pela linguagem de elegibilidade, engenharia pela configuração dos contratos e suporte pela escalada de incidentes. O responsável é a pessoa que pode resolver uma falha, não simplesmente quem escreveu a lista de verificação.

Verifique a mecânica e as restrições de alocação
Documente como a alocação é calculada e onde está a regra de autoridade. Para uma alocação fixa, registre o total, as unidades, as categorias de destinatários, o período de reivindicação e o tratamento dos valores não reivindicados. Para uma alocação variável ou com excesso de demanda, explique a fórmula, o limite, a ordem, a aleatorização ou a regra proporcional. Cite um contrato, uma configuração assinada, uma decisão de governança ou os termos oficiais do lançamento. Não apresente um rótulo da interface como prova de uma regra on-chain.
Verifique se a implementação pode mudar após o lançamento. Analise funções administrativas, caminhos de atualização, funções de pausa, atualizações da lista de permissão e controles de emergência. Esses controles podem ser recursos legítimos de segurança. Sua existência deve estar visível no registro de prontidão porque afeta quem pode alterar a mecânica do lançamento e em quais condições. Se a verificação da fonte não estiver disponível, registre a limitação e não afirme que o comportamento foi confirmado.
Use uma matriz campo a campo em vez de uma única caixa de seleção “alocação verificada”. Inclua a afirmação, a URL ou o endereço da evidência, o valor observado, o horário da verificação, o responsável e o status. Marque um campo como “não aplicável” somente com uma justificativa. Uma fonte ausente é desconhecida, não zero. Uma divergência entre a interface e o contrato é um problema do lançamento a ser resolvido, não um detalhe de redação.
Rastreie a liquidez e as dependências dos contratos
Descreva o caminho da liquidez em termos operacionais. Qual pool ou ambiente é criado? Quais ativos e parâmetros são usados? Quem fornece a liquidez inicial? Quem pode alterar taxas ou parâmetros? Qual transação precisa ser concluída antes que os usuários possam negociar? Essas respostas variam conforme o protocolo e a implantação. Use a documentação oficial do protocolo relevante e os endereços ou a configuração reais do lançamento analisado.
A documentação do Uniswap v4 descreve um `PoolManager` singleton que gerencia o estado e as operações dos pools, com hooks que podem ampliar o comportamento. Essa arquitetura é específica do Uniswap v4. Ela não estabelece os requisitos de outra DEX, de uma ponte, de uma plataforma de lançamento ou de um mercado personalizado. Para uma integração v4, analise o PoolManager implantado, a chave do pool, os hooks, as configurações de taxas e o caminho de integração. A visão geral do protocolo direciona desenvolvedores a conceitos, guias, repositórios, auditorias e referências de implantação. Use essas fontes para rastrear a implementação, sem generalizar a partir da visão geral.
Execute a sequência operacional completa em um ambiente controlado. Confirme que o pool ou a distribuição foi inicializado conforme esperado, que as funções e os saldos correspondem ao plano aprovado e que o monitoramento está ativo. Documente os critérios de reversão ou pausa e a pessoa autorizada a utilizá-los. Não sugira que a profundidade da liquidez garante um preço estável ou um lançamento bem-sucedido.
Use uma matriz de prontidão e mantenha a incerteza visível
Antes de abrir a distribuição, revise quatro áreas de evidência: acesso dos participantes, alocação, liquidez e operações. Para cada uma, registre o requisito, a fonte primária, o resultado atual, o responsável e a questão não resolvida. A matriz apoia a decisão. Ela não transforma evidências incertas em uma pontuação nem garante um resultado.
Uma revisão útil de prontidão pergunta se um novo participante consegue seguir o caminho informado, se os termos de alocação correspondem à implementação, se a sequência de liquidez tem um operador identificado e se o monitoramento e os controles de incidentes estão ativos. Se alguma resposta for desconhecida, decida se o lançamento pode prosseguir com essa incerteza, se a divulgação precisa mudar ou se a dependência deve ser resolvida primeiro. Registre a decisão e seu aprovador.
Falhas comuns incluem usar uma lista genérica para uma mecânica específica de protocolo, depender de um endereço de implantação desatualizado, ignorar configurações privilegiadas e tratar uma transação de teste bem-sucedida como prova de que todos os usuários podem participar. Mantenha os links das evidências junto à lista de verificação e repita os testes após qualquer alteração no contrato, na interface, na elegibilidade ou na liquidez. Para comparações mais amplas de modelos de lançamento, consulte meu guia [estruturas de lançamento DeFi](estruturas de lançamento DeFi) e a [lista de verificação de GTM DeFi](lista de verificação de GTM DeFi).
O gráfico conta as listas de etapas da página do PoolManager do Uniswap v4: cinco para uma troca e sete para uma modificação de liquidez. As contagens são úteis apenas como lembrete de que uma operação tem várias verificações e hooks. Elas não descrevem todos os hooks implantados, integrações ou lançamentos DeFi. Para outro protocolo, reconstrua esta lista de evidências a partir da documentação e da configuração implantada próprias.

Registro de evidências
| Área de evidência | Registro | Regra de decisão |
|---|---|---|
| Fonte | Página oficial, endereço ou configuração | Mantenha a URL e a data da verificação |
| Comportamento observado | Resposta, estado, função ou evento | Separe observação de divulgação |
| Incerteza | Campo desconhecido ou parcial | Não preencha lacunas por inferência |
| Responsável | Pessoa responsável pela resolução | Verifique novamente após qualquer mudança material |
Perguntas frequentes
Um pool de liquidez garante um lançamento de token bem-sucedido?
Não. Um pool é um mecanismo de mercado. Ele não garante demanda, acesso justo, liquidez adequada ou preço estável.
O que deve ser verificado antes da abertura da distribuição de tokens?
Verifique o acesso dos participantes, as regras de alocação, as operações de liquidez, a configuração dos contratos, o monitoramento e os responsáveis. Use fontes primárias e marque os campos não resolvidos como desconhecidos.
Uma lista de verificação do Uniswap v4 pode ser usada em todo lançamento DeFi?
Não. A documentação do Uniswap v4 descreve sua própria arquitetura. Outros protocolos e implantações têm contratos e requisitos operacionais diferentes.
E se a interface e o contrato mostrarem termos de alocação diferentes?
Pause a decisão de prontidão e resolva a divergência com o responsável. Registre as evidências exatas e atualize os termos voltados aos participantes antes de confiar em qualquer uma das versões.
Referências
- https://docs.uniswap.org/contracts/v4/concepts/PoolManager, consultado em 2026-11-09.
- https://docs.uniswap.org/contracts/v4/overview, consultado em 2026-11-09.
Tome a próxima decisão com base em evidências.
Analiso sistemas de crescimento Web3 em produto, distribuição e mensuração.
Conheça a auditoria de crescimento Web3