Plano de teste manual na Sepolia

Esta página é uma lista de verificação executável manualmente, na rede de teste Sepolia, por uma pessoa equipada com uma carteira. Cada caso tem um número estável no formato T-01, que pode ser citado em um relatório.

Antes de começar. Este plano se refere à nova versão. O manifesto público do repositório descreve a implantação Sepolia em serviço, com taxas LP 100: este plano se aplica a ela. Um caso que não se aplica à versão testada é registrado como “fora do escopo da versão”, nunca como “falha”.

Os valores citados vêm do código da nova versão, em contracts/src/, e das decisões de design de 14 de setembro de 2026. Um comportamento que não pôde ser estabelecido está marcado como “a confirmar durante o teste”.

Como usar este plano

Cada seção apresenta seus casos em uma tabela de seis colunas. As duas últimas são preenchidas durante os testes de aceitação.

Uma transação recusada conforme um caso de recusa é um sucesso. Um hash significa apenas que a transação foi enviada: somente o recibo informa o sucesso.

Alguns casos não passam pela interface. Em suas fontes atuais, o dapp lê a ABI da versão em serviço e não expõe as ordens de saída exata, nem claimTeam(), nem as leituras detalhadas dos muros. Esses casos estão marcados como “chamada direta”: eles são executados com uma ferramenta de chamada de contrato, nos endereços do manifesto da implantação testada.

1. Preparação

Registre estes elementos antes do primeiro swap: eles servem de referência para todas as comparações posteriores.

• A rede: Sepolia, identificador de cadeia 11155111.
• Os endereços da implantação testada, lidos em seu manifesto: token, hook, PoolManager, poolId, roteador, Lens, registro V2, Vault, lançador; depois, com o launchpad adicionado, vault de governança e Forge. Não copie nenhuma chave privada para suas anotações.
• Os parâmetros fixos: fee, tickSpacing, LAUNCH_ETH, MIN_POOL_SUPPLY, launchTimestamp, moduleRevision.
• O estado inicial: snapshot() do Lens, band() do hook, totalSupply() e totalBurned() do token, pendingFloorEth, pendingAbsorbedTokens, wallCount(), activeWallCount(), teamAccrued, teamPaidCumulative, rewardReserve() do Vault e o número do bloco de leitura.

Reserve ETH de teste além dos valores trocados: cada transação paga seu gas, e vários casos exigem transações recusadas, que também consomem gas.

2. Lançamento e faixa

Na inicialização do pool, o hook coloca todo o seu depósito em uma única posição [minUsableTick, tickUpper], identificada por BAND_SALT. tickUpper é o tick de abertura arredondado para baixo ao spacing, de modo que a posição contém apenas CUBIT. O hook recusa um depósito inferior a MIN_POOL_SUPPLY, ou seja, 80% da oferta, e queima a poeira de arredondamento.

O lançamento completo também transfere 20% da oferta para a reserva do Vault e efetua uma compra de 0,1 ETH na mesma transação.

3. Percurso de compra e venda

O roteador expõe swapExactIn(key, zeroForOne, amountIn, amountOutMin, recipient, deadline) e swapExactOut(key, zeroForOne, amountOut, amountInMax, recipient, deadline). zeroForOne = true compra CUBIT com ETH.

Nas fontes atuais do dapp, a interface usa apenas a entrada exata. O usuário sempre digita o valor que paga; a quantidade recebida é um campo somente leitura. Os percursos de saída exata devem, portanto, ser testados por chamada direta ao roteador.

Uma compra envia ETH nativo em msg.value. Uma venda envia valor nulo e exige uma aprovação ERC-20 do CUBIT ao roteador: a interface solicita a autorização do valor exato, nunca ilimitada; por isso, uma venda maior exige uma nova autorização.

O roteador recusa preenchimentos parciais: uma entrada exata não totalmente consumida aciona IncompleteInput, e uma saída exata não totalmente atendida aciona InsufficientOutput. Como a taxa é dimensionada sobre o valor solicitado, o cancelamento protege o usuário.

Configurações da interface lidas nas fontes do dapp, a verificar durante os testes de aceitação: tolerância de slippage padrão de 1,0%, entrada limitada a duas casas decimais e ao intervalo 0 a 99,99; mínimo recebido calculado em inteiros e arredondado para o wei superior; cotação atual por 30 segundos; prazo on-chain = timestamp da cadeia mais 120 segundos menos a idade da cotação.

4. Taxas e contabilidade

Em entrada exata, a taxa de compra está incluída no valor fornecido e arredondada para o wei superior. Em saída exata, ela é somada por cima da perna do pool, de modo que a taxa em relação ao total continua sendo 3%.

Para uma venda de saída exata, a taxa vale ceil(saída × 1500 / 8500): o pool produz a saída solicitada mais a taxa. Para uma venda de entrada exata, ela vale ceil(bruto × 15%). Na distribuição, a parcela da equipe é arredondada para baixo e todo o resíduo em wei vai para os muros.

Nas fontes atuais do dapp, a interface exige ler esses percentuais na cadeia antes de autorizar um swap: enquanto eles não forem verificados, o botão permanece em espera.

5. Muros automáticos

A cada venda, em entrada exata ou em saída exata, o hook chama _collectCrossedWalls() e depois _placeWall(). Ele primeiro esvazia todos os muros que o preço atravessou totalmente, do mais próximo ao mais distante, e depois aloca todos os ETH pendentes no alvo 0,4 × preço atual + 0,6 × preço de lançamento, calculado sobre o preço após a venda e arredondado ao tick. Se esse alvo não estiver estritamente acima do tick do pool, o que acontece no preço de lançamento ou abaixo dele, o muro é colocado 1% abaixo do preço atual.

Um muro esvaziado soma seus CUBIT a pendingAbsorbedTokens e devolve seus ETH restantes, taxas e poeira, a pendingFloorEth. Um muro apenas parcialmente consumido permanece no lugar. Somente um valor pequeno demais para criar liquidez e o caso extremo de um preço no topo do intervalo de ticks, onde nenhum muro cabe abaixo do preço, deixam fundos aguardando em pendingFloorEth: a venda nunca é recusada por isso. Em seguida, o roteador CUBIT chama deliverAbsorbed() em um try/catch.

A referência floorPrice() do Lens descreve o último muro financiado, não um mínimo global. Cada muro atravessado custa cerca de 185 000 gas: uma venda atravessa no máximo cerca de 88 muros dentro do limite de 16 777 216 gas de uma transação.

6. mCUBIT Vault

O Vault paga uma recompensa em CUBIT, retirada exclusivamente de rewardReserve. Ela vale DAILY_REWARD_BPS = 300, ou seja, 3% do depósito por período de 24 horas (REWARD_PERIOD), calculada proporcionalmente e limitada a um período: além dele, o excedente é perdido. Ela nunca ultrapassa o saldo da reserva e nunca é paga a partir do principal.

Cada depósito reinicia um bloqueio de 24 horas (LOCK_DURATION) sobre toda a posição da carteira; a retirada antes do vencimento é recusada por Locked. Um depósito, uma retirada ou um resgate paga primeiro a recompensa acumulada e reinicia o período. Qualquer conta pode alimentar a reserva com fundRewardReserve(amount). O vencimento é avaliado pelo timestamp da cadeia, não pelo relógio do navegador.

A recompensa é exclusivamente em CUBIT, resgatada com claimCubit(): o Vault não expõe nenhuma função de recompensa em WETH.

7. Vault de governança do launchpad

O vault de governança recebe as taxas de lançamento da Forge, em ETH, e os tokens absorvidos pelos muros dos filhos Forge. Cada depósito fica bloqueado por 30 dias (LOCK_DURATION) a partir de seu próprio recebimento. Somente o deployer pode resgatar, para sempre e sem possibilidade de transferir esse direito, e apenas os lotes cuja data já passou, do mais antigo ao mais recente. O ETH é contabilizado sob a chave ETH(), o endereço zero. Releia a ABI da implantação testada antes dos testes de aceitação. O deployer pode estender o bloqueio de todos os depósitos, presentes e futuros, com extendLock; lockExtension() só aumenta e é somado a cada data.

O envio automático a partir dos muros dos filhos é verificado por T-52, e o depósito da taxa de lançamento por T-81. Os casos T-67 a T-73 depositam tokens de teste por chamada direta; T-108 resgata o ETH de uma taxa.

8. Forge

A Forge é um launchpad público, apresentado como lançamento futuro. Ela não faz parte do lançamento do CUBIT: é adicionada depois, com seu vault de governança. Anote seus endereços depois que o launchpad for adicionado.

Qualquer conta lança um filho pagando a taxa exata. Um filho Forge deposita toda a sua oferta em sua faixa, a Forge recebe o endereço do vault de governança em sua construção, e cada lançamento paga sua taxa de 0,005 ETH a esse vault, que a mantém: quem lança nunca a recupera. Os salts de implantação são vinculados a quem lança.

9. Substituições e poderes

A autoridade do registro pode substituir quatro endereços periféricos a qualquer momento, sem prazo de espera: Vault, roteador, Lens e Forge. Cada substituição emite ModuleUpdated, incrementa moduleRevision e fecha a funcionalidade correspondente até que a equipe a reabra: Vault, Momentum ou Forge; substituir o roteador não fecha nenhuma funcionalidade. Um candidato já registrado, conectado a outro hook ou a outro token, ou que já tenha stake, é recusado por InvalidModule.

O hook não tem nenhum administrador, e ninguém pode pausar os swaps nem o mecanismo dos muros. O endereço da equipe mantém poderes permanentes: ele recebe a parcela da equipe nas taxas e substitui e, em seguida, ativa os módulos do registro.

10. Casos de recusa esperados

Esta tabela serve de referência durante todos os testes de aceitação. Os muros automáticos não acrescentam recusas à venda: um muro que não pode ser colocado deixa os fundos pendentes, e um envio malsucedido deixa os CUBIT pendentes.

Ponto de atenção. Nas fontes atuais do dapp, os erros de contrato não são traduzidos: uma recusa on-chain pode aparecer como uma mensagem bruta, truncada na exibição. Para cada recusa acionada, registre o texto exato exibido e avalie se ele é compreensível.

As recusas puramente do aplicativo também são registradas: cotação desatualizada, contexto de swap alterado, carteira em outra cadeia, conta trocada, revisão de módulos alterada, percentuais das taxas ainda não verificados.

11. Aplicativo

Estes casos são executados com o dapp. Os comportamentos de interface citados vêm de suas fontes e são verificados durante os testes de aceitação.

12. Ficha de registro

Cada tabela das seções anteriores é a ficha de registro de sua seção: preencha as colunas “Resultado observado” e “Gravidade” à medida que avança pelos casos. No resultado observado, anote no mínimo o hash da transação ou o bloco de leitura e, depois, o que foi constatado.

Resumo a anexar ao relatório:

Um desvio se refere ao número do caso, nunca a uma captura de tela isolada. Anexe a rede, o endereço da implantação, o bloco, o hash e a versão do aplicativo.

Limites deste plano

Este plano descreve o que o código da nova versão e as decisões de 14 de setembro de 2026 preveem. Ele não constitui uma validação: testes de aceitação bem-sucedidos na Sepolia não substituem as campanhas de testes.

Os pontos “a confirmar durante o teste” devem ser observados e, depois, incorporados a esta página.

Fontes: contracts/src/CubitHook.sol, CubitLens.sol, interfaces/ICubitHook.sol, interfaces/ICubitLens.sol, libraries/BandLib.sol, libraries/WallLib.sol, periphery/CubitRouter.sol, CubitV2.sol, CubitVault.sol, CubitGovernanceVault.sol, CubitForge.sol, CubitLaunch.sol, os percursos atuais de dapp/src e as decisões de design de 14 de setembro de 2026 registradas em contracts/docs/REDESIGN_HANDOFF.md.