O trilho Robinhood

As ações tokenizadas que os vaults detêm ficam na Robinhood Chain, uma L2 Arbitrum Orbit. O protocolo chega até ela pela LayerZero, com o OFT USDG da Paxos como perna de caixa.

Por que este trilho

A escolha foi decidida em 2026-09-11, depois de descartado o trilho anterior.

Num trilho de mint primário, um contrato de vault precisa ser elegível para deter o ativo junto ao emissor: KYB, registro do endereço do contrato e uma confirmação por escrito que o emissor nunca documentou publicamente. Era o único bloqueio realmente incontornável do projeto.

Os pools secundários da Robinhood Chain não exigem nada disso: são abertos a todos. O StockFun não tem nenhuma relação com o emissor e não precisa de nenhuma.

O preço pago por essa liberdade é uma dependência cross-chain: uma bridge, dois hubs e uma stablecoin emitida por um terceiro que pode congelá-la. É um risco aceito e documentado, não um risco evitado.

O circuito

O caminho de volta do USDG, da Robinhood Chain para o Ethereum, só servia ao buyback do criador; os dois foram removidos do código em 2026-09-28.

O que é permissionless e o que não é

A última linha é a dependência mais dura do trilho, e ela é real.

O vault espelho

Cada mercado tem um vault espelho na Robinhood Chain, implantado via CREATE2 num endereço previsível a partir do Ethereum. O keeper pode, portanto, fazer o hub remoto pré-implantá-lo antes de o USDC chegar, para que uma transferência nunca caia num endereço sem código. Desde 2026-10-05, só o keeper e o owner do StockFun podem fazê-lo (predeploy): até então, qualquer pessoa podia, mesmo para um mercado que ainda não existia, vinculando o seu vault espelho à conexão daquele dia. O hub remoto passa a conhecer o keeper por meio de um lote da bridge, que o leva: antes do primeiro lote, ele não conhece nenhum keeper, então o owner do StockFun pré-implanta o vault espelho do primeiro mercado. Desde o segundo loop de auditoria de 2026-10-05, um mercado cujo vault espelho o keeper não consegue pré-implantar (antes do primeiro lote, ou depois de uma mudança de keeper que o hub remoto ainda não conhece) fica de fora do lote, com um alerta, em vez de ser enviado com gas insuficiente para implantar o seu vault; os outros mercados atravessam, e o lote deles leva o novo keeper.

Desde 2026-10-02, cada vault espelho é um proxy, um MirrorVaultProxy, na frente da implementação de vault que o hub remoto designa quando o vault é implantado. O construtor do proxy não recebe nenhum argumento, então o seu creation code, e com ele o endereço de cada vault espelho, continua previsível a partir do Ethereum, qualquer que seja a implementação. O basket do vault chega com o primeiro lote, que desde 2026-10-05 também atualiza o router de ações e o oráculo do vault para os que o hub remoto designa nesse momento: um vault implantado antes de uma ação ser listada aceita um basket com essa ação. O owner do StockFun, tal como o hub remoto o espelha, faz o upgrade dos vaults espelho um a um, mercado a mercado, com efeito imediato.

As rotas de swap não são fixas no código: chegam no calldata, codificadas como abi.encode(uint8 version, bytes payload) — versão 3 para um caminho compactado do Uniswap v3, versão 4 para um array de PathKeys v4. O vault recebe vários candidatos por perna e executa no primeiro que passar pelo seu limite. Desde 2026-10-01, uma rota que executa só parte do valor falha, e o candidato seguinte é tentado; antes, uma execução parcial numa rota v3 deixava o USDG não gasto preso no router.

Desde o pipeline de segurança de 2026-10-01, uma rota v3 é executada um pool de cada vez. Cada pool precisa consumir toda a sua entrada, senão a rota falha; a sua saída volta para o router de ações e é a entrada do pool seguinte, e o último pool paga o vault, sujeito ao mínimo da perna. Um pool que falha desfaz os pools anteriores da mesma tentativa, e o candidato seguinte é tentado. Até então, a verificação só via o primeiro pool de uma rota: uma execução parcial mais adiante deixava o token intermediário no router v3 do Uniswap, SwapRouter02, onde qualquer pessoa podia pegá-lo, enquanto a perna era bem-sucedida. Uma perna v3 com vários saltos agora custa um swap e uma aprovação por pool.

Cada perna gasta apenas o USDG reservado para a sua ação, segundo os pesos do basket: veja O TreasuryVault. O seu limite de preço em relação ao feed da ação, 200 pontos-base por padrão, é um parâmetro que o hub remoto guarda e que todo vault espelho lê em tempo real (setStockMaxSlippageBps). Desde 2026-10-05, o vault aplica o próprio mínimo do keeper, nunca mais frouxo do que esse limite, ao que realmente chegou.

Quando o oráculo retém um preço

Desde 2026-10-06, o oráculo dos vaults espelho tem duas salvaguardas, que a própria documentação da Robinhood recomenda; cada uma só pode reter um preço, nunca mudá-lo.

• Um evento corporativo. Enquanto uma ação passa por um (um desdobramento, por exemplo), o seu token diz que o seu oráculo está pausado (oraclePaused()), e o seu feed da Chainlink mantém o seu último valor, que ainda pode parecer recente enquanto o multiplicador do token muda. O oráculo então retém o preço dessa ação: a sua perna de compra falha sozinha (StockOraclePaused), o seu USDG continua reservado para ela, e as outras ações do basket são compradas. A verificação está ligada para toda ação; o owner do StockFun pode desligá-la para uma ação (setOraclePauseCheck), e o preço dela passa então a depender só das verificações do próprio feed. Um token que não responde conta como não pausado.
• O sequenciador. A Robinhood Chain é uma chain Arbitrum com um único sequenciador. Com o feed de disponibilidade do sequenciador L2 da Chainlink definido (setSequencerUptimeFeed), o oráculo retém todos os preços enquanto o feed diz que o sequenciador está fora do ar, que voltou há não mais que o período de carência (uma hora por padrão), ou não pode ser lido: nenhuma perna compra até lá. Hoje não existe nenhum feed assim para a Robinhood Chain, então o trilho é implantado com essa verificação desligada; o owner do StockFun define o feed se a Chainlink publicar um.

O keeper vê as duas antes de cotar qualquer coisa (veja O keeper), o Worker diz por que falta o preço de uma ação, e o dapp o mostra (veja O dapp).

O envio das ações ao airdrop

Desde 2026-10-04, depois de compradas, as ações saem do vault espelho por um único caminho: sendToAirdrop. O keeper o chama com a lista de ações a enviar e paga as taxas da LayerZero; o que ele paga a mais lhe é devolvido. Para cada ação, o vault envia o seu saldo inteiro pelo adaptador dessa ação para o contrato do airdrop no Ethereum, com o id do mercado como payload. O keeper não indica nem o valor nem o destino: o adaptador de cada ação (setStockAdapter, que verifica que o adaptador transporta exatamente esse token) e o contrato do airdrop (setAirdrop) são designados no hub remoto pelo seu admin, o owner do StockFun. Uma ação listada duas vezes ou fora do basket faz a chamada falhar.

Desde 2026-10-06, o keeper indica o gas que cada entrega recebe no Ethereum: sendToAirdrop(stocks, receiveGas, composeGas), o lzReceive do OFT da ação além do que esse OFT impõe, e o compose do contrato do airdrop. O hub remoto limita cada valor entre o piso e o teto que o seu admin define, e zero assume o padrão (airdropGas), e o vault monta o envio e a sua cotação com o que o hub concede; a chamada só com as ações assume os dois padrões. O keeper escolhe os valores a partir de simulações da entrega no Ethereum (veja O keeper): a atualização Glamsterdam do Ethereum, ativa na Sepolia desde 2026-10-06, fez um novo slot de storage custar cerca de cinco vezes mais, e o número único de compose de antes, 600.000 de gas, deixou sem gas suficiente toda entrega do primeiro ciclo da execução em testnet com a LayerZero. Um hub remoto que recebeu upgrade de uma versão sem as políticas recusa todo envio e toda cotação (AirdropGasNotSet) até que as duas sejam definidas.

Desde 2026-10-05, cada ação vai isoladamente. Uma ação sem adaptador, uma cujo saldo não pode ser lido e uma cujo envio falha — um congelamento do emissor, um peer ausente, uma taxa que o pagamento do keeper não cobre — ficam no vault com um evento (AirdropSendFailed), e as outras vão; quando nada vai, a chamada falha e diz por quê. A cotação, quoteSendToAirdrop, deixa de fora o que não consegue precificar em vez de falhar.

A LayerZero transporta seis casas decimais: menos de 10^12 unidades de uma ação de 18 decimais, um milionésimo de token, não consegue atravessar e fica no vault para um envio posterior.

No Ethereum, o OFT da ação cunha a ação wrapped para o contrato do airdrop, e então o endpoint da LayerZero o chama com o payload. O contrato só credita a entrega se ela vier do seu endpoint, de um OFT de ação que o owner registrou, da Robinhood Chain, e se tiver sido enviada pelo vault espelho que o hub da bridge deriva para o mercado que o payload indica. Essa entrega roda com o gas que o envio levou (acima); uma entrega sem gas suficiente falha sem perder nada, armazenada no endpoint da LayerZero, com as ações wrapped já no contrato do airdrop quando só o compose falhou, e qualquer pessoa pode executá-la de novo com mais gas. Desde 2026-10-06, o keeper faz isso, a partir da sua própria chave, dentro de um limite, e alerta uma segunda falha. Detalhes e medições em Implantação e O airdrop.

Upgrades e conexões

Desde 2026-10-02, todo contrato do StockFun no trilho é upgradável, exceto o deployer dos vaults espelho, de cujo endereço é derivado o endereço de cada vault espelho. No Ethereum, o hub da bridge e os seus adaptadores respondem ao owner da factory. Na Robinhood Chain, o hub remoto é a autoridade de upgrade: ele responde com o seu admin de emergência, o owner do Ethereum tal como o último lote o levou, então o hub remoto, os vaults espelho, o router de ações e o oráculo recebem upgrade do owner do StockFun, com efeito imediato.

O hub remoto é implantado primeiro na sua chain, com um admin inicial, que depois designa o router de ações, o oráculo e a implementação dos futuros vaults espelho e, quando forem informados, a rota do airdrop e os adaptadores de ações. O primeiro lote substitui esse admin pelo owner do StockFun.

O mesmo admin detém os parâmetros do hub remoto, desde 2026-10-05: os registros que um sweep paga, 64 por padrão (setMaxRecordsPerSweep, nunca zero), o limite de preço das compras dos vaults espelho, e o gas de cada entrega do airdrop (setAirdrop); e, desde 2026-10-06, as duas salvaguardas do oráculo e as duas políticas de gas das entregas do airdrop no Ethereum, cada uma com um padrão, um piso e um teto (setAirdropReceiveGas, 650.000 entre 200.000 e 1.500.000; setAirdropComposeGas, 1.250.000 entre 600.000 e 4.000.000; um piso zero, um piso acima do teto e um padrão fora deles são recusados). O hub remoto define as duas na inicialização, e o DeployRemote as define de novo a partir do seu ambiente. Um oráculo substituto que o admin designe (setOracle) começa com as duas salvaguardas desligadas, então o admin as liga de novo para ele; os vaults espelho já inicializados mantêm o oráculo com que foram inicializados.

No Ethereum, o hub da bridge não implanta mais o seu adaptador: o adaptador é implantado apontando para o hub e depois designado uma única vez pelo owner do StockFun (setAdapter), que verifica as suas fixações. Uma substituição posterior, changeAdapter, é imediata desde 2026-10-05. Ela só aceita um adaptador cujas fixações sejam exatamente as do atual: o mesmo hub, a mesma factory, os mesmos tokens de caixa, o mesmo hub remoto, a mesma chain de destino e o mesmo transporte. Ela pode mudar valores de gas, opções ou o pool da Curve, nunca um destino; o hub remoto continua aceitando lotes apenas do adaptador para o qual foi construído (M-2, veja Modo de emergência). Por isso, um adaptador é trocado fazendo o seu upgrade no lugar, no mesmo endereço; um novo endereço exigiria antes um upgrade do hub remoto para aceitá-lo. Em 2026-10-05, o owner decidiu manter assim.

Os próprios números dos adaptadores também são parâmetros do owner do StockFun: no trilho do USDG, a pior taxa de USDG por USDC aceita na Curve, 30 pontos-base por padrão, e o gas do último passo da entrega na Robinhood Chain (setSettings); desde o décimo loop de auditoria, em 2026-10-06, esse gas é uma base de que todo lote precisa, 200.000 por padrão, mais uma parte para cada mercado do lote, 400.000 por padrão, e um lote leva no máximo 17 mercados (setBatchGas; veja "O gas de compose de um lote" abaixo). Até então, um único número, 1.200.000 por padrão, pagava todo lote, qualquer que fosse o seu conteúdo. No trilho canônico, o gas dos dois tickets (setTicketGas). Desde 2026-10-05, o ticket de contabilidade do trilho canônico paga o que a inbox da bridge cobra pelo tamanho do lote à taxa base atual, sendo o parâmetro o seu piso. Uma cotação lida offchain, sem preço de gas, enxergava uma taxa base nula e precificava esse ticket só pelo piso, então um lote longo falhava à taxa base real; desde o segundo loop de auditoria daquele dia, o keeper pede a cotação a uma taxa base que ele indica (quoteBridgeAt), o dobro da mais recente, e recebe o excedente de volta. Desde o quarto loop, o ticket de depósito é precificado da mesma forma: o que a inbox cobra por depositCalldataLength() bytes à taxa base, sendo o parâmetro tokenSubmissionCost o seu piso. Esse comprimento também é um parâmetro do owner (setDepositCalldataLength, nunca zero): 1.024 bytes por padrão, acima dos 740 bytes do depósito do gateway para USDC. Até então, o custo de submissão do depósito era um parâmetro fixo, e uma taxa base que o ultrapassasse fazia todo lote falhar.

Falhas que ficam contidas

Desde 2026-10-01, depois da auditoria de segurança de 2026-09-29:

• Um basket recusado só bloqueia o seu próprio mercado. Se a Robinhood Chain recusa o basket de um mercado, por exemplo uma ação que o seu router ou o seu oráculo não suporta, o vault espelho desse mercado continua não inicializado e guarda o seu caixa, que o modo de emergência pode recuperar. Os outros mercados do mesmo lote da bridge passam normalmente. Antes, o lote inteiro falhava, e qualquer pessoa podia agrupar mercados saudáveis com um mercado recusado.
• Um token remoto, um identificador. O hub da bridge se recusa a mapear um segundo identificador de basket para um token da Robinhood Chain que já está mapeado.
• Um hub remoto pausado continua aplicando os papéis. Cada lote leva o keeper e o admin de emergência atuais. Um hub pausado os aplica mesmo assim, então uma mudança de owner do StockFun sempre chega à Robinhood Chain. O caixa é registrado por mercado e pago aos vaults espelho por um sweep depois do fim da pausa.
• Os registros canônicos são pagos em ordem. Na bridge canônica do Orbit, usada em testnet e como fallback, os tokens e a contabilidade chegam em dois tickets separados. O hub paga os registros pendentes por inteiro, na ordem em que as suas mensagens chegaram, quem quer que acione o sweep. Desde o pipeline de segurança de 2026-10-01, um ticket de contabilidade paga no máximo tantos registros quantos acrescentou à fila, os mais antigos primeiro, e eles podem pertencer a lotes anteriores; o sweep paga o resto, até 64 registros por chamada por padrão. Antes, um acúmulo deixado por uma pausa ou por um depósito atrasado podia levar um ticket além do gas fixo da sua execução automática, e o lote ficava sem registro, a menos que alguém reexecutasse o ticket manualmente em até sete dias.

Uma falha só estava contida em parte. A segunda rodada da auditoria, em 2026-10-01, constatou que, se o token da perna de caixa recusar um vault espelho, por exemplo porque o seu emissor congelou esse endereço, a fila canônica fica paralisada e, nos dois trilhos, todo lote agrupado com esse mercado reverte (R2H-2). O segundo loop de auditoria de 2026-10-05 a mitigou, e o quarto a encerrou no mesmo dia: uma entrega assim agora espera isoladamente, e o lote continua (abaixo).

Desde 2026-10-05, depois do loop de auditoria daquele dia:

• Só o keeper envia pela bridge. O lote da bridge, bridgeReady, é exclusivo do keeper. Até então, qualquer pessoa podia enviar um: um terceiro podia inserir um lote, com o mínimo mais frouxo do adaptador, entre dois trades próprios no pool da Curve, ou fazer o lote do keeper falhar acionando antes o bridging de um dos vaults desse lote.
• No hub remoto, as contas de uma emergência são acertadas, não pagas por outro mercado. No trilho do USDG, o hub se recusa a pagar o que deve enquanto o caixa que o lastreia ficar aquém, uma contagem que ele mesmo mantém desde o segundo loop de auditoria daquele dia, nunca o seu saldo, que também inclui o caixa de lotes ainda a caminho; o caixa volta via restore. No trilho canônico, o owner do StockFun pausa o hub antes da transferência, remove o registro cujo caixa a emergência levou e então encerra a pausa. Veja Modo de emergência.

Desde o quarto loop de auditoria de 2026-10-05, que aplica a regra do fundador de que uma falha nunca bloqueia o resto (veja Arquitetura):

• Uma entrega recusada espera isoladamente. No trilho do USDG, a parte de um vault espelho que o token da perna de caixa recusa fica no hub remoto, devida a esse mercado e lastreada (DeliveryRefused), e os outros mercados do lote são pagos. No trilho canônico, um registro assim sai da fila e fica retido à parte para o seu mercado (undeliverable), de modo que os registros atrás dele e os próximos tickets são pagos. Nos dois, qualquer pessoa o paga com sweep(marketId) assim que o vault volta a aceitar o caixa. Desde 2026-10-06, o keeper, no trilho canônico, também encerra as transferências cujos registros recusados um único sweep pagou de uma vez, ou que o owner do StockFun imputou ao mercado, para que nenhuma fique sendo acompanhada para sempre.
• Cada mercado de um lote vai isoladamente. bridgeReady deixa de fora um mercado listado cujo vault não consegue liberar o seu caixa — pausado, vazio, recusado pelo emissor ou, desde o quinto loop, um vault ainda sem código, como o do mercado do protocolo antes de ser designado —, um mercado desconhecido ou um cujo payload o adaptador não consegue montar (MarketSkipped), e os outros vão. O mínimo do keeper cobre o lote tal como listado, e é reduzido na proporção do que realmente saiu; Bridged lista só os mercados que saíram. Um lote do qual nada sai falha, com o motivo do primeiro mercado.
• Cada perna da compra vai isoladamente, no vault espelho como no vault do Ethereum (LegFailed): veja O TreasuryVault.
• Uma transferência de emergência pode ser imputada a um único mercado. O owner do StockFun movimenta o caixa de um mercado e acerta as suas contas na mesma chamada, para que nenhum outro mercado espere: emergencyTransferFromPending retira o que o hub deve a esse mercado no trilho do USDG, ou a sua parte recusada no trilho canônico, e emergencyTransferRecord, um registro canônico na fila, inteiro. Desde o quinto loop, esta última serve para um registro cujo depósito já chegou: o caixa da fila é comum, então ela recusa um valor além do caixa não retido para partes recusadas (RecordNotCovered). Um registro cujo depósito se perdeu recebe baixa (writeOffRecord). No trilho do USDG, uma transferência não imputada a nenhum mercado mantém a sua espera geral, por design: as contas mostram um déficit até que o caixa seja reposto ou baixado.
• Um preço retido só segura as suas próprias pernas (desde 2026-10-06): uma ação em evento corporativo faz falhar só a sua própria perna, em todo vault espelho; com a verificação do sequenciador definida, uma queda do sequenciador segura todas as pernas até que ele esteja de volta há o período de carência, e o caixa espera nos vaults (acima, "Quando o oráculo retém um preço").

O gas de compose de um lote

Desde o décimo loop de auditoria, em 2026-10-06. O último passo de um lote da bridge na Robinhood Chain, o compose do hub remoto, inicializa e financia o vault espelho de cada mercado, então o seu gas cresce com o lote. Ele recebia um único número fixo, 1.200.000 por padrão, qualquer que fosse o conteúdo do lote: quatro novos mercados em baskets de cinco ações o esgotaram. O USDG deles ficou então no hub remoto sem nenhum registro, cada lote seguinte com os mesmos mercados falhou da mesma forma, e só uma execução à mão no endpoint da Robinhood Chain o destravou. Nada foi perdido, mas nenhum mercado do lote teve compras nem airdrop nesse meio-tempo.

• Uma base e uma parte por mercado. O adaptador do USDG dá a um lote de n mercados composeGas + n × composeGasPerMarket de gas de compose, 200.000 mais 400.000 por mercado por padrão, para o envio e para cada cotação igualmente. O primeiro lote de um mercado de cinco ações precisa de cerca de 294.000 de gas (extrapolado das medições com uma a três ações), e um mercado já configurado de 21.000 a 39.000, num fork da testnet da Robinhood Chain pelo próprio endpoint da LayerZero
• No máximo 17 mercados por lote. A LayerZero recusa uma mensagem acima do limite de tamanho da rota, 10.000 bytes por padrão, e cada mercado de cinco ações acrescenta no máximo 544 bytes à do lote: 17 mercados cabem, 18 não. Um lote maior é recusado inteiro antes que qualquer coisa se mova, cada vault mantendo o seu USDC. O keeper envia no máximo essa quantidade, primeiro os mercados que esperam há mais tempo, e os outros vão na sua próxima passagem, então nenhum espera para sempre. O trilho canônico não tem esse teto
• Dentro dos limites da Robinhood Chain. O gas de compose do maior lote é no máximo 24.000.000, abaixo dos 32.000.000 de gas que a Robinhood Chain executa numa transação; os parâmetros do owner não podem passar disso. Antes da mainnet, o owner lê o limite de tamanho da rota que o USDG da Paxos usa e ajusta o teto de acordo se ele for diferente
• Custa pouco. O executor da LayerZero cobra o gas extra ao preço do gas da Robinhood Chain: na testnet, a taxa de um lote cresce 0,00001 ETH por milhão de gas
• Um adaptador de antes recusa todo lote até que o owner defina os dois novos parâmetros, o que o seu upgrade faz na mesma transação. O adaptador da testnet recebeu upgrade dessa forma em 2026-10-06, e o seu lote seguinte foi composto pelo executor da LayerZero com a sua nova opção, 600.000 de gas para um mercado, 115.990 usados
• Um compose parado diz isso. O alerta do keeper para uma transferência não creditada a tempo agora lê a mensagem do lote no endpoint da Robinhood Chain: ainda não entregue lá; composta, com o crédito em seguida; ou armazenada, com o seu USDG no hub remoto, esperando ser executada de novo à mão com mais gas, o que qualquer pessoa pode fazer, e o alerta dá o hash da mensagem armazenada. O keeper continua sem executar ele mesmo um compose da bridge

O que foi verificado, e o que não foi

Primeiro, o estado atual. Nenhuma implantação na mainnet e nenhuma transferência de fundos reais aconteceu. Os testes locais simulam a entrega; não provam uma entrega real via LayerZero. Os envios do airdrop, codificados em 2026-10-04, são testados contra mocks da LayerZero e dos adaptadores de ações.

A execução em testnet com a LayerZero, 2026-10-06. O protocolo foi implantado na Sepolia e na testnet da Robinhood Chain (167 transações de implantação, todas bem sucedidas) e rodou de ponta a ponta sobre os endpoints, o DVN e o executor reais de testnet da LayerZero, das 13:50 às 19:07 UTC, pelo keeper, em sete janelas horárias: o ETH de cada janela convertido uma vez, enviado pela bridge num lote da LayerZero, processado por compose no hub remoto para o vault espelho e gasto nas três ações de teste. Seis ciclos do airdrop foram abertos, enviados de volta via LayerZero e processados por compose no contrato do airdrop; os quatro primeiros foram reivindicados por inteiro pelos cinco holders, o quinto em parte, o sexto ficou a reivindicar, cada pagamento exatamente a parte calculada de forma independente a partir do registrador de posições. Os exercícios de incidente (pausas, transferências de emergência e restore, rescue, um keeper interrompido com uma transação pendente, um compose executado à mão, um feed parado, uma ação pausada, a salvaguarda do sequenciador, uma entrega que o token da perna de caixa recusa) foram feitos sobre mensagens reais e recuperados como documentado, exceto duas metades: a pausa do hub da bridge na Sepolia, e um compose da bridge executado à mão. A Sepolia ativou a atualização Glamsterdam do Ethereum durante a execução: as primeiras entregas do airdrop ficaram sem gas no executor da LayerZero e foram executadas à mão, e a correção do gas da entrega (acima) foi aplicada por upgrade e conduziu os ciclos seguintes. O keeper foi reiniciado às 18:25 no código do nono loop de auditoria e executou a última janela sem problemas, com o gas que escolheu a partir das suas simulações.

O que essa execução não prova: o USDG da Paxos, cujo token de testnet não tem função OFT nessas testnets, então um USDG de teste sob o MintBurnOFTAdapter da LayerZero, no formato do par da mainnet, o substituiu, e nem os DVNs do par, nem o seu congelamento, nem a sua pausa foram exercitados; as ações da Robinhood e os seus adaptadores, substituídos por ações de teste sob o OFTAdapter da LayerZero; feeds de preço reais e liquidez real; o gas, as taxas e a finalidade da mainnet. Resta um teste na mainnet, um primeiro ciclo pequeno num vault de verificação.

Os scripts mais antigos de Sepolia usam a bridge canônica do Orbit e não validam a LayerZero. Um sucesso em fork, ou em testnet, não é prova de uma entrega real na mainnet.