Registro delle decisioni

Il registro canonico è doc/DECISIONS.md. Questa pagina riassume i punti di svolta.

2026-08-25 — Revisione di sicurezza interna

Un rilievo di gravità alta: le esecuzioni parziali lasciavano ETH e USDC bloccati nei router, interamente tassati. Corretto rifiutando le esecuzioni parziali invece di gestirle.

2026-08-27 — La commissione passa dal 4 % al 5 %

La quota del creatore raddoppia, dall'1 % al 2 %. Lo schema di $STOCKFUN passa da 2 / 1,5 / 0,5 a 2 / 2,5 / 0,5. La quota della tesoreria resta al 2 %, ed è il numero che non cambia mai.

Conseguenza accettata: l'andata e ritorno passa dal 7,84 % al 9,75 %. Dal 2026-10-05 l'aliquota e la sua ripartizione sono impostazioni dell'owner, e questi valori sono quelli di default.

2026-08-27 — Il buyback del creatore

Toglie l'esclusione "nessuna uscita" su un unico percorso, che finisce sempre al burn. Il Treasury Ratio può ora scendere a discrezione di un creatore. Rimosso il 2026-09-27, sostituito dall'airdrop.

2026-08-29 — Modalità di emergenza

L'owner può spostare gli asset di una tesoreria dopo 48 ore di attesa pubblica. Sostituisce la promessa "nessuno può toccare la tesoreria". Il protocollo smette di essere descritto come trustless. Immediata dal 2026-10-05: il periodo di attesa non esiste più.

2026-09-11 — Il rail passa a Robinhood Chain

L'ostacolo era l'idoneità di un contratto vault presso un emittente a mint primario, mai documentata pubblicamente. I pool secondari di Robinhood Chain non la richiedono. Prezzo pagato: una dipendenza cross-chain accettata.

2026-09-12 — La bonding curve viene eliminata

Sostituita da due posizioni Uniswap v4 single-sided, bloccate dalla creazione. Nessuna graduation, nessuna migrazione, nessuna commissione di graduation.

La FDV di lancio non cambia: resta quella a cui apriva la curva, 3,409 ETH. Un primo ticket da 2 ETH prende il 36,06 % della supply contro il 36,99 % di prima — il lancio si comporta come prima, a meno di un punto.

Scartati lungo il percorso: un lancio a $5.000 con un tetto a $50.000, che dava solo 3,25 ETH di profondità e permetteva al primo acquirente da 2 ETH di prendere il 57 % della supply. E l'idea che un tetto più basso avrebbe calmato il mercato — passa prima il testimone alla banda senza limite, che è sottile, e raddoppia la FDV raggiunta dopo 50 ETH di spesa.

2026-09-12 — Anti-snipe in tre blocchi

Solo il creatore nel blocco 1, 99 % al buyback nel blocco 2 tranne il creatore e la whitelist dell'owner, normale in seguito. Sostituito il 2026-09-28 dall'anti-snipe decrescente.

Presa con piena consapevolezza dell'obiezione: una tassa del 99 % produce qualcosa solo se qualcuno perde i propri soldi, e chiudere il blocco 2 avrebbe avuto lo stesso effetto deterrente senza vittime. La whitelist sta a livello di protocollo anziché di creatore, proprio perché non possa diventare un vantaggio da insider, mercato per mercato.

2026-09-12 — Nessun burn sulle vendite

L'idea di inviare al burn il 10 % dei token in entrata a ogni vendita è stata abbandonata. Pagata dal venditore, portava l'andata e ritorno al 18,78 %. Pagata dall'LP, rendeva falso "liquidità bloccata per sempre" e dava a chiunque una leva di circa 1:1 per bruciare il flottante e pompare la propria bag.

2026-09-27 — L'airdrop sostituisce il buyback del creatore

La tesoreria di un mercato ha ora un solo uso: il 100 % delle azioni che compra viene distribuito in airdrop agli holder del suo token, pro rata, in natura, su Robinhood Chain. Il buyback del creatore è rimosso, e con esso il percorso inverso del bridge. Il buyback e burn di $STOCKFUN resta.

Scartati lungo il percorso: mantenere il buyback del creatore, e una ripartizione che teneva il 60 % nella tesoreria e ne distribuiva il 40 %, il vecchio piano V2. Conseguenze accettate: nessuna tesoreria si accumula più, il Treasury Ratio perde il suo significato, e slogan e tagline sono da rivedere. Il meccanismo è stato implementato il 2026-10-04: vedi L'airdrop.

2026-09-27 — Un ciclo ogni 24 ore

La cadenza dell'airdrop è fissata lo stesso giorno. Una volta ogni 24 ore, per ogni mercato la cui tesoreria ha accumulato almeno 0,1 ETH, il keeper converte, esegue il bridge, compra le azioni, poi le distribuisce in airdrop. Sotto la soglia, quel giorno non succede nulla; l'ETH attende.

Le azioni si possono comprare solo quando la borsa USA è aperta, quindi non c'è alcun ciclo nel fine settimana né nei giorni festivi del NYSE. Nel codice del keeper, fino al 2026-10-06 la conversione avveniva durante la sessione, al primo giro in cui il vault deteneva la soglia; da allora segue questa decisione, una volta per finestra, al primo giro del keeper dopo la chiusura della finestra e solo se il vault detiene la soglia in quel momento (vedi 2026-10-06 sotto); dal sesto ciclo di audit, lo stesso giorno, anche l'USDC che un vault detiene segue questa cadenza. L'invio all'airdrop avviene una volta per finestra dal 2026-10-05, dopo la sessione del giorno: vedi Il keeper.

2026-09-27 — Fondi bloccati e misurazione della detenzione

I residui di un ciclo interrotto completano il percorso al ciclo successivo, che la soglia sia raggiunta o no. I fondi dell'airdrop rimasti bloccati per 24 ore in un vault speculare possono essere spostati dall'owner senza preavviso: l'unica eccezione al periodo di attesa pubblico di 48 ore, scelta consapevolmente. La detenzione viene misurata come saldo medio nelle 24 ore precedenti il ciclo, anche il lunedì. La finestra dei fondi bloccati è passata a 48 ore il 2026-09-28, e la regola è stata chiusa il 2026-10-05, senza essere mai implementata.

2026-09-28 — Anti-snipe decrescente

80 % nel blocco di apertura, meno 8 punti per blocco, 5 % dall'11° blocco, su acquisti e vendite. L'eccedenza va alla tesoreria del mercato, o alle commissioni del team da riscuotere su $STOCKFUN. Esenti: l'acquisto di lancio del creatore e una whitelist stabilita dal creatore, fissata nella transazione di creazione, pubblica, immutabile e con un tetto di 20 indirizzi; su $STOCKFUN, stabilita dall'owner al lancio. Dal 2026-10-05 questi numeri sono impostazioni dell'owner, e i valori qui sopra sono quelli di default.

Scartato lungo il percorso: marcare i wallet che comprano nei primi blocchi e tassarne le vendite successive, anche dopo un trasferimento. Un pool v4 non vede il wallet, una tassa prelevata dal token fa fallire la vendita, e bloccare i wallet marcati fuori dal router StockFun farebbe segnalare il token dagli scanner. Conseguenza accettata: la whitelist passa dal protocollo al creatore, cosa che la decisione del 2026-09-12 aveva escluso per evitare un vantaggio da insider.

2026-09-28 — Fondi dell'airdrop bloccati: 48 ore

I fondi dell'airdrop rimasti 48 ore in un vault speculare, invece di 24, possono essere spostati dall'owner senza preavviso. A 24 ore la finestra coincideva con il periodo del ciclo, quindi un normale riporto al ciclo successivo diventava spostabile senza preavviso; a 48 ore non è più così. Un fallimento del venerdì diventa comunque spostabile la domenica, prima del ciclo del lunedì. Deciso lo stesso giorno: il conteggio non si ferma mai, né durante una pausa né nel fine settimana. Chiusa il 2026-10-05, mai implementata: il trasferimento di emergenza è immediato ovunque.

2026-09-28 — La detenzione registrata onchain

Il token di ogni mercato registra nel tempo la detenzione di ogni wallet, così un contratto calcola la media nelle 24 ore precedenti un ciclo e ogni quota; il keeper non le fornisce mai. Scartata: una ripartizione calcolata offchain dal keeper e pubblicata con un periodo di contestazione. Costo accettato: ogni trasferimento del token paga gas in più.

2026-09-28 — L'airdrop in azioni wrapped, su Ethereum

Le azioni comprate su Robinhood Chain vi vengono bloccate in adapter LayerZero deployati da StockFun, uno per azione, e inviate su Ethereum come azioni wrapped. La distribuzione avviene su Ethereum, dove vivono il token e la sua detenzione, e ogni holder riscuote la propria quota a proprie spese. Conseguenze accettate: le azioni wrapped valgono solo quanto le azioni bloccate e la configurazione LayerZero, non hanno mercato su Ethereum, e un congelamento degli Stock Token da parte del loro emittente immobilizzerebbe le azioni bloccate. Deciso lo stesso giorno: l'owner detiene la configurazione LayerZero degli adapter, senza periodo di attesa e senza limite ai prelievi, come fa Paxos per l'USDG. Scartate: una configurazione congelata dopo il deploy, e modifiche con un preavviso di 48 ore.

2026-09-28 — Il router ufficiale resta modificabile

L'owner può cambiare in qualsiasi momento lo swap router ufficiale, e l'hook riconosce la whitelist anti-snipe attraverso quel router. Conseguenza accettata: indicando un altro router, l'owner può esentare chiunque dall'anti-snipe.

2026-09-28 — Una commissione di creazione di 0,001 ETH

La commissione di creazione diventa 0,001 ETH, fissata nel codice, invece di circa $3: nessun feed di prezzo, nessuna impostazione dell'owner. Il suo valore in dollari ora segue il prezzo dell'ETH. Un'impostazione dell'owner dal 2026-10-05, 0,001 ETH di default.

2026-09-28 — Il PoolManager fuori dal registro della detenzione

Il token non registra il PoolManager di Uniswap, parte di ogni swap, che detiene i token di tutti i pool e non riceve mai un airdrop: la sua cronologia vale zero, mentre quella del trader resta registrata. Risparmio misurato: circa 24.000 di gas per swap, sia in acquisto sia in vendita.

2026-09-29 — Nessuna commissione LP sui pool StockFun

I pool vengono creati con una commissione LP di Uniswap pari a zero invece dello 0,30 %: la tassa dell'hook rappresenta l'intero costo di un trade, il 5 % per direzione e il 9,75 % per un'andata e ritorno prima dell'impatto sul prezzo. Costo accettato: la tesoreria, il team e il creatore perdono la loro quota delle commissioni LP, e viene meno il burn della parte in token di quelle commissioni. Dal 2026-10-05 la commissione LP è un'impostazione del lancio, zero di default; ogni pool mantiene quella con cui è stato creato.

2026-10-01 — Correzioni dell'audit di sicurezza del 2026-09-29

Applicate il 2026-09-30 e il 2026-10-01, dopo che ogni rilievo è stato esaminato e la sua correzione scelta. Ogni rilievo corretto ha dei test di regressione che falliscono sul codice sottoposto ad audit.

Solo il lock della liquidità può aggiungere liquidità a un pool StockFun: una posizione di terzi faceva da controparte agli swap tassati senza pagare la tassa né l'anti-snipe. Il nuovo permesso dell'hook ha cambiato l'indirizzo dell'hook, che è stato minato di nuovo.

Solo la quota della tesoreria viene inviata durante un trade. Le quote del team e del buyback vengono accreditate sull'hook e pagate tramite riscossioni che chiunque può chiamare, ai wallet correnti della factory; l'escrow non esiste più. Il router e il lock pagano l'importo in entrata prima dello swap. Fino ad allora, un wallet delle commissioni che a sua volta chiamava Uniswap poteva fermare il trading su ogni pool.

Ogni passaggio di conversione spende un importo indicato dal keeper, così un vault più grande della sua sede di esecuzione converte a tranche. Il cash viene riservato per ogni azione del basket man mano che arriva, e un'azione che il keeper salta conserva la propria riserva; il vault speculare funziona allo stesso modo.

Ogni token registra nel tempo la propria supply al di fuori del PoolManager di Uniswap, il denominatore della quota pro rata dell'airdrop. Delle tre opzioni dell'audit, questa costa una scrittura in più per swap; registrare di nuovo il PoolManager sarebbe costato circa 24.000 gas per swap. Conseguenza accettata: le finestre dell'airdrop iniziano e finiscono a un'ora esatta.

Sul rail Robinhood, un basket rifiutato non blocca più gli altri mercati di un batch, a un token remoto corrisponde un solo identificatore, un'esecuzione parziale su v3 fa fallire il suo percorso, un hub remoto in pausa applica comunque i cambi di ruolo, e le registrazioni canoniche vengono pagate nell'ordine in cui sono arrivate.

Misurato: un acquisto tramite il router costa 113.529 gas e una vendita 137.250, contro 125.862 e 150.416 prima. Ancora aperti, in attesa della decisione dell'owner: la rotazione dell'adapter del bridge (M-2, e L-8 con essa), le attestazioni Ondo (M-7), e i router che accettano sé stessi come destinatario (L-4). Dal 2026-10-05 M-7 e L-4 sono corretti, e M-2 resta com'è per decisione dell'owner, e L-8 con esso.

2026-10-01 — La pipeline di sicurezza completa le correzioni

Lo stesso giorno, un secondo round di audit, da parte di due auditor indipendenti, ha completato diverse correzioni. Ognuna ha dei test di regressione; nessuna cambia una decisione di design o un parametro immutabile.

Su Robinhood Chain, un percorso v3 viene eseguito un pool alla volta, e ogni pool deve consumare tutto il proprio input: il controllo precedente vedeva solo il primo pool, e un'esecuzione parziale più avanti lasciava il token intermedio dove chiunque poteva prenderlo. Un ticket contabile canonico paga al massimo tante registrazioni quante ne ha aggiunte alla coda, a partire dalle più vecchie, così un arretrato non lo spinge più oltre il gas della sua esecuzione automatica; lo sweep paga il resto.

Un'emergenza eseguita che fa scendere il cash di un vault sotto le sue riserve le azzera tutte, in entrambi i vault: ciò che resta, e ogni afflusso successivo, viene ripartito da capo secondo i pesi. Fino ad allora l'azzeramento esisteva solo nella lettura, e le vecchie riserve tornavano con l'afflusso successivo.

Il keeper trattiene n−1 unità sull'ultima azione di un basket a ogni acquisto: il resto dell'arrotondamento va a quell'azione, e un trasferimento di polvere poteva far fallire l'acquisto. Dimezza inoltre una tranche di burn che il pool $STOCKFUN non riesce a eseguire per intero. Ogni token registra il suo primo punto orario al deploy, cosa che contava solo su un orologio che parte dall'ora 0, come quello di una chain di test. Lo stock router di Ethereum esegue un sync prima di pagare in ETH, e la Lens rifiuta una pagina vuota.

Misurato: il primo swap di ogni ora su un token costa circa da 28.000 a 30.000 gas in più come transazione a sé, non circa 23.000.

In attesa della decisione dell'owner, non decisi: un'emergenza sul cash registrato dell'hub remoto, le cui registrazioni vengono poi pagate con il cash di altri mercati (R2H-1); un token cash che rifiuta un vault speculare, il che ferma la coda canonica e fa fallire i batch che comprendono quel mercato (R2H-2); il lato contratti del margine dell'ultima azione, che cambia la regola di allocazione documentata (R2T-1); prelevare la tassa sugli acquisti come claim del PoolManager, così che qualsiasi router possa comprare (R2F-1, option b); far deployare il vault di $STOCKFUN dalla factory stessa (R2F-2); e tre punti informativi (R2H-4, R2H-6, R2H-7). Un'azione che non si può mai più comprare continua a ricevere la propria quota di ogni afflusso, secondo il suo peso: è voluto, perché dismettere una tratta cambierebbe i pesi fissi del basket. Dal 2026-10-05 R2H-1 è coperto dagli strumenti di sistemazione dei conti dei cicli di audit di quel giorno più una procedura, la messa in pausa dell'hub remoto da parte dell'owner prima del trasferimento; R2H-2 è chiuso dalle consegne non bloccanti del quarto ciclo; l'option b di R2F-1 è scartata, e la tassa resta prelevata come oggi; e un vault che rifiuta ETH non ferma più il suo mercato, il blocco descritto da R2F-2: vedi più avanti le voci del 2026-10-05.

2026-10-02 — Tutti i moduli upgradabili

Fino ad allora, nessun contratto del protocollo poteva ricevere un upgrade. Tutti i moduli tranne i token e il lock della liquidità diventano upgradabili dall'owner di StockFun, con effetto immediato: nessun timelock. Ognuno è un proxy con upgrade tramite UUPS, e chiede alla propria autorità di upgrade chi può farne l'upgrade: la factory su Ethereum, l'hub remoto su Robinhood Chain. I vault, su entrambe le chain, sono un proxy per mercato, con upgrade mercato per mercato. Il proxy dell'hook è minato con tutti i 14 permessi v4, così un'implementazione successiva può usare qualsiasi callback senza spostare l'indirizzo.

I token non hanno alcuna logica propria: un semplice ERC-20 con supply fissa e un solo setter, setRecorder, per l'owner. Il registro della detenzione li lascia per un nuovo modulo, il registratore della detenzione, che ogni token chiama a ogni trasferimento; se la chiamata fallisce, il trasferimento fallisce. Dal 2026-10-05 i token hanno anche dei rescue, per ciò che viene inviato al loro stesso indirizzo, e quella chiamata bloccante è l'unica eccezione voluta alla regola di isolamento del fondatore (vedi più avanti).

Il lock della liquidità resta non upgradabile e acquisisce una modalità di chiusura: l'owner la annuncia, e 30 giorni dopo può recuperare l'intera liquidità di ogni pool, compresa quella di $STOCKFUN, verso qualsiasi indirizzo. L'owner può annullare; il trading continua durante i 30 giorni, e nessun nuovo mercato può essere lanciato finché una chiusura è in sospeso. Esiste per il caso in cui il progetto chiuda; i 30 giorni sono il preavviso degli holder. Nemmeno il deployer dei vault speculari su Robinhood Chain è upgradabile: l'indirizzo di ogni vault speculare deriva da esso.

Cosa cambia: un upgrade non attende le 48 ore della modalità di emergenza, che resta; le regole che questo libro definisce fisse, dai limiti dei vault al burn e all'aliquota del 5 %, valgono finché l'owner non fa l'upgrade del modulo che le contiene; la factory viene deployata per prima e collegata dall'owner, il che cambia l'ordine di deploy. Uno swap costa circa 27.000 gas in più, misurato in isolamento: un acquisto 237.190 gas invece di 210.105, una vendita 285.031 invece di 258.278 — il prezzo dei proxy sul suo percorso e della chiamata al registratore. Dal 2026-10-05 nemmeno la modalità di emergenza ha più un periodo di attesa, e i limiti dei vault e l'aliquota del 5 % sono impostazioni dell'owner.

2026-10-04 — Il contratto dell'airdrop

Implementato e testato, non deployato. AirdropDistributor, un modulo upgradabile su Ethereum legato alla factory, distribuisce le azioni di ogni mercato per ciclo giornaliero. La finestra di un ciclo si chiude alle 13:00 UTC, prima dell'apertura USA tutto l'anno; i suoi acquisti e invii avvengono nella sessione che segue. Un ciclo si apre con il suo primo invio, o prima di esso, e congela i suoi numeri: il registratore della detenzione, la lista di esclusione in vigore alla chiusura della finestra, e le detenzioni idonee. Due percorsi lo alimentano, sendToAirdrop sul vault speculare, attraverso l'adapter LayerZero di ogni azione, e sul vault Ethereum per il rail locale; nient'altro accredita un ciclo.

Deciso lo stesso giorno: nessun invio da parte del keeper, solo l'holder riscuote, a proprie spese (TBD 5); nessun tetto per wallet, nessun minimo, nessuna scadenza (TBD 7); una lista di esclusione per token, stabilita dall'owner, al massimo 16 indirizzi, con sempre l'indirizzo di burn e il contratto di vesting per $STOCKFUN (TBD 8). Un invio per una finestra senza detenzioni idonee viene messo da parte per la prima finestra che ne ha, 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.

Accettato e documentato: il keeper sceglie quando, quindi un invio che arriva dopo le 13:00 UTC successive viene misurato sulla finestra del giorno dopo; spostare l'ora del ciclo ridisegna le finestre non ancora aperte, comprese quelle che le azioni messe da parte devono ancora esaminare; il registratore della detenzione di un token riceve l'upgrade sul posto, e non viene mai sostituito su un token attivo. Fuori da questa modifica: la regola delle 48 ore per i fondi bloccati, gli adapter delle azioni, il passaggio dell'airdrop nel keeper e la schermata di riscossione della dapp. Dal 2026-10-05 non c'è più alcun contratto di vesting da escludere, la regola delle 48 ore è chiusa, e l'ora del ciclo fa parte di una programmazione che l'owner imposta, la durata e l'orario di chiusura delle finestre (setCycleSchedule); un registratore indicato su un token attivo parte dalla supply del token al di fuori del PoolManager (vedi più avanti la voce del ciclo di audit).

2026-10-05 — Nessuna allocazione al team, una modalità di emergenza immediata, ogni numero un'impostazione

Tre decisioni, implementate e testate lo stesso giorno, non deployate.

L'allocazione al team scompare. Il contratto di vesting del team, TeamVesting, è eliminato, e nessun $STOCKFUN è riservato al team: l'intera supply, 1.000.000.000 token di default, va nella posizione single-sided bloccata, così come l'intera supply di un mercato va nelle sue due posizioni. Fino ad allora il 10 % andava al contratto di vesting su 12 mesi, e l'airdrop escludeva quel contratto dai cicli di $STOCKFUN; ora è escluso solo l'indirizzo di burn, insieme, dal terzo ciclo di audit di quel giorno, all'operatore del lancio (vedi più avanti).

La modalità di emergenza diventa immediata. emergencyTransfer sposta un asset fuori da un vault, da un bridge hub o dal contratto dell'airdrop, verso qualsiasi indirizzo, subito; ogni trasferimento ha un id sequenziale e un evento pubblico. La programmazione con 48 ore di attesa del 2026-08-29 non esiste più, insieme alla sua finestra di annullamento, e il periodo di attesa non è un parametro: un'emergenza agisce non appena l'owner la usa, mai dopo un'attesa. Anche la sostituzione dell'adapter del bridge, changeAdapter, è immediata, con gli stessi indirizzi fissati. La regola per i fondi dell'airdrop bloccati, decisa il 2026-09-27 e il 2026-09-28 e mai implementata, è chiusa: il trasferimento immediato la copre, su qualsiasi contratto, in qualsiasi momento.

Ogni numero diventa un'impostazione. I numeri del protocollo sono ora impostazioni onchain dell'owner, su entrambe le chain, e i valori di oggi sono quelli di default: la tassa, la sua ripartizione e l'anti-snipe; la commissione di creazione e i limiti di lunghezza dei testi di un nuovo mercato; la forma dei nuovi mercati, commissione LP e tick spacing compresi, e le quote di ciò che incassano le posizioni bloccate; la soglia di conversione e i limiti di prezzo dei vault; la programmazione e i limiti dell'airdrop; gli heartbeat degli oracoli; il gas e lo slippage del bridge. Ognuna ha effetto subito e rifiuta i valori impossibili. Un cambio della tassa vale dallo swap successivo su ogni pool, compreso uno ancora nei suoi blocchi anti-snipe; un cambio di forma vale per i mercati creati in seguito, e ogni pool mantiene la commissione LP e il tick spacing con cui è stato creato.

Resta fisso: il preavviso di 30 giorni della modalità di chiusura, END_DELAY, nel lock, che non è upgradabile; le unità e le codifiche, dal punto base all'ora del registro della detenzione; e i collegamenti, dai feed di prezzo agli endpoint del bridge, che solo un upgrade può far puntare altrove.

Conseguenza accettata: le cifre che questo libro riporta per la tassa, il lancio, i vault e l'airdrop sono valori di default, non garanzie; l'owner può cambiare ognuna di esse in qualsiasi momento, senza preavviso. Misurato: leggere le impostazioni della tassa costa a uno swap circa 1.200 gas in più, a caldo. Vedi Modello di fiducia.

2026-10-05 — Le correzioni del ciclo di audit

Lo stesso giorno, un ciclo di revisione su tutto il codice ha portato a correzioni dei contratti, ognuna con un test di regressione, non deployate. Quattro di esse cambiano il comportamento.

Dopo un trasferimento di emergenza, i conti vengono sistemati, mai pagati a spese di un altro mercato. Il contratto dell'airdrop e l'hub remoto detengono asset dovuti a più mercati. Dopo un trasferimento fuori dall'uno o dall'altro, i pagamenti che dipendono da ciò che manca attendono — le riscossioni dell'airdrop di quell'azione, i pagamenti dell'hub remoto sul rail USDG — finché gli asset non tornano o l'owner di StockFun non imputa la perdita al ciclo o al mercato che l'ha subita; sul rail canonico, prima che arrivi il deposito successivo, l'owner elimina la registrazione il cui cash è stato preso dal trasferimento. Un ciclo può essere svalutato in parte solo finché nessuno ne ha riscosso l'azione, e ogni holder perde allora nella stessa proporzione; una volta pagati alcuni holder, solo dell'intero residuo, che perdono gli holder non ancora pagati. Il trasferimento in sé resta immediato e incondizionato. Vedi Modalità di emergenza.

Solo il keeper esegue il bridge. Fino ad allora chiunque poteva inviare un batch del bridge: una terza parte poteva infilarne uno al minimo più permissivo dell'adapter tra due propri trade sul pool Curve, o far fallire il batch del keeper facendo prima il bridge di uno dei suoi vault.

Solo il keeper e l'owner di StockFun deployano in anticipo un vault speculare su Robinhood Chain. Fino ad allora chiunque poteva farlo, anche per un mercato che non esisteva ancora, legato ai collegamenti di quel giorno. Un vault deployato in anticipo ora prende lo stock router e l'oracolo dell'hub remoto al suo primo batch.

Un registratore della detenzione indicato su un token attivo parte dalla supply del token al di fuori del PoolManager, e un registratore che ha già registrato il token lo rifiuta. Fino ad allora un registratore nuovo partiva da zero: ogni vendita falliva, e le quote dell'airdrop dei cicli aperti in seguito erano rotte per sempre. Ora il trading continua, e gli holder di cui il nuovo registratore non ha visto alcun movimento risultano non aver detenuto nulla fino al loro movimento successivo. L'upgrade del registratore sul posto resta la regola.

Correzioni minori: i vault applicano il minimo del keeper stesso a ciò che arriva effettivamente, non solo il proprio limite; il ticket contabile del bridge canonico paga in base alla dimensione del batch; le impostazioni rifiutano un tick di lancio a cui nessun pool può aprire, un limite vuoto per il nome, e un hook e un lock su PoolManager diversi; un passaggio a finestre dell'airdrop più lunghe non blocca più un mercato con azioni messe da parte. Vedi Modello di fiducia.

2026-10-05 — Il secondo passaggio del ciclo di audit

Lo stesso giorno, un secondo ciclo di revisione sulle correzioni ha portato ad altre correzioni dei contratti, ognuna con un test, non deployate, e a modifiche del keeper.

I conti conteggiano ciò che li copre, mai il saldo. Il saldo del contratto dell'airdrop, e dell'hub remoto sul rail USDG, comprende anche token arrivati ma non ancora accreditati: una consegna il cui ultimo passaggio non è stato eseguito. Dopo un'emergenza, tali token potevano riaprire le riscossioni di un ciclo svuotato e pagarle con le azioni di un altro mercato. Entrambi i contratti ora conteggiano da sé ciò che copre i loro conti. Un trasferimento di emergenza prende innanzitutto da quello; ciò che prende oltre quello proveniva da token non ancora accreditati, e le consegne successive lo ripianano prima di coprire qualsiasi cosa, con l'hub remoto che registra quei batch invece di consegnarli. Gli asset tornano tramite restore, che chiunque può chiamare; un semplice trasferimento non copre nulla, quindi i token dispersi si recuperano solo per ripristinarli. Vedi Modalità di emergenza.

Dopo uno stralcio dell'intero residuo di un ciclo, che segue una riscossione, ciò che raggiunge quel ciclo in seguito viene ripartito pro rata tra tutti i suoi holder, come se l'importo stralciato non ci fosse mai stato; fino ad allora andava prima agli holder non ancora pagati, nell'ordine in cui riscuotevano. Uno stralcio che non lascia nulla di ciò che un mercato tiene da parte pone fine alla sua ricerca di una finestra.

Un token rifiuta un registratore della detenzione legato a un PoolManager di Uniswap diverso da quello del suo pool, che conterebbe il pool come un holder e pagherebbe a ogni holder una frazione della propria quota. E un registratore indicato su un token attivo mantiene una supply registrata almeno pari al totale degli holder, non pari a esso, finché ogni holder non ha fatto un movimento.

Sul bridge canonico, la commissione viene quotata a una base fee indicata dal keeper, il doppio dell'ultima, con l'eccesso restituito: una quotazione letta senza un prezzo del gas vedeva una base fee pari a zero, e un batch lungo falliva. L'hub remoto apprende chi è il keeper solo da un batch: prima del primo, l'owner di StockFun deploya in anticipo il vault speculare del primo mercato, e un mercato il cui vault il keeper non può deployare in anticipo viene lasciato fuori dal suo batch, con un avviso. Il keeper conta separatamente i fallimenti di un vault su Ethereum e su Robinhood Chain.

Quanto al secondo round del 2026-10-01: R2H-1 è coperto dagli strumenti di sistemazione dei conti più una procedura, la messa in pausa dell'hub remoto da parte dell'owner prima del trasferimento; R2H-2 è mitigato, ancora aperto: un vault speculare congelato non ferma più per sempre la coda canonica, e solo il keeper compone un batch, ma una consegna a quel vault fallisce ancora per intero, quindi il keeper deve lasciare fuori quel mercato. Vedi Modello di fiducia. Chiuso lo stesso giorno dal quarto passaggio: vedi più avanti.

2026-10-05 — Un guasto non blocca mai il resto

La regola di progettazione del fondatore, fissata lo stesso giorno: quando qualcosa fa fallire una funzione, le altre funzioni non devono farne le spese; tutto deve continuare a funzionare, e tutto deve avere una leva per recuperare i fondi persi e ricevere la correzione. Ha due parti. Isolamento: un guasto in una funzione, un mercato, un'azione, un ciclo, una registrazione o un destinatario non blocca mai gli altri; l'elemento viene saltato, conservato come dovuto o differito, con un evento, e il resto prosegue. Leve: ogni contratto che può detenere ETH o token, anche di passaggio o per errore, ha una leva per portare fuori ciò che resta bloccato, e ogni modulo può ricevere una correzione, un upgrade o un setter che lo sostituisce. Dal quarto ciclo di audit in poi, i cicli contano come un difetto qualsiasi violazione.

Un'eccezione voluta: la notifica di un token al suo registratore della detenzione resta bloccante, e una notifica che fallisce fa fallire il trasferimento. Una notifica a cui fosse permesso fallire lascerebbe che un holder la privasse del gas nel proprio trasferimento, così che il registro salti il movimento e la sua quota dell'airdrop cresca. La leva è immediata: setRecorder(0) sul token, o un upgrade sul posto del registratore, di una transazione ciascuna.

Conseguenze accettate: una quota rifiutata attende il suo destinatario invece di fermare il resto; un trasferimento di emergenza non imputato ad alcun mercato fa attendere i pagamenti di quell'asset finché non viene sistemato; e finché un token non ha un registratore, l'airdrop non apre alcun suo ciclo e ne mette da parte le azioni. Vedi Architettura.

2026-10-05 — Il terzo passaggio del ciclo di audit

Lo stesso giorno, un terzo ciclo, condotto sulle sequenze: operazioni corrette da sole che vanno storte in un certo ordine o in un certo momento. Ogni correzione ha un test, non deployata.

restore restituisce prima ciò che un trasferimento di emergenza ha preso oltre a ciò che copre i conti, sul contratto dell'airdrop e sul rail USDG dell'hub remoto, e copre i conti con il resto: restituire i token di una consegna in attesa non paga più con essi il mercato svuotato. Un'azione stralciata per intero da un ciclo prima che qualcuno la riscuotesse esce dalla lista di quel ciclo.

Un registratore della detenzione indicato su un token attivo avvia una nuova registrazione al momento del cambio: l'airdrop non misura alcuna finestra iniziata prima di esso, le cui azioni attendono, messe da parte, la prima finestra che copre per intero, e il token notifica il saldo dell'indirizzo di burn al momento del cambio. Fino ad allora una finestra del genere, misurata solo dal cambio, pagava di più chi si era mosso dopo. Procedura: aprire prima i cicli delle finestre già chiuse, poi cambiare subito dopo la fine di una finestra; l'upgrade sul posto del registratore resta la regola.

Lo script di lancio di $STOCKFUN esclude dall'airdrop l'operatore del lancio, la cui detenzione il primo ciclo pagava fino ad allora. Gli script del bridge si fermano prima del deploy quando la factory indica già un altro hub, e mappano le azioni prima di indicare l'hub; setBridgeHub rifiuta un hub che non può trasportare un basket registrato. Offchain: una transazione la cui ricevuta non si può leggere viene seguita tramite il suo hash e non viene mai inviata due volte; la sorveglianza delle emergenze legge i propri eventi a blocchi, e lancia un'allerta una volta quando fallisce e una volta quando si riprende; un mercato la cui voce nel batch non si può costruire viene lasciato fuori, con un'allerta. Nell'app, una transazione non confermata conserva il suo hash (dal decimo ciclo di audit viene seguita fino a ciò che viene minato al suo nonce, e un annullamento nel wallet non viene mai letto come fatto: sotto), e un pool che la modalità di chiusura ha recuperato non mostra né prezzo né trading.

2026-10-05 — Il quarto passaggio del ciclo di audit: la regola nel codice

Lo stesso giorno, il quarto ciclo ha portato nel codice la regola del fondatore. Ogni correzione ha un test di regressione, non deployata.

Le consegne del bridge non bloccano mai un altro mercato, la decisione dell'owner su R2H-2: una quota che il token cash rifiuta a un vault speculare resta sull'hub remoto, dovuta al suo mercato, e gli altri vengono pagati; sul rail canonico esce dalla coda, così le registrazioni che la seguono vengono pagate. Chiunque la paga in seguito con sweep. Un trasferimento di emergenza sull'hub remoto può essere imputato a un solo mercato, i cui conti vengono sistemati nella stessa chiamata. Le riscossioni pagano ciò che possono: un'azione per cui i conti non bastano, o il cui trasferimento viene rifiutato, viene differita e resta dovuta, e claimMany salta un ciclo che esclude il chiamante. Ogni tratta d'acquisto, ogni azione di un invio all'airdrop e ogni mercato di un batch del bridge va a sé. Un vault che rifiuta ETH non ferma più il suo mercato: l'hook conserva ciò che non ha potuto pagare come dovuto a quel vault, il lock conserva per il suo destinatario la quota rifiutata di un incasso di commissioni, e chiunque li paga; un contratto creatore che non può ricevere ETH riscuote verso un altro indirizzo. La Lens legge un vault alla volta.

Leve ovunque: un rescue di ciò che un modulo detiene per errore su ogni modulo che non conserva nulla di nessuno, sull'hook solo per ciò che è disperso, sul lock mai per le quote che conserva, sul burner per il suo ETH solo quando nessun burn potrebbe più spenderlo, e su entrambi i token; i vault, gli hub e il contratto dell'airdrop mantengono la modalità di emergenza.

Inoltre: il router Ondo serve solo i vault della sua factory (M-7), e ogni router rifiuta sé stesso come destinatario (L-4); il ticket di deposito del rail canonico viene prezzato alla base fee; lo script di lancio di $STOCKFUN mette in lista l'operatore prima del conio; il controllo dello storage confronta ogni livello di ogni struct. Deciso lo stesso giorno: M-2 e R2F-1 restano come sono. Vedi Modalità di emergenza e Modello di fiducia.

2026-10-05 — Il passaggio dell'airdrop nel keeper e la schermata di riscossione

Scritti lo stesso giorno, su richiesta del fondatore, senza alcuna nuova decisione; non deployati. Il keeper invia le azioni di ogni mercato una volta per finestra, dopo la sessione USA di default: prima colloca le azioni messe da parte, poi apre il ciclo, poi fa l'invio, ogni azione e ogni mercato a sé, e segue ogni consegna da Robinhood Chain finché non viene accreditata, con un'allerta che riporta il comando per rieseguire una consegna in ritardo. La schermata di riscossione della dapp elenca ciò che un wallet può riscuotere, finestra per finestra, e riscuote fino a dieci finestre per transazione, circa da 3,4 a 3,5 milioni di gas misurati a freddo. Escluso: eseguire automaticamente l'ultimo passo di una consegna fallita; l'allerta fornisce invece il comando.

Il passaggio offchain del quarto ciclo ha poi dato al keeper i suoi nuovi compiti: pagare i debiti che l'hook e il lock conservano, lanciare allerte sulle tratte fallite, sui mercati esclusi ripetutamente e sulle consegne rifiutate, pianificare ogni tratta d'azione a sé, un file di stato tra un riavvio e l'altro e l'incasso giornaliero delle commissioni LP. L'app mostra "Figures unavailable" per un vault che non può rispondere. Vedi Il keeper e La dapp.

2026-10-05 — Il quinto passaggio del ciclo di audit

Lo stesso giorno, un quinto ciclo ha trovato sette problemi di gravità bassa, ognuno corretto con un test, non deployato. Il trasferimento dell'hub remoto imputato a una registrazione canonica è per una registrazione il cui deposito è arrivato: rifiuta un importo oltre il cash non trattenuto per le quote rifiutate, e una registrazione il cui deposito è andato perso viene stralciata. Un'azione il cui saldo non si può leggere non ferma più un invio all'airdrop, né la sua quotazione, e nemmeno un adapter senza codice ferma più la quotazione. I contratti di implementazione della factory e dell'hub remoto, che tengono il loro admin nello storage del proxy, hanno il loro deployer come leva per ciò che viene inviato loro. Il lock ed entrambi i token ottengono rescue per i claim v4 e gli NFT inviati loro per errore; il lock continua a non avere alcuna chiamata generica. Un batch del bridge lascia fuori un mercato il cui vault non ha ancora codice. È stato corretto un commento che descriveva in modo errato come un acquisto sposta i fondi. Vedi Modalità di emergenza.

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

La revisione del codice offchain nel quinto ciclo ha trovato tre problemi di gravità media e sedici di gravità bassa, ciascuno corretto lo stesso giorno con un test, non deployato. Il keeper ora si attiene alla cadenza del 2026-09-27: l'ETH di un vault si converte una volta per finestra dell'airdrop, se il vault detiene la soglia al primo giro del keeper dopo la chiusura della finestra; al di sotto, l'ETH attende la finestra successiva. Fino ad allora il keeper lo convertiva a qualsiasi giro della sessione non appena il vault deteneva la soglia. Ogni transazione che il keeper invia viene scritta nel suo file di stato, con il suo nonce, prima che se ne attenda la ricevuta, così un keeper interrotto mentre attende non la invia di nuovo; una che nessun nodo conosce più viene abbandonata dopo un limite di tempo; una cartella di stato è usata da un solo keeper alla volta. Sul rail Ondo, un acquisto che Ondo quota sotto il limite del vault non viene più inviato per fallire, né pagato con un'attestazione. Un'azione il cui adapter non risponde resta fuori da un invio all'airdrop da sola.

Un basket comprende al massimo cinque azioni, un limite tecnico che l'owner di StockFun può cambiare con un upgrade: ogni costo che cresce con un basket è misurato fino a quella dimensione, e i tre basket del lancio comprendono tre, tre e due azioni. La Lens riporta lo stato di ogni vault e ciò che l'hook e il lock gli devono, e il suo upgrade va in produzione prima del Worker e dell'app che la leggono. Lo script di lancio di $STOCKFUN riprende un'esecuzione che si è fermata prima che il mercato del protocollo fosse indicato, invece di coniare un secondo token. L'app conta nella sua tesoreria l'ETH dovuto a un vault, lascia in una riscossione spazio per un'azione accreditata prima che sia minata, ricorda un'azione che il suo token ha rifiutato, e non mostra mai come nulla una cifra che non ha potuto leggere. Vedi Il keeper, I basket e La dapp.

2026-10-06 — Il sesto ciclo di audit

Il sesto ciclo ha trovato un problema di gravità alta e cinque di gravità bassa, ciascuno corretto lo stesso giorno con un test, non deployato. Sul bridge canonico, usato sulla testnet e come fallback, il keeper smetteva di rieseguire i ticket di un batch non appena i suoi mercati erano accreditati, e a un mercato poteva essere accreditato il cash di un altro batch, così un deposito che aveva mancato la sua esecuzione automatica poteva scadere. Il keeper ora segue ogni ticket finché non sa che è stato eseguito, qualunque sia l'accredito del suo trasferimento, riesegue quello ancora vivo e lancia un'allerta quando di un ticket non si sa che sia stato eseguito dopo sei ore di default, o quando è perso; accredita un trasferimento canonico solo in base agli eventi dell'hub remoto stesso, mai in base a un saldo.

Con le correzioni è arrivata una decisione, presa dall'audit come suo default raccomandato: la cadenza del 2026-09-27 si estende all'USDC. L'USDC di un vault, speso in azioni su Ethereum o inviato attraverso il bridge, parte una volta dopo ogni conversione del suo ETH, e al massimo una volta per finestra negli altri casi; fino ad allora poche unità di USDC inviate a un vault facevano inviare al keeper una transazione, o un intero batch del bridge, a ogni giro. Gli acquisti su Robinhood Chain avvengono ancora a ogni giro: il saldo di un vault speculare non distingue una consegna da una donazione, e i tetti di ogni acquisto distribuiscono di proposito una consegna grande su più giri. Le esecuzioni locali e di testnet disattivano entrambe le cadenze con lo stesso interruttore.

Corretti anche: una ricerca di azioni messe da parte che non collocherebbe nulla, per un vault che non ha nulla da inviare, non viene più inviata ogni giorno; un vault sotto la soglia viene controllato su un saldo letto dopo la chiusura della finestra; prima ancora, lo stesso giorno, il file di deploy locale viene verificato rispetto alla chain prima di essere usato; l'app contrassegna il prezzo di $STOCKFUN come "(last read)" finché la Lens non riesce a leggerne la tesoreria, e il worker nel frattempo non registra alcun prezzo per esso. Il ciclo di audit successivo, avviato lo stesso giorno, ha rilevato che il keeper quotava ogni vault su un solo router mentre ogni vault conserva il router con cui è stato creato: ora ogni vault viene quotato sul proprio. Vedi Il keeper.

Dal settimo ciclo, sotto, "nulla da inviare" significa nulla che valga la pena inviare, e il keeper legge ogni ticket partendo dalla ricevuta della sua creazione.

2026-10-06 — Il settimo ciclo di audit

Il settimo ciclo ha trovato un problema di gravità media e quattordici di gravità bassa, ciascuno corretto lo stesso giorno con un test, non deployato; i contratti erano puliti. Sul bridge canonico, il keeper leggeva se un ticket esisteva ancora prima di leggere la ricevuta della sua creazione: un deposito creato tra le due letture, o visto da due nodi a un blocco di distanza, poteva passare per eseguito mentre era ancora vivo, e scadere senza riesecuzione e senza allerta. Ora li legge nell'ordine in cui lo fa l'SDK di Arbitrum: prima la ricevuta, poi l'esecuzione automatica, poi il ticket a un blocco non anteriore alla sua creazione.

Con le correzioni è arrivata una decisione, presa dall'audit come suo default raccomandato: il keeper invia all'airdrop solo ciò che vale quanto costa inviarlo. Un'azione sopra la polvere che il bridge LayerZero non può trasportare, valutata con l'oracolo stesso del suo vault all'ultima risposta del suo feed di prezzo, deve valere la propria commissione LayerZero, o la sua quota del gas dell'invio su Ethereum, e le azioni che passano devono valere insieme l'intero invio più l'apertura del ciclo della finestra quando non è ancora aperto; altrimenti attendono nel vault una finestra successiva, con ciò che si accumula. Un valore che il keeper non riesce a leggere lascia partire l'invio, come prima. Il multiplo è un'impostazione del keeper, KEEPER_AIRDROP_MIN_VALUE_BPS: una volta il costo di default, e 0 disattiva la regola. Decide solo quando parte un'azione, mai quanto, cosa o dove. Fino ad allora un regalo di azioni appena sopra la polvere al vault di un mercato che nessuno scambia faceva aprire al keeper il ciclo di quella finestra e pagare un messaggio LayerZero ogni giorno; e la stessa polvere contava come "qualcosa da inviare", così il limite sulle ricerche di azioni messe da parte del sesto ciclo non valeva sul bridge.

Corretti anche: ogni ricerca nei log del keeper si ferma qualche blocco sotto l'ultimo blocco della chain, così un evento non viene mai perso dietro un nodo in ritardo di uno o due blocchi; il keeper verifica che ogni RPC serva la chain indicata dalla sua configurazione, e altrimenti si rifiuta di partire; il suo webhook di allerta ha un limite di tempo e la sua risposta viene letta, e un'allerta che non accetta viene conservata e inviata di nuovo; un'impostazione vuota prende il suo default. Il Worker dati dell'app legge ogni contratto upgradabile a sé, così uno che fallisce dopo un upgrade difettoso non azzera più le cifre del token $STOCKFUN; mostra il volume a 24 ore come sconosciuto finché le sue letture dei log dei trade continuano a fallire, verifica che ciascuno dei suoi endpoint serva la sua chain, e il grafico dei prezzi colloca ogni punto al suo orario. Né la Lens né lo schema di dati del Worker cambiano. Vedi Il keeper e La dapp.

Dall'ottavo ciclo, sotto, per un'azione la cui quotazione propria è zero si interroga il suo adapter, l'apertura della finestra si conta una sola volta sul rail locale, il ticket si legge qualche blocco sotto l'ultimo, e il keeper non presume più un identificatore di chain quando non ne è impostato nessuno.

2026-10-06 — Le protezioni dei feed di prezzo su Robinhood Chain

Il piano di lancio elencava due protezioni che l'oracolo non aveva ancora, entrambe raccomandate dalla documentazione di Robinhood. Sono costruite, non deployate, come impostazioni dell'owner di StockFun che partono disattivate; ciascuna può solo trattenere un prezzo, mai cambiarlo.

• Un'operazione societaria. Mentre un'azione ne attraversa una, il suo token dice che il suo oracolo è in pausa, e il suo feed di prezzo mantiene il suo ultimo valore, che può ancora sembrare fresco mentre il moltiplicatore del token cambia. L'oracolo ora trattiene il prezzo di quell'azione: la sua tratta d'acquisto fallisce da sola, con il suo cash conservato per essa, e le altre azioni del basket vengono acquistate. Il controllo è attivo per ogni azione del rail Robinhood, azione per azione, così un token la cui risposta non si può usare, o il cui flag resta attivo, può essere disattivato da solo. Un token che non risponde conta come non in pausa: Robinhood definisce il flag indicativo, e il controllo di freschezza proprio del feed resta la protezione principale.
• Il sequencer. Robinhood Chain è una chain Arbitrum con un unico sequencer. Con il feed di uptime del sequencer L2 di Chainlink, l'oracolo trattiene ogni prezzo finché il sequencer è fermo, è ripartito entro il periodo di grazia (un'ora di default), o il feed non si può leggere. Non esiste alcun feed del genere per Robinhood Chain, e Chainlink non li aggiunge più alle nuove reti: il rail viene deployato con questo controllo disattivato, per una scelta esplicita che lo script di deploy richiede, e l'owner di StockFun imposta il feed se mai ne viene pubblicato uno.

Su Ethereum entrambe restano disattivate. Vedi Il rail Robinhood.

2026-10-06 — L'ottavo ciclo di audit

L'ottavo ciclo ha trovato un problema di gravità media e otto di gravità bassa, ciascuno corretto lo stesso giorno con un test, non deployato; i contratti e le protezioni dei feed di prezzo erano puliti. Prima che l'app avesse letto il registro dei basket della chain, il suo modulo di lancio offriva i basket configurati con i loro numeri configurati: su un deploy che numerasse i suoi basket in altro modo, un creatore poteva lanciare un mercato, in modo irreversibile, su un basket diverso da quello mostrato. Il modulo ora offre solo i basket letti dalla chain, e rilegge dalla factory quello scelto subito prima dell'invio, che rifiuta se il nome o le azioni differiscono.

Corretti anche: il keeper segue un batch del bridge solo una volta che il blocco che lo contiene è profondo qualche blocco, così una riorganizzazione dei blocchi più recenti di Ethereum non può più lasciarlo a seguire identificatori che non esistono mai; distingue la polvere che il bridge non può trasportare da un'azione la cui commissione LayerZero non si può quotare, che ora lascia fuori con un'allerta invece di scartarla in silenzio; conserva un'unica allerta in attesa per allerta distinta, con quante volte e quando è stata lanciata, così le allerte ripetute a ogni ciclo non scalzano più un'allerta isolata; non mette più da parte un file di stato scritto per un'altra chain prima di aver verificato quale chain serve il suo RPC, e richiede entrambi gli identificatori di chain; legge un ticket qualche blocco sotto l'ultimo, che ogni nodo di un endpoint ha; e sul rail locale conta una sola volta l'apertura della finestra. Il keeper, il suo preflight e il suo ispettore conoscono ora le protezioni dei feed di prezzo: gli acquisti su Robinhood Chain attendono finché l'oracolo trattiene i prezzi per il sequencer, con un'allerta, e un'azione in un'operazione societaria attende da sola, mai contata come un fallimento. Il Worker dati dell'app non fa mai arretrare la sua finestra dei trade, così un nodo qualche blocco indietro non fa più contare due volte dei blocchi al volume a 24 ore; il suo proxy RPC rifiuta qualsiasi cosa non sia un indirizzo; pubblica perché manca il prezzo di un'azione (schema di dati 8), cosa che l'app mostra; e il pannello di trading addebita a un wallet nella whitelist la tassa normale durante la finestra anti-snipe, come fa l'hook. La Lens non cambia, e il Worker e l'app si deployano ancora in qualsiasi ordine. Vedi Il keeper e La dapp.

2026-10-06 — Il gas della consegna dell'airdrop con Glamsterdam

Sepolia ha attivato l'aggiornamento Glamsterdam di Ethereum il 2026-10-06, durante l'esecuzione su testnet con LayerZero (sotto); Hoodi e la mainnet non avevano ancora una data. Riprezza la crescita dello stato: un nuovo slot di storage scritto a freddo costa 110.020 gas, contro 22.100 prima. Ogni cifra di gas fissa dei contratti e degli script è stata misurata di nuovo su Sepolia, e tutte reggono tranne una coppia, il gas che una consegna dell'airdrop riceve su Ethereum: l'invio del vault speculare portava un'unica cifra di compose, 600.000, e il lzReceive dell'OFT dell'azione riceveva solo ciò che quell'OFT impone. Ogni consegna del primo ciclo dell'esecuzione è rimasta senza gas presso l'executor di LayerZero ed è stata eseguita a mano. Il decimo ciclo di audit ne ha trovati poi altri due: il gas proprio degli script di deploy e quello del compose del bridge per un batch (sotto).

La decisione del fondatore, lo stesso giorno: il keeper simula ogni consegna e ne sceglie il gas, contenuto entro limiti che l'owner di StockFun fissa sull'hub remoto; una consegna ancora bloccata viene rieseguita dal keeper, e segnalata con un'allerta a un secondo fallimento. Nel codice, non deployato sulla mainnet:

• L'hub remoto detiene due politiche di gas, ciascuna con un default, un minimo e un massimo: il gas di lzReceive oltre a ciò che impone l'OFT dell'azione, 650.000 tra 200.000 e 1.500.000 (setAirdropReceiveGas), e il gas del compose, 1.250.000 tra 600.000 e 4.000.000 (setAirdropComposeGas). Il sendToAirdrop(stocks, receiveGas, composeGas) del vault speculare invia ciò che l'hub concede per ciò che chiede il keeper, e zero prende il default; la chiamata con le sole azioni prende entrambi i default. Un hub aggiornato con un upgrade da prima delle politiche rifiuta ogni invio finché entrambe non sono impostate
• Il keeper simula il lzReceive e il compose di ogni azione su Ethereum, dall'indirizzo dell'endpoint, e chiede il fabbisogno più il 25 %; quando una simulazione non può girare, prende ciò che hanno usato le ultime consegne del mercato, poi i default dell'hub. Una consegna che resta memorizzata sull'endpoint, una volta che l'executor di LayerZero l'ha fatta fallire o dopo dieci minuti, viene rieseguita dalla chiave stessa del keeper, con il suo fabbisogno simulato più il 25 %, al massimo 4.000.000 gas di default; una che non può partire è oggetto di un'allerta con il comando per eseguirla a mano, e un secondo fallimento è oggetto di un'allerta e non viene mai inviato di nuovo
• L'app riscuote cinque finestre per transazione invece di dieci, lascia 400.000 gas per ogni azione che una finestra può ancora ricevere, e aggiungeva 150.000 gas alla stima di ogni scrittura, cosa che il nono ciclo di audit ha sostituito con il limite proprio di ogni scrittura (sotto)

La correzione è stata applicata con un upgrade all'hub remoto e al vault speculare dell'esecuzione su testnet, e ne ha sostenuto i cicli successivi. Vedi Il keeper e Il rail Robinhood.

2026-10-06 — L'esecuzione su testnet con LayerZero

Il protocollo è stato deployato su Sepolia e sulla testnet di Robinhood Chain, con gli script di produzione o con wrapper di testnet che ne mantengono il corpo, in 167 transazioni, tutte riuscite, con azioni di test, adapter di test, un USDG di test e feed simulati, ed è girato dalle 13:50 alle 19:07 UTC: sette finestre orarie, l'ETH di ciascuna convertito, passato dal bridge via LayerZero e speso sulle azioni di test; sei cicli dell'airdrop rinviati via LayerZero, i primi quattro riscossi per intero da cinque holder, ogni pagamento esattamente la quota calcolata dal registratore della detenzione; le esercitazioni di incidente svolte su messaggi reali e recuperate come documentato, tranne due metà. L'esecuzione dimostra il codice di StockFun sugli endpoint, sul DVN e sull'executor reali di LayerZero. Non dimostra la coppia USDG di Paxos, le azioni di Robinhood e i loro adapter, feed o liquidità reali, né il gas, le commissioni e la finalità della mainnet: resta una prova sulla mainnet. Ciò che ha trovato nel codice di produzione è il riprezzamento di Glamsterdam (sopra) e parte del nono ciclo di audit (sotto). Vedi Il rail Robinhood.

2026-10-06 — Il nono ciclo di audit, e il gate di verifica

Il nono ciclo ha rivisto le correzioni dell'ottavo, e ha raccolto i rilievi dell'operatore dell'esecuzione su testnet con LayerZero. Ha trovato due problemi di gravità media, il gas della consegna dell'airdrop (sopra) e il Worker dati dell'app, che ricostruiva il suo failover RPC a ogni espulsione del suo oggetto Cloudflare, il che, durante un'interruzione dell'RPC principale, gli inviava 37 richieste in meno di sette minuti dove ora ne partono 8; e problemi di gravità bassa nel keeper, nel Worker e in uno script di testnet, ciascuno corretto lo stesso giorno con un test. Per un minuto dopo una delle sue transazioni, il keeper legge ciò che ha cambiato, e stima il gas di ciò che invia dopo, al blocco di quella transazione, così un nodo indietro di un blocco non trasforma più in un falso fallimento il batch del bridge inviato subito dopo una conversione; ogni sua transazione parte con il suo gas stimato più il 25 %; le allerte che non ha potuto consegnare partono nell'ordine in cui sono state lanciate per ultime; un ticket che la sua stessa riesecuzione ha cancellato non viene più segnalato come vivo; un orario della chain che nessuna data può contenere si legge "an unknown time"; decodifica gli errori dell'oracolo; e il suo preflight gira sul deploy dell'esecuzione su testnet. Il Worker registra il numero di blocco proprio di Robinhood Chain.

Da questo ciclo un secondo agente rivede la modifica di ogni correzione prima che venga inviata al repository, rispetto alle classi di difetto che i cicli precedenti hanno trovato, la maggior parte nelle correzioni del ciclo precedente: il gate di verifica. Ciò che trova viene corretto come un rilievo di revisione, e quella correzione ripassa dal gate. In questo ciclo ha trovato difetti di gravità bassa in varie correzioni, tra cui una riesecuzione che credeva a un'allerta che chiunque può emettere, ora creduta solo se viene dall'executor di LayerZero, e un'altra che decideva un'esecuzione fallita al blocco stesso di quell'esecuzione, cosa che una riorganizzazione del blocco avrebbe potuto trasformare in un falso secondo fallimento: ora attende che il blocco sia profondo qualche blocco. Tutti sono corretti.

La revisione del Worker e dell'app dello stesso ciclo ha poi trovato un altro problema di gravità media, i 150.000 gas che l'app aggiungeva alla stima di una scrittura, che non bastavano quando un trade incontra più storage nuovo del segno di supply dell'ora, corretto lo stesso giorno: ogni scrittura riceve ora la sua stima più 50.000 gas, e un trade anche il gas di ogni scrittura che la sua stima non può vedere e che può ancora avvenire, letto al blocco della stima; una scrittura la cui stima fallisce parte con un limite fisso, e un lancio allora attende. I suoi due rilievi di gravità bassa sono stati corretti anche loro: un piatto che è una stima viene contrassegnato con "+" ovunque compaia, e un'approvazione che non si può leggere non viene mai presa per nessuna. Il ciclo non è pulito, e il conteggio dei cicli puliti resta a zero. Vedi Il keeper e La dapp.

2026-10-06 — Il decimo ciclo di audit

Il decimo ciclo ha rivisto le correzioni del nono e il lavoro sull'aggiornamento Glamsterdam di Ethereum, ogni area da un'angolazione propria: i contratti con i nuovi prezzi del gas, ogni messaggio cross-chain che fallisce a destinazione, il keeper sull'arco di mesi, l'app con wallet reali, e i documenti rispetto al codice. Ha trovato tre problemi di gravità media e sei di gravità bassa, ciascuno corretto lo stesso giorno con un test, ogni correzione rivista dal gate di verifica, non deployato sulla mainnet. I contratti sono risultati puliti sotto l'angolazione del gas con entrambe le tabelle di prezzo.

• La procedura di deploy con Glamsterdam. Il deploy documentato su Ethereum non poteva riuscire: lo strumento di deploy dava a ogni transazione il gas della sua simulazione locale, ai prezzi vecchi, mentre la creazione di un contratto ora ne richiede da quattro a sette volte tanto. Ogni trasmissione ora chiede al nodo il gas di ogni transazione una volta minata la precedente; eseguita su Sepolia
• Il gas di compose di un batch del bridge. L'ultimo passo di un batch del bridge su Robinhood Chain riceveva un'unica cifra di gas fissa, 1.200.000, qualunque cosa contenesse il batch: quattro nuovi mercati a cinque azioni l'hanno lasciato senza gas, il loro USDG è rimasto allora sull'hub remoto senza alcuna registrazione, e ogni batch successivo con gli stessi mercati falliva allo stesso modo. Ora il gas è una base più una parte per mercato, 200.000 e 400.000 di default, entrambe impostazioni dell'owner di StockFun, e un batch porta al massimo 17 mercati, il che tiene il suo messaggio sotto il limite di dimensione di LayerZero e il suo gas sotto il limite per transazione di Robinhood Chain; il keeper ne invia al massimo altrettanti e lascia il resto al suo giro successivo, prima i mercati che attendono da più tempo. Il gas in più costa poco: l'executor di LayerZero lo fattura al prezzo del gas di Robinhood Chain, 0,00001 ETH per milione di gas sulla testnet. L'allerta del keeper per un trasferimento bloccato ora dice a che punto è il messaggio del batch. L'adapter della testnet è stato aggiornato con un upgrade lo stesso giorno e il suo batch successivo è passato con il nuovo gas
• La sorveglianza delle emergenze. Il keeper nominava tutti i vault sorvegliati in un'unica richiesta di log, che un endpoint rifiuta oltre il suo limite: una volta che il registro lo avesse superato, nessun trasferimento di emergenza sarebbe più stato inoltrato. Ora li nomina a gruppi, limitati da una nuova variabile
• Correzioni minori. I testi di errore del keeper conservano di un indirizzo RPC solo l'host; le sue letture di ogni mercato passano da Multicall3, cento mercati per chiamata, invece che una per una a ogni giro; l'app segue una transazione che il wallet annulla o sostituisce, senza mai mostrare un annullamento come fatto, e per un minuto dopo la propria transazione legge a un blocco non anteriore a quello di quella transazione, così una vendita subito dopo la sua approvazione non viene più rifiutata da un nodo indietro di un blocco; e due documenti sono stati allineati al codice

Con il suo default di inviare dopo la sessione USA, il keeper ora rilegge un vault senza nulla da inviare dopo la chiusura solo alla sessione successiva. Una conseguenza di questo risparmio, e non una regola nuova: un'azione data a un vault dopo la chiusura, al di fuori di qualsiasi acquisto, parte con l'invio della sessione successiva, in una finestra più tarda; ciò che portano gli acquisti del vault stesso va sempre nella finestra terminata quel giorno.

L'audit ha anche valutato una raccomandazione, non un difetto: riscossioni che lascino un wei in ciascuno degli accumuli di commissioni dell'hook, perché il trade successivo non paghi mai la scrittura di quegli slot da zero. Per ora non è adottata. Il gas in più ricade sul primo trade dopo ogni riscossione, circa 104.000 per slot, e il margine dell'app per esso alza il limite di un trade, non ciò che paga; la modifica toccherebbe codice di riscossione le cui regole formali non potrebbero essere dimostrate di nuovo senza un'esecuzione del prover; e l'hook e il burner possono adottarla più tardi tramite upgrade, senza migrazione. Il ciclo non è pulito, e il conteggio dei cicli puliti resta a zero. Vedi Il keeper, Il rail Robinhood e La dapp.