Testes e verificação

Os níveis

Os invariantes econômicos

São as igualdades que precisam valer sempre:

1. As quatro partes somam exatamente a taxa cobrada, 500 pontos-base por padrão, sem perder nenhum wei
2. Ninguém pode sacar os ativos de um vault para um endereço da sua escolha; as únicas reduções possíveis são a conversão, o airdrop aos holders e a transferência de emergência do owner
3. Os pesos de um basket somam 100 % e nunca mudam
4. As duas posições são depositadas na criação e só podem ser removidas pelo modo de encerramento, 30 dias depois do seu anúncio
5. A liquidez está travada; a sua única saída é o modo de encerramento, que o owner anuncia com 30 dias de antecedência
6. O buyback de $STOCKFUN não pode enviar os tokens comprados para nenhum lugar além do burn
7. O supply do criador é zero em todos os mercados
8. Um vault só pode comprar os ativos do seu basket
9. Um vault só adquire ETH, USDC, USDG e as ações do seu basket, além de reembolsos em USDon no trilho opcional da Ondo
10. Um ciclo de airdrop nunca paga mais do que detém, ação por ação, e nenhum holder recebe mais do que a sua parte pro rata; o que o contrato do airdrop deve, somando ciclos e ações guardadas à parte, nunca excede o seu saldo — exigido desde 2026-09-27, testado desde 2026-10-04 por um invariante com estado. Desde 2026-10-05, também através das emergências, o que lastreia essas contas é sempre feito de tokens que o contrato realmente detém, nunca de tokens ainda não creditados, testado por um segundo invariante com estado
11. Só o lock de liquidez adiciona liquidez a um pool do StockFun
12. Um trade não paga ninguém além do vault do mercado; as outras partes esperam no hook até serem reivindicadas. Desde 2026-10-05, a parte que um vault recusa fica devida a ele no hook, e o trade continua
13. Cada ação do basket gasta apenas o caixa reservado para ela

Eles são verificados nas implementações atuais; um upgrade substitui o código sobre o qual são verificados.

A restrição de tamanho

O limite do EIP-170 é de 24.576 bytes de código de runtime. Ele é imposto por um teste que faz a suíte de testes falhar, não por inspeção manual.

É uma restrição real aqui: a factory teve de ser dividida. Até 2026-10-02, o deployer de vaults, que embutia o creation code de um TreasuryVault, era o contrato mais próximo do teto, e cada linha adicionada ao vault era descontada dessa folga. A remoção do buyback do criador, em 2026-09-28, o levou de 23.055 para 14.965 bytes; as correções de 2026-10-01, que reservam o caixa ação por ação, o levaram a 15.954. Desde 2026-10-02, ele implanta um proxy, e o que precisa caber dentro do limite é a implementação de cada módulo.

Em 2026-10-05, o contrato do airdrop passou a ser o mais próximo. As reivindicações do quarto loop de auditoria o levaram acima do limite; tornar privadas algumas das suas funções de leitura e retirar as suas transferências de emergência imputadas a um único ciclo o trouxeram de volta a 24.432 bytes, 144 abaixo do teto.

Depois da auditoria de 2026-09-29

Cada achado corrigido depois da auditoria de segurança de 2026-09-29 tem testes de regressão que falham no código auditado; a maioria são as provas de conceito da auditoria, invertidas para verificar o comportamento corrigido.

O pipeline de segurança de 2026-10-01

Uma segunda rodada de auditoria, por dois auditores independentes, e depois todas as verificações de novo sobre o código corrigido. Cada uma das suas correções nos contratos e no keeper tem testes de regressão. Em 2026-10-01, depois dessas correções:

• Foundry. Os 421 testes fora das suítes de fork passam, assim como o perfil profundo: 20.000 execuções de fuzz, invariantes com 512 execuções de profundidade 128. As suítes de fork não rodaram: nenhuma URL de RPC estava disponível.
• Testes de mutação. O slither-mutate rodou em cinco contratos: o distribuidor de taxas, o registro de posições, o vault da tesouraria, o router de ações da Robinhood Chain e o hub remoto. Gerou 1.301 mutantes, pequenas mudanças deliberadas no código, e os testes pegaram 1.118. Dos 183 que sobreviveram, 107 são equivalentes ao código original: nenhuma entrada consegue diferenciá-los. Os outros 76 revelaram verificações que os testes não faziam; agora os testes cobrem todas elas. Nenhum mutante revelou um bug.
• Verificação formal. Todos os jobs Certora foram executados de novo no prover, sobre o código corrigido (certora-cli 8.8.1, verificações básicas de sanidade). Nenhuma regra foi violada. Sete regras do LiquidityLock continuam sem decisão em um método, lockProtocolLiquidity: excederam o tempo limite, e uma nova execução com um limite maior terminou sem veredito. Elas valem em todos os outros métodos; esse método é exclusivo do owner, roda uma única vez, para $STOCKFUN, e os testes de Foundry cobrem seu acesso, seu uso único e o formato do seu lock. Os outros resultados não verificados são casos conhecidos de vacuidade: uma regra executada sobre cada método, para um método que nunca pode ter sucesso na configuração verificada. As falhas da primeira execução do TreasuryVault vieram de dois artefatos da especificação, nenhum deles um bug; a especificação foi corrigida.
• Fuzzing e execução simbólica. O Medusa rodou cinco propriedades do registro de posições por dez minutos, sem nenhuma falha. A sua primeira execução constatou que, numa chain cujo relógio começa na hora 0, uma chain de teste, faltava a primeira marca horária do supply registrado; nenhuma chain real foi afetada, e o token agora registra essa marca na implantação. O Halmos passa em três verificações simbólicas para toda entrada dentro dos limites: a divisão da taxa é exata, o supply registrado acompanha quaisquer duas transferências, e a sua integral na hora seguinte está correta. O Mythril não consegue explorar os contratos do protocolo fora de uma implantação, cerca de 14 % de cobertura; no registro de posições, que é autônomo, atingiu 31 % em 15 minutos e não reportou nada.
• Análise estática. Slither, Aderyn e Solhint não encontraram nada novo.
• Numa chain local nova. Uma implantação completa, um ciclo real do keeper e dez casos de uso passam. O ensaio de implantação, os scripts de produção executados na ordem do runbook, passa depois da correção de um script: o script do trilho mock cunhava os seus fundos iniciais para o remetente padrão do forge, em vez da chave de implantação.

Essa execução também verificou 11 regras do TeamVesting, um contrato removido com a sua especificação em 2026-10-05. O prover não cobre o lado da Robinhood Chain: o hub remoto, os vaults espelho e o router de ações.

A reformulação upgradável de 2026-10-02

A reformulação que tornou os módulos upgradáveis veio depois de todas as verificações acima. Em 2026-10-02, sobre o novo código:

• Foundry. Os 458 testes fora das suítes de fork passam. Novas suítes cobrem os upgrades, no Ethereum e na Robinhood Chain — quem pode fazer upgrade, a autoridade e o PoolManager que uma nova implementação precisa manter, os vaults um a um — e o modo de encerramento. A suíte do registro de posições acompanhou o registro, para o registrador de posições.
• Layouts de storage. O layout de storage de cada módulo upgradável é registrado em contracts/storage-layouts/, e contracts/script/check-storage-layouts.sh falha com qualquer mudança que não seja um acréscimo. Ele foi feito para rodar antes de cada upgrade. Desde 2026-10-05, ele verifica cada nível de cada struct: veja Implantação.
• Numa chain local nova. O script LocalRun passa.
• Verificação formal. As especificações Certora estão sendo atualizadas para o novo código. A sua última execução completa no prover, em 2026-10-01, é anterior à reformulação: a tabela acima descreve essa execução.

O perfil profundo, os testes de mutação, o fuzzing e a execução simbólica e a análise estática descritos acima rodaram em 2026-10-01, sobre o código anterior à reformulação.

O airdrop de 2026-10-04

O contrato do airdrop e os dois caminhos sendToAirdrop, codificados em 2026-10-04, não implantados. Naquele dia, sobre o novo código:

• Foundry. Os 514 testes fora das suítes de fork passam, contra 459 antes do airdrop. Três novas suítes: AirdropDistributorTest, 38 testes; AirdropCrossChainTest, 15, com a LayerZero simulada por mocks; AirdropInvariantsTest, 2, em torno de um invariante com estado: conservação e solvência em dois mercados sob envios, reivindicações, alocações, aberturas e mudanças de exclusões e de horário do ciclo aleatórios, 128 execuções de 64 chamadas. Um fuzz do cálculo das partes roda 512 vezes.
• Gas. Reivindicar um ciclo de duas ou três ações custa aproximadamente 120.000 a 210.000 de gas, conforme medido nos testes, que rodam com storage quente: uma transação real custa um pouco mais. Uma entrega vinda da Robinhood Chain custa cerca de 85.000 a 1.016.000 de gas no Ethereum, medido a frio: veja Implantação.
• Numa chain local. No Anvil, LocalRun e depois LocalAirdrop: dois holders, ações guardadas à parte antes das 13:00 UTC, depois alocadas e reivindicadas. Cada reivindicação é exatamente o piso da sua parte, com 1 wei de poeira por ação.
• Verificação formal. As cinco especificações Certora que tocam os contratos alterados passam na verificação de tipos. O prover não foi executado, e nenhuma especificação cobre o contrato do airdrop.
• Offchain. Os 93 testes do keeper, os 43 do pacote compartilhado, os 9 do backend e os 58 do worker passam.
• Revisões. O Codex (gpt-6-astra) revisou o design e depois o código: um Medium, sobre o momento das ações guardadas à parte, e um Low, sobre o script local, ambos corrigidos. Uma nova revisão das correções encontrou um Medium, sobre o momento das mudanças de exclusões, e um Low, sobre a ordem do script local, ambos corrigidos: uma janela é medida contra a lista de exclusão em vigor quando fechou, e o script aloca primeiro as ações guardadas à parte. Uma verificação final dessas duas correções não encontrou nenhum bug, dentro da garantia declarada: as ações guardadas à parte vão para a primeira janela com posições elegíveis, seja quem for que chame e seja quando for, desde que, nesse meio-tempo, o horário do ciclo não mude e o registrador de posições do token não seja substituído. Os relatórios estão em projet/docs/audit-2026-10-04/.

As mudanças de 2026-10-05

Nenhuma alocação para a equipe, um modo de emergência imediato e todo número como um parâmetro do owner, codificados em 2026-10-05, não implantados. Naquele dia, sobre o novo código:

• Foundry. A suíte passa, 520 testes. Duas novas suítes, Settings e SettingsCrossChain, cobrem cada parâmetro: quem pode defini-lo, os valores que ele recusa e a próxima operação depois de uma mudança — entre eles a taxa e o anti-snipe, o formato de lançamento, cada pool mantendo a sua chave, e as partes do que as posições travadas coletam. As propriedades da taxa, com fuzzing e execução simbólica, valem para quaisquer parâmetros aceitos. Os testes de emergência acompanham a transferência imediata, e os testes do contrato de vesting foram removidos com ele.
• Gas. Ler os parâmetros da taxa custa a um swap cerca de 1.200 de gas a mais, com storage quente.
• Verificação formal. As especificações da taxa, do hook, do lock, da factory, dos tokens e do oráculo acompanham os parâmetros e passam na verificação de tipos localmente. O prover não foi executado.

Os loops de auditoria de 2026-10-05

No mesmo dia, cinco loops de revisão percorreram o código, não implantado; a partir do quarto, uma violação da regra do fundador de que uma falha nunca bloqueia o resto conta como um defeito (veja Arquitetura). Cada correção tem um teste de regressão. No código de cada loop:

• Foundry. 602 testes passam depois do quarto loop e 613 depois do quinto; no fim do dia, 614 passam, com três suítes de fork puladas por falta de RPC. Todo contrato cabe sob o EIP-170, e os layouts de storage só cresceram onde uma correção acrescentou estado.
• Invariantes. Os invariantes do airdrop passam 512 execuções de profundidade 128 no perfil profundo, depois do terceiro loop. Um segundo invariante com estado conduz o airdrop por emergências: entregas cujo último passo roda tarde, tokens extraviados, transferências para fora, devoluções, baixas e pausas e, desde o quinto loop, ações congeladas pelo seu emissor e claimMany.
• Verificação formal. Os loops acrescentaram regras sobre o hook (as suas dívidas com os vaults, o que está extraviado), sobre o lock (as partes que ele guarda, os seus rescues), sobre o burner e os tokens (os seus rescues), e uma regra de que só o owner do protocolo faz rescue nos routers, no oráculo e na factory: 213 regras e invariantes em 11 especificações depois do quarto loop, mais uma sobre os rescues dos tokens depois do quinto. Cada especificação tocada passa na verificação de tipos localmente; nada foi enviado ao prover, cuja última execução continua sendo a de 2026-10-01.
• Offchain. Depois da etapa do airdrop no keeper, da tela de reivindicação do dapp e da passada offchain do quarto loop: os 191 testes do keeper, os 51 do pacote compartilhado, os 9 do back end e os 90 do worker passam, e o app passa na sua verificação de tipos e no seu lint.
• Numa chain local. No Anvil, LocalRun, depois o keeper, o motor do worker e a preparação de reivindicações do app: na janela da implantação, o keeper não enviou nada; na seguinte, abriu dois ciclos e enviou as ações de dois vaults, e um claimMany pagou cinco ações nos dois ciclos, a cerca de 421.000 de gas, depois do que claimable passou a indicar zero.

A passada offchain do quinto loop, 2026-10-06

A revisão do keeper, do worker, do app e dos scripts no quinto loop encontrou três problemas de média gravidade e dezesseis de baixa gravidade, cada um corrigido com um teste de regressão, não implantado. Executado em 2026-10-06:

• Foundry. 619 testes passam no código daquele dia, com três suítes de fork puladas por falta de RPC: os novos campos da Lens, o teto de cinco ações por basket e o lançamento retomado do $STOCKFUN têm os seus testes. Os layouts de storage não mudaram.
• Offchain. Os 210 testes do keeper, os 51 do pacote compartilhado, os 9 do back end e os 111 do worker passam; os testes de cada correção do keeper falham quando a correção é removida. O app passa na sua verificação de tipos e no seu lint; ele não tem executor de testes, e a sua preparação de reivindicações passou para o motor do worker, cujos testes a cobrem.
• Numa chain local. Um ensaio num Anvil privado passou nos seus seis cenários: LocalRun, cujo dry run não grava nenhum arquivo de implantação; o keeper ao longo de duas janelas, convertendo o ETH de cada vault uma vez por janela, depois alocando, abrindo e enviando o airdrop uma vez, cada reivindicação exata até o wei; um vault que recusa ETH, com as suas dívidas no hook e no lock pagas depois de restaurado; interrupções no meio da operação com o arquivo de estado e a sua trava, nada enviado duas vezes, uma transação substituída e uma descartada tratadas; os rescues e uma coleta diária das taxas de LP. O trilho da bridge, o app e o worker não fizeram parte dele.

Depois do ensaio, 2026-10-06

As constatações do ensaio foram corrigidas no mesmo dia, não implantadas. O keeper aloca as ações que o contrato do airdrop guarda à parte para um mercado mesmo quando o seu vault não tem nada novo a enviar, e registra um vault encontrado abaixo do limiar pela janela para a qual foi verificado, nunca pelo seu próprio relógio; ele conta separadamente um envio que fica guardado à parte, deixa em paz as poucas unidades de USDC que a última perna de compra de um vault nunca consegue gastar, e mostra os ids dos pools no seu log. A primeira área do sexto loop de revisão não encontrou nada nos contratos e um problema de baixa gravidade num script local, corrigido: o arquivo de implantação local é verificado contra a chain antes que o keeper, o app ou o worker o usem. Nesse código:

• Foundry. 620 testes passam, com três suítes de fork puladas por falta de RPC: um a mais, em que um lançamento retomado do $STOCKFUN recusou um vault que detém as ações de outro basket
• Offchain. Os 218 testes do keeper, os 51 do pacote compartilhado, os 9 do back end e os 111 do worker passam; os testes de cada correção do keeper falham no keeper anterior a ela. A verificação do arquivo de implantação local não tem teste automatizado: ela foi executada à mão num Anvil privado, onde aceitou uma implantação nova e recusou um arquivo com os papéis de dois contratos trocados

Depois do sexto e do sétimo loops de auditoria, 2026-10-06

As correções do keeper e do worker do sexto loop e as do sétimo foram feitas no mesmo dia, não implantadas; o código de nenhum contrato mudou em nenhum dos dois, e só um comentário de um contrato foi corrigido. Executado em 2026-10-06, no commit 415dcae (os contratos a partir de uma cópia limpa desse commit, já que outro trabalho nos contratos estava em andamento):

• Foundry. 620 testes passam: 615 fora dos arquivos de fork, e os cinco da suíte de fork da Robinhood Chain contra o seu RPC público; as três suítes de fork do Ethereum são puladas por falta de RPC. A mesma contagem de depois do ensaio: nenhum teste de contrato mudou
• Offchain. Os 277 testes do keeper, os 51 do pacote compartilhado, os 9 do back end e os 137 do worker, em 11 arquivos, passam. Cada prova de conceito do sétimo loop é um teste de regressão, e os novos testes de cada correção falham no código anterior a ela, exceto os poucos que fixam o que o código antigo já fazia (um envio que o keeper não consegue avaliar vai como antes; um arquivo de estado antigo carrega) e os do gráfico, cujas funções são novas. Um arquivo de estado gravado pelo keeper antes do sexto loop é mantido como fixture de teste e carrega no novo keeper
• O app. Ele passa na sua verificação de tipos, no seu lint e no seu build, e o seu gráfico de demonstração pré-renderizado ocupa toda a área do gráfico; ele não tem executor de testes, e nenhum teste em navegador foi executado. O posicionamento do gráfico roda código do motor do worker, que os testes do worker cobrem

As proteções dos feeds de preço e o oitavo loop de auditoria, 2026-10-06

As duas proteções dos feeds de preço do oráculo para a Robinhood Chain foram escritas em 2026-10-06, e as correções do keeper, do worker e do app do oitavo loop no mesmo dia, não implantadas. Os contratos mudaram com as proteções, não com o loop. Executado em 2026-10-06, no commit 6586d40 (os contratos a partir de uma cópia limpa desse commit, já que outro trabalho nos contratos estava em andamento):

• Foundry. 640 testes passam: 633 fora dos arquivos de fork, em 82 suítes, e os sete do arquivo de fork da Robinhood Chain contra o seu RPC público; as três suítes de fork do Ethereum são puladas por falta de RPC. As proteções acrescentaram 18 testes fora dos arquivos de fork: 16 só no oráculo, com feeds e tokens mock (cada salvaguarda desligada, depois ligada, cada forma pela qual um feed ou um token pode deixar de responder, cada resposta que conta como pausa, uma leitura privada de gas, os parâmetros do owner e as recusas do script de implantação), e 2 no trilho cross-chain (a perna de uma ação pausada falha sozinha e compra quando a pausa é levantada; uma queda do sequenciador para todas as pernas até o fim do seu período de carência). Os dois novos testes de fork leem os tokens reais das ações: cada um dos vinte responde ao sinal de pausa como o oráculo o lê, a leitura mais cara tendo custado 13.288 de gas, e um token pausado onde o seu código real guarda a flag retém só o seu próprio preço
• Storage e especificações. Os layouts de storage dos 17 módulos upgradáveis não mudaram, exceto pelo acréscimo do oráculo; a especificação formal do oráculo, 25 regras e invariantes, passa na verificação de tipos, sem execução no prover
• Offchain. Os 306 testes do keeper, os 51 do pacote compartilhado, os 9 do back end e os 155 do worker, em 12 arquivos, passam. Cada prova de conceito do oitavo loop é um teste de regressão, e os novos testes de cada correção falham no código anterior a ela, exceto os de funções que são novas
• O app. Ele passa na sua verificação de tipos, no seu lint, na verificação do seu motor e no seu build; ele não tem executor de testes, e nenhum teste em navegador foi executado. A verificação do basket do seu formulário de lançamento e a taxa do seu painel de trade rodam código do motor do worker, que os testes do worker cobrem

O nono loop de auditoria, a Glamsterdam e a execução em testnet com a LayerZero, 2026-10-06

As correções do nono loop, o gas da entrega do airdrop sob a atualização Glamsterdam do Ethereum e a nova execução pelo keeper de uma entrega presa foram feitas em 2026-10-06, não implantadas na mainnet. Uma mudança de contrato (as políticas de gas do hub remoto e o envio e a cotação de três argumentos do vault espelho) veio com elas, testada por nove novos testes do trilho cross-chain (os padrões contra as medições, a limitação nos dois extremos, as opções do envio e a cotação que corresponde a elas, as formas de um único argumento, as recusas dos setters, uma entrega mais pesada do que o gas que o seu OFT impõe, um hub sem políticas mantendo as ações em casa, as opções byte a byte) e quatro do script de implantação. O mock do OFT das ações agora soma as opções de gas e deixa uma entrega sem gas suficiente esperando uma execução com mais, como faz o endpoint da LayerZero. Desde este loop, um segundo agente revisa a mudança de cada correção antes que ela seja enviada ao repositório (o gate de verificação), e os seus achados são corrigidos e testados da mesma forma. Executado em 2026-10-06, no commit 92a1904 (os contratos a partir de uma cópia limpa desse commit, já que outro trabalho estava em andamento):

• Foundry. 653 testes passam: 646 fora dos arquivos de fork, em 83 suítes, e os sete do arquivo de fork da Robinhood Chain contra o seu RPC público; as três suítes de fork do Ethereum são puladas por falta de RPC. O Foundry roda a tabela de gas do Cancun: os seus números de gas são os preços antigos, e os novos vêm da Sepolia
• Storage. Os layouts de storage dos 17 módulos upgradáveis não mudaram, exceto pelo acréscimo do hub remoto (as suas políticas de gas, slots 21 a 23)
• Offchain. Os 370 testes do keeper, os 51 do pacote compartilhado, os 9 do back end e os 189 do worker, em 14 arquivos, passam (os 372 do keeper em e1dd5f6, depois da última correção do gate, os outros sem mudança); o keeper e o worker passam na sua verificação de tipos. Os novos testes de cada correção falham no código anterior a ela, exceto os de funções que são novas. O novo limite de gas por escrita do app roda código do motor do worker, que os testes do worker cobrem
• O app. Ele passa na sua verificação de tipos, no seu lint e na verificação do seu motor; ele não tem executor de testes. As suas duas outras correções, o pote marcado como estimativa e a aprovação que não pôde ser lida, foram verificadas rodando o seu próprio código numa cópia de rascunho
• Na Sepolia, depois da Glamsterdam. Todo número fixo de gas dos contratos e dos scripts foi medido de novo na chain ao vivo: todos se mantêm, com folga, exceto os dois da entrega do airdrop, corrigidos pelas políticas de gas. O décimo loop de auditoria encontrou mais dois: o gas próprio dos scripts de implantação, que o forge tira da sua própria simulação aos preços antigos (toda transmissão agora usa a estimativa do nó), e o do compose da bridge, dimensionado para um mercado e não para um lote. O preflight do keeper, executado em modo somente leitura sobre a implantação da execução em testnet com a LayerZero, passa nas suas 68 verificações
• A execução em testnet com a LayerZero. O protocolo rodou de ponta a ponta na Sepolia e na testnet da Robinhood Chain sobre os endpoints, o DVN e o executor reais de testnet da LayerZero, sete janelas horárias e seis ciclos do airdrop, cada reivindicação exatamente a parte calculada a partir do registrador de posições: veja O trilho Robinhood. A sua última janela rodou no keeper do nono loop, com o gas da entrega escolhido a partir das suas simulações

O décimo loop de auditoria, 2026-10-06

As correções do décimo loop foram feitas em 2026-10-06, não implantadas na mainnet, cada uma revisada por um segundo agente antes de ser mesclada. Um contrato mudou, o adaptador da bridge do USDG: o último passo de um lote da bridge na Robinhood Chain agora recebe uma base mais uma parte por mercado, e um lote leva no máximo 17 mercados. Nove novos testes o cobrem: quatro novos mercados de cinco ações, um lote cheio de 17 e trinta mercados enviados como dois lotes, cada um rodado a frio com exatamente o seu gas; 18 mercados recusados pelo tamanho da sua mensagem; a taxa crescendo com o lote; um lote acima do teto recusado inteiro enquanto o seguinte passa; um adaptador configurado antes dos novos parâmetros que não passa nada pela bridge até que eles sejam definidos; e os limites dos parâmetros. O mock da bridge do token USDG agora recusa uma mensagem acima do limite de tamanho da LayerZero e precifica o gas, como faz a LayerZero. O procedimento de implantação não tem teste: a sua mudança foi executada na Sepolia, onde uma criação enviada com o gas próprio da ferramenta de implantação ficou sem ele, e as mesmas criações enviadas com a estimativa do nó passaram. Executado em 2026-10-07, no commit 5ea8bf0 (os contratos a partir de uma cópia limpa desse commit):

• Foundry. 662 testes passam: 655 fora dos arquivos de fork, em 84 suítes, e os sete do arquivo de fork da Robinhood Chain contra o seu RPC público; as três suítes de fork do Ethereum são puladas por falta de RPC. Os 2 testes do projeto da execução em testnet com a LayerZero passam, sobre os próprios contratos da LayerZero
• Storage. Os layouts de storage dos 17 módulos upgradáveis não mudaram, exceto pelo acréscimo do adaptador da bridge (os seus dois parâmetros de lote)
• Offchain. Os 400 testes do keeper, os 51 do pacote compartilhado, os 9 do back end e os 210 do worker, em 15 arquivos, passam; o keeper e o worker passam na sua verificação de tipos. A prova de conceito de cada revisor é um teste de regressão, e os novos testes de cada correção falham no código anterior a ela, exceto os de funções que são novas. O acompanhamento pelo app de uma transação que a carteira cancela ou substitui, e as suas leituras num bloco não anterior ao da sua própria última transação, rodam código do motor do worker, que os testes do worker cobrem
• O app. Ele passa na sua verificação de tipos, no seu lint e na verificação do seu motor; ele não tem executor de testes
• Nas testnets. O adaptador da bridge da execução em testnet com a LayerZero recebeu upgrade na Sepolia em 2026-10-06, e o seu lote seguinte, um mercado, foi entregue e composto pelo executor da LayerZero com o seu novo gas, 600.000, dos quais 115.990 foram usados

O que os testes não provam

Isto importa, e os próprios relatórios do projeto o dizem com todas as letras.

Os testes locais simulam a entrega cross-chain. Eles não provam uma entrega real via LayerZero. Os testes cross-chain do airdrop rodam contra mocks da LayerZero e dos adaptadores de ações, que não estão no repositório para a mainnet. As suítes de fork foram excluídas de pelo menos uma execução porque os endpoints públicos retornaram erros HTTP — e aquele relatório diz isso em vez de apresentar as suítes como aprovadas.

A execução em testnet com a LayerZero de 2026-10-06 levou mensagens reais da LayerZero entre duas testnets, com ações de teste, adaptadores de teste, um USDG de teste e feeds simulados: ela prova o código do StockFun sobre o transporte da LayerZero, não o par USDG da Paxos, as ações da Robinhood e os seus adaptadores, feeds e liquidez reais, nem o gas, as taxas e a finalidade da mainnet.

Nenhuma execução prova: transporte via LayerZero na mainnet, uma revisão externa ou uma prova formal que cubra o trilho atual. A execução em testnet assinou com carteiras reais, três das suas reivindicações pelo app.

Localmente

O cenário completo roda em quatro terminais: a chain, a implantação e a simulação, o serviço de preços, o dapp. Depois, o keeper e o harness de navegador.

O procedimento exato está em projet/docs/LOCAL_TESTING.md.