Test e verifica

I livelli

Gli invarianti economici

Sono le uguaglianze che devono valere sempre:

1. Le quattro quote sommano esattamente la tassa prelevata, 500 punti base di default, senza perdere alcun wei
2. Nessuno può prelevare gli asset di un vault verso un indirizzo di sua scelta; le sole diminuzioni possibili sono la conversione, l'airdrop agli holder e il trasferimento di emergenza dell'owner
3. I pesi di un basket sommano al 100 % e non cambiano mai
4. Entrambe le posizioni vengono depositate alla creazione e possono essere rimosse solo dalla modalità di chiusura, 30 giorni dopo il suo annuncio
5. La liquidità è bloccata; la sua unica uscita è la modalità di chiusura, che l'owner annuncia con 30 giorni di anticipo
6. Il buyback di $STOCKFUN non può inviare i token acquistati altrove che al burn
7. La supply del creatore è zero su ogni mercato
8. Un vault può comprare solo gli asset del proprio basket
9. Un vault acquisisce solo ETH, USDC, USDG e le azioni del proprio basket, più rimborsi in USDon sul rail Ondo opzionale
10. Un ciclo dell'airdrop non paga mai più di quanto detiene, azione per azione, e nessun holder riceve più della propria quota pro rata; ciò che il contratto dell'airdrop deve, tra cicli e azioni messe da parte, non supera mai il suo saldo — requisito dal 2026-09-27, testato dal 2026-10-04 da un invariante con stato. Dal 2026-10-05, anche attraverso le emergenze, ciò che copre quei conti è sempre fatto di token che il contratto detiene davvero, mai di token non ancora accreditati, testato da un secondo invariante con stato
11. Solo il lock della liquidità aggiunge liquidità a un pool StockFun
12. Un trade non paga nessuno tranne il vault del mercato; le altre quote attendono sull'hook finché non vengono riscosse. Dal 2026-10-05 un vault che rifiuta la propria quota ne diventa creditore sull'hook, e il trade prosegue
13. Ogni azione del basket spende solo il cash che le è riservato

Sono verificati sulle implementazioni attuali; un upgrade sostituisce il codice su cui vengono verificati.

Il vincolo di dimensione

Il limite EIP-170 è di 24.576 byte di codice runtime. È imposto da un test che fa fallire la suite di test, non da un'ispezione manuale.

Qui è un vincolo reale: la factory ha dovuto essere divisa. Fino al 2026-10-02 il deployer dei vault, che incorporava il creation code di un TreasuryVault, era il contratto più vicino al tetto, e ogni riga aggiunta al vault veniva sottratta a quel margine. La rimozione del buyback del creatore, il 2026-09-28, lo ha portato da 23.055 a 14.965 byte; le correzioni del 2026-10-01, che riservano il cash azione per azione, lo hanno portato a 15.954. Dal 2026-10-02 fa il deploy di un proxy, e ciò che deve stare sotto il limite è l'implementazione di ogni modulo.

Il 2026-10-05 il contratto dell'airdrop è diventato il più vicino al tetto. Le riscossioni del quarto ciclo di audit lo hanno portato oltre il limite; rendere private alcune delle sue funzioni di lettura ed eliminare i suoi trasferimenti di emergenza imputati a un solo ciclo lo hanno riportato a 24.432 byte, 144 sotto il tetto.

Dopo l'audit del 2026-09-29

Ogni rilievo corretto dopo l'audit di sicurezza del 2026-09-29 ha dei test di regressione che falliscono sul codice sottoposto ad audit; la maggior parte sono le proof of concept dell'audit, invertite per verificare il comportamento dopo la correzione.

La pipeline di sicurezza del 2026-10-01

Un secondo round di audit, da parte di due auditor indipendenti, poi di nuovo ogni verifica sul codice corretto. Ognuna delle sue correzioni ai contratti e al keeper ha dei test di regressione. Il 2026-10-01, dopo quelle correzioni:

• Foundry. Passano i 421 test al di fuori delle suite di fork, e anche il profilo approfondito: 20.000 run di fuzz, invarianti a 512 run di profondità 128. Le suite di fork non sono state eseguite: non era disponibile alcun URL RPC.
• Test di mutazione. slither-mutate è stato eseguito su cinque contratti: il distributore delle commissioni, il registro della detenzione, il vault della tesoreria, lo stock router di Robinhood Chain e l'hub remoto. Ha generato 1.301 mutanti, piccole modifiche deliberate al codice, e i test ne hanno intercettati 1.118. Dei 183 sopravvissuti, 107 sono equivalenti al codice originale: nessun input può distinguerli. Gli altri 76 hanno mostrato controlli che i test non facevano; ora i test li coprono tutti. Nessun mutante ha rivelato un bug.
• Verifica formale. Ogni job Certora è stato eseguito di nuovo sul prover, sul codice corretto (certora-cli 8.8.1, sanity check di base). Nessuna regola è stata violata. Sette regole del LiquidityLock restano indecise su un metodo, lockProtocolLiquidity: hanno superato il tempo limite, e una nuova esecuzione con un limite più lungo si è conclusa senza verdetto. Valgono su tutti gli altri metodi; quel metodo è riservato all'owner, viene eseguito una sola volta, per $STOCKFUN, e i test Foundry ne coprono l'accesso, l'uso unico e la forma del lock. Gli altri risultati non verificati sono casi noti di vacuità: una regola eseguita su ogni metodo, per un metodo che non può mai riuscire nel setup verificato. I fallimenti della prima esecuzione del TreasuryVault derivavano da due artefatti della specifica, nessuno dei quali era un bug; la specifica è stata corretta.
• Fuzzing ed esecuzione simbolica. Medusa ha eseguito cinque proprietà del registro della detenzione per dieci minuti, senza alcun fallimento. La sua prima esecuzione ha rilevato che su una chain il cui orologio parte dall'ora 0, una chain di test, mancava il primo punto orario della supply registrata; nessuna chain reale ne era interessata, e il token ora registra quel punto al deploy. Halmos supera tre verifiche simboliche per ogni input entro i limiti: la ripartizione della commissione è esatta, la supply registrata segue due trasferimenti qualsiasi, e il suo integrale all'ora successiva è corretto. Mythril non riesce a esplorare i contratti del protocollo al di fuori di un deploy, circa il 14 % di copertura; sul registro della detenzione, che è autonomo, ha raggiunto il 31 % in 15 minuti e non ha segnalato nulla.
• Analisi statica. Slither, Aderyn e Solhint non hanno trovato nulla di nuovo.
• Su una chain locale nuova. Passano un deploy completo, un vero ciclo del keeper e dieci casi d'uso. La prova generale del deploy, gli script di produzione eseguiti nell'ordine del runbook, passa dopo la correzione di uno script: lo script del rail mock coniava i propri fondi iniziali a favore del mittente predefinito di forge invece che della chiave che esegue il deploy.

Quell'esecuzione ha verificato anche 11 regole di TeamVesting, un contratto eliminato con la sua specifica il 2026-10-05. Il prover non copre il lato Robinhood Chain: l'hub remoto, i vault speculari e lo stock router.

La riprogettazione upgradabile del 2026-10-02

La riprogettazione che ha reso i moduli upgradabili è arrivata dopo tutte le verifiche qui sopra. Il 2026-10-02, sul nuovo codice:

• Foundry. Passano i 458 test al di fuori delle suite di fork. Nuove suite coprono gli upgrade, su Ethereum e su Robinhood Chain — chi può fare l'upgrade, l'autorità e il PoolManager che una nuova implementazione deve mantenere, i vault uno per uno — e la modalità di chiusura. La suite del registro della detenzione si è spostata con il registro, nel registratore della detenzione.
• Layout dello storage. Il layout dello storage di ogni modulo upgradabile è registrato in contracts/storage-layouts/, e contracts/script/check-storage-layouts.sh fallisce su qualsiasi modifica che non sia un'aggiunta. È pensato per essere eseguito prima di ogni upgrade. Dal 2026-10-05 controlla ogni livello di ogni struct: vedi Deploy.
• Su una chain locale nuova. Lo script LocalRun passa.
• Verifica formale. Le specifiche Certora sono in corso di adeguamento al nuovo codice. La loro ultima esecuzione completa sul prover, il 2026-10-01, precede la riprogettazione: la tabella qui sopra descrive quell'esecuzione.

Il profilo approfondito, i test di mutazione, il fuzzing e l'esecuzione simbolica e l'analisi statica descritti sopra sono stati eseguiti il 2026-10-01, sul codice precedente alla riprogettazione.

L'airdrop del 2026-10-04

Il contratto dell'airdrop e i due percorsi sendToAirdrop, implementati il 2026-10-04, non deployati. Quel giorno, sul nuovo codice:

• Foundry. Passano i 514 test al di fuori delle suite di fork, contro i 459 prima dell'airdrop. Tre nuove suite: AirdropDistributorTest, 38 test; AirdropCrossChainTest, 15, con LayerZero sostituito da mock; AirdropInvariantsTest, 2, attorno a un invariante con stato: conservazione e solvibilità su due mercati sotto sequenze casuali di invii, riscossioni, collocamenti, aperture e cambi delle esclusioni e dell'ora del ciclo, 128 run da 64 chiamate. Un fuzz del calcolo delle quote gira 512 volte.
• Gas. Riscuotere un ciclo di due o tre azioni costa all'incirca da 120.000 a 210.000 gas secondo le misure dei test, che girano con lo storage caldo: una transazione reale costa un po' di più. Una consegna da Robinhood Chain costa circa da 85.000 a 1.016.000 gas su Ethereum, misurati a freddo: vedi Deploy.
• Su una chain locale. Su Anvil, LocalRun e poi LocalAirdrop: due holder, azioni messe da parte prima delle 13:00 UTC, poi collocate e riscosse dopo. Ogni riscossione è esattamente la parte intera della sua quota, con 1 wei di polvere per azione.
• Verifica formale. Le cinque specifiche Certora che toccano i contratti modificati superano il controllo dei tipi. Il prover non è stato eseguito, e nessuna specifica copre il contratto dell'airdrop.
• Offchain. Passano i 93 test del keeper, i 43 del pacchetto condiviso, i 9 del backend e i 58 del worker.
• Revisioni. Codex (gpt-6-astra) ha esaminato il design, poi il codice: un Medium, sui tempi delle azioni messe da parte, e un Low, sullo script locale, entrambi corretti. Una nuova revisione delle correzioni ha trovato un Medium, sui tempi delle modifiche alle esclusioni, e un Low, sull'ordine dello script locale, entrambi corretti: una finestra viene misurata rispetto alla lista di esclusione in vigore alla sua chiusura, e lo script colloca per prime le azioni messe da parte. Un controllo finale di queste due correzioni non ha trovato alcun bug, entro la garanzia dichiarata: le azioni messe da parte vanno alla prima finestra con detenzioni idonee chiunque chiami e in qualunque momento, purché nel frattempo l'ora del ciclo non cambi e il registratore della detenzione del token non venga sostituito. I report sono in projet/docs/audit-2026-10-04/.

Le modifiche del 2026-10-05

Nessuna allocazione al team, una modalità di emergenza immediata e ogni numero un'impostazione dell'owner, implementati il 2026-10-05, non deployati. Quel giorno, sul nuovo codice:

• Foundry. La suite passa, 520 test. Due nuove suite, Settings e SettingsCrossChain, coprono ogni impostazione: chi può impostarla, i valori che rifiuta, e l'operazione successiva dopo un cambio — tra queste la tassa e l'anti-snipe, la forma del lancio, ogni pool che mantiene la propria chiave, e le quote di ciò che incassano le posizioni bloccate. Le proprietà delle commissioni, con fuzzing ed esecuzione simbolica, valgono per qualsiasi impostazione accettata. I test di emergenza seguono il trasferimento immediato, e i test del contratto di vesting sono stati eliminati con esso.
• Gas. Leggere le impostazioni della tassa costa a uno swap circa 1.200 gas in più, a caldo.
• Verifica formale. Le specifiche delle commissioni, dell'hook, del lock, della factory, dei token e dell'oracolo seguono le impostazioni e superano il controllo dei tipi in locale. Il prover non è stato eseguito.

I cicli di audit del 2026-10-05

Lo stesso giorno, cinque cicli di revisione hanno esaminato il codice, non deployato; dal quarto, una violazione della regola del fondatore secondo cui un guasto non blocca mai il resto conta come un difetto (vedi Architettura). Ogni correzione ha un test di regressione. Sul codice di ogni ciclo:

• Foundry. Passano 602 test dopo il quarto ciclo e 613 dopo il quinto; a fine giornata ne passano 614, con tre suite di fork saltate in assenza di un RPC. Ogni contratto sta sotto EIP-170, e i layout dello storage sono cresciuti solo dove una correzione ha aggiunto stato in coda.
• Invarianti. Gli invarianti dell'airdrop superano 512 esecuzioni di profondità 128 con il profilo profondo, dopo il terzo ciclo. Un secondo invariante con stato porta l'airdrop attraverso le emergenze: consegne il cui ultimo passo viene eseguito in ritardo, token dispersi, trasferimenti in uscita, ripristini, svalutazioni e pause e, dal quinto ciclo, azioni congelate dal loro emittente e claimMany.
• Verifica formale. I cicli hanno aggiunto regole sull'hook (i suoi debiti verso i vault, ciò che vi è disperso), sul lock (le quote che conserva, i suoi rescue), sul burner e sui token (i loro rescue), e una regola secondo cui solo l'owner del protocollo esegue rescue sui router, sull'oracolo e sulla factory: 213 regole e invarianti in 11 specifiche dopo il quarto ciclo, una in più sui rescue dei token dopo il quinto. Ogni specifica toccata supera il controllo dei tipi in locale; nulla è stato inviato al prover, la cui ultima esecuzione resta quella del 2026-10-01.
• Offchain. Dopo il passaggio dell'airdrop nel keeper, la schermata di riscossione della dapp e il passaggio offchain del quarto ciclo: passano i 191 test del keeper, i 51 del pacchetto condiviso, i 9 del back end e i 90 del worker, e l'app supera il suo controllo dei tipi e il suo lint.
• Su una chain locale. Su Anvil, LocalRun, poi il keeper, il motore del worker e la preparazione delle riscossioni dell'app: nella finestra del deploy il keeper non ha inviato nulla; nella successiva ha aperto due cicli e inviato le azioni di due vault, e un claimMany ha pagato cinque azioni sui due cicli, a circa 421.000 gas, dopo di che claimable indicava zero.

Il passaggio offchain del quinto ciclo, 2026-10-06

La revisione del keeper, del worker, dell'app e degli script nel quinto ciclo ha trovato tre problemi di gravità media e sedici di gravità bassa, ciascuno corretto con un test di regressione, non deployato. Eseguito il 2026-10-06:

• Foundry. Passano 619 test sul codice di quel giorno, con tre suite di fork saltate in assenza di un RPC: i nuovi campi della Lens, il tetto di cinque azioni per basket e il lancio ripreso di $STOCKFUN hanno i loro test. I layout dello storage non sono cambiati.
• Offchain. Passano i 210 test del keeper, i 51 del pacchetto condiviso, i 9 del back end e i 111 del worker; i test di ogni correzione del keeper falliscono quando la correzione viene rimossa. L'app supera il suo controllo dei tipi e il suo lint; non ha un test runner, e la sua preparazione delle riscossioni è passata nel motore del worker, i cui test la coprono.
• Su una chain locale. Una prova generale su un Anvil privato ha superato i suoi sei scenari: LocalRun, il cui dry run non scrive alcun file di deploy; il keeper su due finestre, che converte l'ETH di ogni vault una volta per finestra, poi colloca, apre e invia l'airdrop una volta, ogni riscossione esatta al wei; un vault che rifiuta ETH, con i suoi debiti sull'hook e sul lock pagati una volta ripristinato; interruzioni a metà operazione con il file di stato e il suo lock, nulla inviato due volte, una transazione sostituita e una scartata gestite; i rescue e un incasso giornaliero delle commissioni LP. Il rail del bridge, l'app e il worker non ne facevano parte.

Dopo la prova generale, 2026-10-06

I rilievi della prova generale sono stati corretti lo stesso giorno, non deployati. Il keeper colloca le azioni che il contratto dell'airdrop tiene da parte per un mercato anche quando il suo vault non ha nulla di nuovo da inviare, e registra un vault trovato sotto la soglia in base alla finestra per cui è stato controllato, mai in base al proprio orologio; conta a parte un invio messo da parte, lascia stare le poche unità di USDC che l'ultima tratta d'acquisto di un vault non può mai spendere, e mostra gli id dei pool nel suo log. La prima area del sesto ciclo di revisione non ha trovato nulla nei contratti e un problema di gravità bassa in uno script locale, corretto: il file di deploy locale viene verificato rispetto alla chain prima che il keeper, l'app o il worker lo usino. Su quel codice:

• Foundry. Passano 620 test, con tre suite di fork saltate in assenza di un RPC: uno in più, un lancio ripreso di $STOCKFUN che ha rifiutato un vault che detiene le azioni di un altro basket
• Offchain. Passano i 218 test del keeper, i 51 del pacchetto condiviso, i 9 del back end e i 111 del worker; i test di ogni correzione del keeper falliscono sul keeper precedente. Il controllo del file di deploy locale non ha un test automatizzato: è stato eseguito a mano su un Anvil privato, dove ha accettato un deploy nuovo e rifiutato un file con i ruoli di due contratti scambiati

Dopo il sesto e il settimo ciclo di audit, 2026-10-06

Le correzioni del keeper e del worker del sesto ciclo e quelle del settimo sono state fatte lo stesso giorno, non deployate; in nessuno dei due è cambiato il codice di alcun contratto, ed è stato corretto solo un commento di un contratto. Eseguito il 2026-10-06, sul commit 415dcae (i contratti da una copia pulita di quel commit, dato che era in corso altro lavoro sui contratti):

• Foundry. Passano 620 test: 615 fuori dai file di fork, e i cinque della suite di fork di Robinhood Chain contro il suo RPC pubblico; le tre suite di fork di Ethereum vengono saltate in assenza di un RPC. Lo stesso conteggio di dopo la prova generale: nessun test dei contratti è cambiato
• Offchain. Passano i 277 test del keeper, i 51 del pacchetto condiviso, i 9 del back end e i 137 del worker, in 11 file. Ogni proof of concept del settimo ciclo è un test di regressione, e i nuovi test di ogni correzione falliscono sul codice precedente a essa, tranne i pochi che fissano ciò che il vecchio codice già faceva (un invio che il keeper non riesce a valutare parte come prima; un vecchio file di stato si carica) e quelli del grafico, le cui funzioni sono nuove. Un file di stato scritto dal keeper prima del sesto ciclo è conservato come fixture di test e si carica con il nuovo keeper
• L'app. Supera il suo controllo dei tipi, il suo lint e la sua build, e il suo grafico dimostrativo prerenderizzato occupa tutta l'area del grafico; non ha un test runner, e non è stato eseguito alcun test nel browser. Il posizionamento del grafico esegue codice del motore del worker, che i test del worker coprono

Le protezioni dei feed di prezzo e l'ottavo ciclo di audit, 2026-10-06

Le due protezioni dei feed di prezzo dell'oracolo per Robinhood Chain sono state scritte il 2026-10-06, e le correzioni del keeper, del worker e dell'app dell'ottavo ciclo lo stesso giorno, non deployate. I contratti sono cambiati con le protezioni, non con il ciclo. Eseguito il 2026-10-06, sul commit 6586d40 (i contratti da una copia pulita di quel commit, dato che era in corso altro lavoro sui contratti):

• Foundry. Passano 640 test: 633 fuori dai file di fork, in 82 suite, e i sette del file di fork di Robinhood Chain contro il suo RPC pubblico; le tre suite di fork di Ethereum vengono saltate in assenza di un RPC. Le protezioni hanno aggiunto 18 test fuori dai file di fork: 16 sul solo oracolo, con feed e token mock (ogni protezione disattivata, poi attivata, ogni modo in cui un feed o un token può non rispondere, ogni risposta che conta come pausa, una lettura privata di gas, le impostazioni dell'owner e i rifiuti dello script di deploy), e 2 sul rail cross-chain (la tratta di un'azione in pausa fallisce da sola e compra una volta tolta la pausa; un'interruzione del sequencer ferma ogni tratta finché non termina il suo periodo di grazia). I due nuovi test di fork leggono i veri token delle azioni: ciascuno dei venti risponde al segnale di pausa come lo legge l'oracolo, la lettura più costosa ha richiesto 13.288 gas, e un token messo in pausa dove il suo vero codice tiene il flag trattiene solo il proprio prezzo
• Storage e specifiche. I layout dello storage dei 17 moduli upgradabili sono invariati, salvo l'aggiunta in coda dell'oracolo; la specifica formale dell'oracolo, 25 regole e invarianti, supera il controllo dei tipi, senza alcuna esecuzione sul prover
• Offchain. Passano i 306 test del keeper, i 51 del pacchetto condiviso, i 9 del back end e i 155 del worker, in 12 file. Ogni proof of concept dell'ottavo ciclo è un test di regressione, e i nuovi test di ogni correzione falliscono sul codice precedente a essa, tranne quelli di funzioni che sono nuove
• L'app. Supera il suo controllo dei tipi, il suo lint, il controllo del suo motore e la sua build; non ha un test runner, e non è stato eseguito alcun test nel browser. Il controllo del basket del suo modulo di lancio e la tassa del suo pannello di trading eseguono codice del motore del worker, che i test del worker coprono

Il nono ciclo di audit, Glamsterdam e l'esecuzione su testnet con LayerZero, 2026-10-06

Le correzioni del nono ciclo, il gas della consegna dell'airdrop con l'aggiornamento Glamsterdam di Ethereum e la riesecuzione da parte del keeper di una consegna bloccata sono state fatte il 2026-10-06, non deployate sulla mainnet. Una modifica dei contratti (le politiche di gas dell'hub remoto e l'invio e la quotazione a tre argomenti del vault speculare) è arrivata con esse, testata da nove nuovi test del rail cross-chain (i default rispetto alle misure, il limite a entrambi gli estremi, le opzioni dell'invio e la quotazione che corrisponde a esse, le forme a un solo argomento, i rifiuti dei setter, una consegna più pesante del gas che impone il suo OFT, un hub senza politiche che tiene le azioni a casa, le opzioni byte per byte) e da quattro dello script di deploy. Il mock dell'OFT delle azioni ora somma le opzioni di gas e lascia una consegna rimasta senza gas in attesa di un'esecuzione con più gas, come fa l'endpoint di LayerZero. Da questo ciclo un secondo agente rivede la modifica di ogni correzione prima che venga inviata al repository (il gate di verifica), e i suoi rilievi vengono corretti e testati allo stesso modo. Eseguito il 2026-10-06, sul commit 92a1904 (i contratti da una copia pulita di quel commit, dato che era in corso altro lavoro):

• Foundry. Passano 653 test: 646 fuori dai file di fork, in 83 suite, e i sette del file di fork di Robinhood Chain contro il suo RPC pubblico; le tre suite di fork di Ethereum vengono saltate in assenza di un RPC. Foundry usa la tabella del gas di Cancun: le sue cifre di gas sono i prezzi vecchi, e quelli nuovi vengono da Sepolia
• Storage. I layout dello storage dei 17 moduli upgradabili sono invariati, salvo l'aggiunta in coda dell'hub remoto (le sue politiche di gas, slot da 21 a 23)
• Offchain. Passano i 370 test del keeper, i 51 del pacchetto condiviso, i 9 del back end e i 189 del worker, in 14 file (i 372 del keeper a e1dd5f6, dopo l'ultima correzione del gate, gli altri invariati); il keeper e il worker superano il loro controllo dei tipi. I nuovi test di ogni correzione falliscono sul codice precedente a essa, tranne quelli di funzioni che sono nuove. Il nuovo limite di gas per scrittura dell'app esegue codice del motore del worker, che i test del worker coprono
• L'app. Supera il suo controllo dei tipi, il suo lint e il controllo del suo motore; non ha un test runner. Le sue altre due correzioni, il piatto contrassegnato come stima e l'approvazione che non si è potuta leggere, sono state verificate eseguendo il suo stesso codice in una copia di lavoro
• Su Sepolia, dopo Glamsterdam. Ogni cifra di gas fissa dei contratti e degli script è stata misurata di nuovo sulla chain reale: tutte reggono, con margine, tranne le due della consegna dell'airdrop, corrette dalle politiche di gas. Il decimo ciclo di audit ne ha trovate altre due: il gas proprio degli script di deploy, che forge prende dalla propria simulazione ai prezzi vecchi (ogni trasmissione ora prende la stima del nodo), e quello del compose del bridge, dimensionato per un mercato e non per un batch. Il preflight del keeper, eseguito in sola lettura sul deploy dell'esecuzione su testnet con LayerZero, supera le sue 68 verifiche
• L'esecuzione su testnet con LayerZero. Il protocollo ha girato da un capo all'altro su Sepolia e sulla testnet di Robinhood Chain sugli endpoint, sul DVN e sull'executor reali di testnet di LayerZero, sette finestre orarie e sei cicli dell'airdrop, ogni riscossione esattamente la quota calcolata dal registratore della detenzione: vedi Il rail Robinhood. La sua ultima finestra ha girato sul keeper del nono ciclo, con il gas delle consegne scelto dalle sue simulazioni

Il decimo ciclo di audit, 2026-10-06

Le correzioni del decimo ciclo sono state fatte il 2026-10-06, non deployate sulla mainnet, ciascuna rivista da un secondo agente prima di essere unita. È cambiato un contratto, l'adapter del bridge USDG: l'ultimo passo di un batch del bridge su Robinhood Chain riceve ora una base più una parte per mercato, e un batch porta al massimo 17 mercati. Lo coprono nove nuovi test: quattro nuovi mercati a cinque azioni, un batch pieno di 17 e trenta mercati inviati come due batch, ciascuno eseguito a freddo con esattamente il suo gas; 18 mercati rifiutati per la dimensione del loro messaggio; la commissione che cresce con il batch; un batch oltre il tetto rifiutato per intero mentre il successivo passa; un adapter configurato prima delle nuove impostazioni che non fa passare nulla dal bridge finché non sono impostate; e i limiti delle impostazioni. Il mock del bridge del token USDG ora rifiuta un messaggio oltre il limite di dimensione di LayerZero e prezza il gas, come fa LayerZero. La procedura di deploy non ha test: la sua modifica è stata eseguita su Sepolia, dove una creazione inviata con il gas proprio dello strumento di deploy è rimasta senza gas, e le stesse creazioni inviate con la stima del nodo sono passate. Eseguito il 2026-10-07, sul commit 5ea8bf0 (i contratti da una copia pulita di quel commit):

• Foundry. Passano 662 test: 655 fuori dai file di fork, in 84 suite, e i sette del file di fork di Robinhood Chain contro il suo RPC pubblico; le tre suite di fork di Ethereum vengono saltate in assenza di un RPC. Passano i 2 test del progetto dell'esecuzione su testnet con LayerZero, sui contratti di LayerZero stessi
• Storage. I layout dello storage dei 17 moduli upgradabili sono invariati, salvo l'aggiunta in coda dell'adapter del bridge (le sue due impostazioni di batch)
• Offchain. Passano i 400 test del keeper, i 51 del pacchetto condiviso, i 9 del back end e i 210 del worker, in 15 file; il keeper e il worker superano il loro controllo dei tipi. La proof of concept di ogni revisore è un test di regressione, e i nuovi test di ogni correzione falliscono sul codice precedente a essa, tranne quelli di funzioni che sono nuove. Il tracciamento da parte dell'app di una transazione che il wallet annulla o sostituisce, e le sue letture a un blocco non anteriore a quello della sua ultima transazione, eseguono codice del motore del worker, che i test del worker coprono
• L'app. Supera il suo controllo dei tipi, il suo lint e il controllo del suo motore; non ha un test runner
• Sulle testnet. L'adapter del bridge dell'esecuzione su testnet con LayerZero è stato aggiornato su Sepolia il 2026-10-06, e il suo batch successivo, un mercato, è stato consegnato e composto dall'executor di LayerZero con il suo nuovo gas, 600.000, di cui 115.990 usati

Cosa i test non dimostrano

È importante, e i report del progetto stesso lo dicono chiaramente.

I test locali simulano la consegna cross-chain. Non dimostrano una vera consegna LayerZero. I test cross-chain dell'airdrop girano contro mock di LayerZero e degli adapter delle azioni, che non sono nel repository per la mainnet. Le suite di fork sono state escluse da almeno un'esecuzione perché gli endpoint pubblici restituivano errori HTTP — e quel report lo dice, invece di presentare le suite come superate.

L'esecuzione su testnet con LayerZero del 2026-10-06 ha portato veri messaggi LayerZero tra due testnet, con azioni di test, adapter di test, un USDG di test e feed simulati: dimostra il codice di StockFun sul trasporto di LayerZero, non la coppia USDG di Paxos, le azioni di Robinhood e i loro adapter, feed e liquidità reali, o il gas, le commissioni e la finalità della mainnet.

Nessuna esecuzione dimostra: il trasporto LayerZero sulla mainnet, una revisione esterna, o una prova formale che copra il rail attuale. L'esecuzione su testnet ha firmato con wallet reali, tre delle sue riscossioni tramite l'app.

In locale

Lo scenario completo gira in quattro terminali: la chain, il deploy e la simulazione, il servizio prezzi, la dapp. Poi il keeper e l'harness del browser.

La procedura esatta è in projet/docs/LOCAL_TESTING.md.