Stato di avanzamento

Questo libro descrive il protocollo come è stato deciso. Una parte di ciò che descrive non è ancora nel codice. Questa pagina dice con precisione quale.

Deciso e implementato

• La commissione, il 5 % di default, e i suoi due schemi
• Il TreasuryVault, i suoi limiti oracolo e l'assenza di prelievo
• Il BuybackBurner e il volano di $STOCKFUN
• La modalità di emergenza, immediata dal 2026-10-05
• Il rail cross-chain verso Robinhood Chain, preparato e testato in simulazione, a senso unico da quando il percorso inverso è stato rimosso il 2026-09-28, e fatto girare da un capo all'altro su due testnet tramite LayerZero il 2026-10-06 (sotto)
• Il lancio single-sided del token del protocollo $STOCKFUN
• La rimozione del buyback del creatore, il 2026-09-28
• La riprogettazione del lancio, il 2026-09-28: niente più bonding curve né graduation; ogni mercato viene creato con le sue due posizioni bloccate, 700M e 300M di default, e l'acquisto facoltativo del creatore nella stessa transazione
• La commissione di creazione, 0,001 ETH di default, un'impostazione dell'owner dal 2026-10-05
• L'anti-snipe decrescente e la whitelist del creatore, al massimo 20 indirizzi di default, esenti quando fanno trading tramite il router ufficiale; il router ufficiale resta modificabile dall'owner
• Le commissioni del creatore detenute sull'hook, mercato per mercato, e riscosse dal creatore; dal 2026-10-01 anche le quote del team e del buyback, pagate tramite riscossioni che chiunque può attivare
• La detenzione registrata onchain per ogni token di mercato e per $STOCKFUN, dal 2026-10-02 a opera del registratore della detenzione, che ogni token chiama a ogni trasferimento. Il 2026-10-01, con il registro ancora nei token, costava circa da 52.000 a 61.000 gas in più per trasferimento tra due wallet, al di sopra della stima fatta al momento della decisione, da 20.000 a 40.000. Il PoolManager di Uniswap non viene registrato, quindi uno swap paga per il lato del trader e, dal 2026-10-01, una scrittura per la supply registrata: 113.529 gas per un acquisto tramite il router e 137.250 per una vendita, per un wallet che detiene già il token (125.862 e 150.416 prima delle correzioni del 2026-10-01, che hanno anche eliminato due invii da ogni trade)
• Nessuna commissione LP di Uniswap sui pool StockFun di default, dal 2026-09-29: la tassa rappresenta l'intero costo di un trade
• Le correzioni dell'audit di sicurezza del 2026-09-29, applicate il 2026-09-30 e il 2026-10-01: liquidità solo dal lock della liquidità; quote del team e del buyback riscosse al di fuori di qualsiasi trade; conversioni in importi indicati dal keeper, con il cash riservato azione per azione; la supply registrata, il denominatore dell'airdrop, in ogni token; un rail Robinhood Chain in cui un mercato non blocca più un batch e un hub remoto in pausa applica comunque i cambi di ruolo. Ogni rilievo corretto ha dei test di regressione
• La pipeline di sicurezza del 2026-10-01, un secondo round di audit che ha completato diverse di quelle correzioni: su Robinhood Chain, un percorso v3 viene eseguito un pool alla volta e un ticket contabile canonico non paga più registrazioni di quante ne abbia messe in coda; un'emergenza che fa scendere il cash di un vault sotto le sue riserve le annulla; il keeper trattiene n−1 unità sull'ultima azione di un basket. Ogni correzione ha dei test di regressione
• La riprogettazione upgradabile del 2026-10-02: ogni modulo tranne i token, il lock della liquidità e il deployer dei vault speculari dietro un proxy, upgradabile dall'owner di StockFun con effetto immediato; i vault un proxy per mercato, su entrambe le chain; i token ridotti a un semplice ERC-20 con un solo setter, setRecorder, e, dal 2026-10-05, i suoi rescue; il registro della detenzione in un modulo a sé; il proxy dell'hook minato con tutti i 14 permessi v4; la modalità di chiusura del lock della liquidità, con il suo preavviso di 30 giorni; i layout dello storage registrati e verificati da uno script. 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 contratto dell'airdrop, il 2026-10-04: AirdropDistributor su Ethereum, upgradabile e legato alla factory, alimentato da sendToAirdrop su entrambi i vault, e la rotta dell'airdrop sull'hub remoto. Cicli giornalieri la cui finestra si chiude alle 13:00 UTC, quote calcolate dalla detenzione registrata, una riscossione da parte di ogni holder a proprie spese, senza scadenza, tetto né minimo, una lista di esclusione per token, azioni messe da parte per una finestra senza detenzioni idonee, la modalità di emergenza. Passano i 514 test al di fuori delle suite di fork, compreso un invariante con stato; nei test LayerZero è sostituito da mock. Codex ha esaminato il design, il codice e le correzioni due volte, e il suo controllo finale non ha trovato alcun bug. Non deployato
• Le decisioni del 2026-10-05: nessuna allocazione al team, l'intera supply di $STOCKFUN nella sua posizione bloccata; un trasferimento di emergenza immediato e una sostituzione dell'adapter immediata; ogni numero del protocollo un'impostazione onchain dell'owner, su entrambe le chain, con i valori di oggi come default, e ogni pool che mantiene la commissione LP e il tick spacing con cui è stato creato. Implementate e testate, non deployate
• La regola di progettazione del fondatore del 2026-10-05: un guasto non blocca mai il resto, e ogni contratto che può detenere fondi ha una leva per portare fuori ciò che resta bloccato, con un'unica eccezione voluta, la notifica del token al suo registratore della detenzione; vedi Architettura. Il quarto ciclo di audit di quel giorno l'ha portata nel codice: consegne del bridge che non bloccano mai un altro mercato, riscossioni che pagano ciò che possono, ogni tratta d'acquisto, ogni azione dell'airdrop e ogni mercato di un batch a sé, debiti conservati per un destinatario che rifiuta ETH invece di un mercato fermo, una Lens che legge un vault alla volta, e rescue sui moduli senza modalità di emergenza. Implementato e testato, non deployato
• I cinque cicli di audit del 2026-10-05 e le loro correzioni, tra cui: conti sistemati dopo un trasferimento di emergenza, mai pagati con il cash di un altro mercato; il batch del bridge riservato al keeper, e il pre-deploy dei vault speculari al keeper e all'owner; un registratore indicato su un token attivo che non interrompe più il trading né misura una finestra anteriore a esso; l'operatore del lancio di $STOCKFUN escluso dall'airdrop prima del conio; i ticket del rail canonico prezzati alla base fee; il controllo dello storage a ogni livello; la regola sopra. Ogni correzione ha un test di regressione; a fine giornata passano 614 test Foundry, con tre suite di fork saltate in assenza di un RPC. Non deployato
• Il passaggio dell'airdrop nel keeper e la schermata di riscossione della dapp, il 2026-10-05, con i nuovi compiti del keeper: pagare ciò che l'hook e il lock conservano per un destinatario, lanciare allerte su ciò che continua a fallire, pianificare ogni tratta d'azione a sé, un file di stato che sopravvive ai riavvii e l'incasso giornaliero delle commissioni LP. Non deployato
• Il passaggio offchain del quinto ciclo di audit, il 2026-10-06: il keeper converte l'ETH di un vault una volta per finestra dell'airdrop, come deciso il 2026-09-27, registra ogni transazione prima che se ne attenda la ricevuta e tiene un lock sulla sua cartella di stato, e non paga più un'attestazione Ondo per un acquisto che può solo fallire; un basket comprende al massimo cinque azioni; la Lens riporta lo stato e i debiti di ogni vault; lo script di lancio di $STOCKFUN riprende un'esecuzione interrotta; l'app conta l'ETH dovuto a un vault, lascia nelle riscossioni spazio per un'azione ancora in arrivo, ricorda un'azione che il suo token ha rifiutato, e non mostra mai una cifra non letta come nulla. Passano 619 test Foundry, con tre suite di fork saltate in assenza di un RPC. Una prova generale su una chain privata lo stesso giorno ha eseguito il keeper da un capo all'altro su due finestre e ha superato i suoi sei scenari. Vedi Il keeper e La dapp. Non deployato
• I rilievi della prova generale, corretti il 2026-10-06: 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, così un mercato che ha fatto un trade e poi è rimasto fermo non tiene più il suo primo airdrop fuori dalla portata dei suoi holder; registra un vault trovato sotto la soglia in base alla sua finestra, mai in base al proprio orologio; e il file di deploy locale viene verificato rispetto alla chain prima che il keeper, l'app o il worker lo usino. Passano 620 test Foundry, con tre suite di fork saltate in assenza di un RPC. Vedi Il keeper. Non deployato
• Il sesto ciclo di audit, corretto il 2026-10-06: sul bridge canonico il keeper segue ogni ticket finché non sa che è stato eseguito, qualunque sia l'accredito del suo trasferimento, e accredita un trasferimento solo in base agli eventi dell'hub remoto; l'USDC di un vault parte una volta dopo ogni conversione del suo ETH e al massimo una volta per finestra negli altri casi, come deciso per l'ETH il 2026-09-27, mentre gli acquisti su Robinhood Chain avvengono ancora a ogni giro; una ricerca di azioni messe da parte che non può collocare 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; ogni vault viene quotato sul proprio router; l'app contrassegna il prezzo di $STOCKFUN come "(last read)" finché la Lens non riesce a leggerlo. Vedi Il keeper. Non deployato
• Il settimo ciclo di audit, corretto il 2026-10-06: il keeper invia all'airdrop solo ciò che vale quanto costa inviarlo, e la polvere che il bridge non può trasportare non conta più come qualcosa da inviare; legge ogni ticket canonico partendo dalla ricevuta della sua creazione, così un deposito vivo non viene mai preso per eseguito; ogni ricerca nei log si ferma qualche blocco sotto l'ultimo blocco; si rifiuta di partire con un RPC che serve una chain diversa da quella configurata; il suo webhook di allerta conserva e invia di nuovo ciò che non ha accettato; un'impostazione vuota prende il suo default. Il Worker dati dell'app legge ogni contratto upgradabile a sé, mostra il volume a 24 ore come sconosciuto finché le sue letture dei trade falliscono, e verifica la chain di ogni endpoint; il grafico dei prezzi colloca ogni punto al suo orario. Passano 620 test Foundry (615 fuori dai file di fork, e i cinque della suite di fork di Robinhood Chain sul suo RPC pubblico; le tre suite di fork di Ethereum saltate in assenza di un RPC); passano i 277 test del keeper, i 51 del pacchetto condiviso, i 9 del back end e i 137 del worker. Vedi Il keeper e La dapp. Non deployato
• Le protezioni dei feed di prezzo su Robinhood Chain, implementate il 2026-10-06: l'oracolo trattiene il prezzo di un'azione finché il suo token dice che il suo oracolo è in pausa per un'operazione societaria, attiva per ogni azione, e ogni prezzo finché il feed di uptime del sequencer di Chainlink dice che il sequencer è fermo o appena ripartito. Non esiste alcun feed del genere per Robinhood Chain, quindi quel secondo controllo resta disattivato al deploy, per una scelta esplicita, finché non ne viene pubblicato uno. Entrambe sono impostazioni dell'owner, disattivate su Ethereum. Vedi Il rail Robinhood. Non deployato
• L'ottavo ciclo di audit, corretto il 2026-10-06: il modulo di lancio dell'app offre solo i basket letti dalla chain e ricontrolla quello scelto prima dell'invio; il keeper segue un batch del bridge una volta che il suo blocco è profondo qualche blocco, distingue la polvere del bridge da un'azione la cui commissione non si può quotare, conserva un'unica allerta in attesa per allerta distinta, trattiene un file di stato di un'altra chain finché non ha letto la chain del suo RPC, richiede entrambi gli identificatori di chain, legge un ticket qualche blocco sotto l'ultimo e conta una sola volta l'apertura del rail locale; il keeper, il suo preflight e il suo ispettore, il Worker e l'app conoscono ora le protezioni dei feed di prezzo; la finestra dei trade del Worker non arretra mai, e il pannello di trading addebita a un wallet nella whitelist la tassa normale. Passano 640 test Foundry (633 fuori dai file di fork, e i sette del file di fork di Robinhood Chain sul suo RPC pubblico; le tre suite di fork di Ethereum saltate in assenza di un RPC); passano i 306 test del keeper, i 51 del pacchetto condiviso, i 9 del back end e i 155 del worker. Vedi Il keeper e La dapp. Non deployato
• Il gas della consegna dell'airdrop con l'aggiornamento Glamsterdam di Ethereum, che Sepolia ha attivato il 2026-10-06: la decisione del fondatore di quel giorno, con il keeper che simula ogni consegna e ne sceglie il gas entro i limiti che l'owner di StockFun fissa sull'hub remoto, e che riesegue una consegna ancora bloccata, con un'allerta a un secondo fallimento. Implementato e testato, applicato con un upgrade sull'esecuzione su testnet, non deployato sulla mainnet. Vedi Il keeper
• Il nono ciclo di audit, corretto il 2026-10-06, con i rilievi dell'esecuzione su testnet con LayerZero: il keeper legge al blocco della sua ultima transazione per un minuto e vi stima il gas di ciò che invia dopo, dà a ogni transazione la sua stima più il 25 %, consegna le sue allerte in attesa nell'ordine in cui sono state lanciate per ultime, non segnala più un ticket che la sua stessa riesecuzione ha cancellato, e il suo preflight gira sul deploy di testnet; il Worker conserva ciò che ha appreso dei suoi RPC quando il suo oggetto Cloudflare dorme, e registra il blocco proprio di Robinhood Chain; l'app dà a ogni scrittura il proprio limite di gas, contrassegna un piatto che è una stima, e non prende mai per nessuna un'approvazione che non è riuscita a leggere. Da questo ciclo un secondo agente rivede ogni correzione prima che venga inviata al repository, e i suoi rilievi vengono corretti allo stesso modo. Passano 653 test Foundry (646 fuori dai file di fork, e i sette del file di fork di Robinhood Chain sul suo RPC pubblico; le tre suite di fork di Ethereum saltate in assenza di un RPC); passano i 370 test del keeper (372 dopo l'ultima correzione del gate), i 51 del pacchetto condiviso, i 9 del back end e i 189 del worker. Vedi Test e verifica. Non deployato sulla mainnet
• Il decimo ciclo di audit, corretto il 2026-10-06: ogni trasmissione del deploy prende la stima del gas del nodo, dato che la cifra propria dello strumento di deploy è insufficiente per ogni creazione con Glamsterdam; l'ultimo passo di un batch del bridge su Robinhood Chain riceve una base più una parte per mercato, al massimo 17 mercati per batch, e il keeper non ne invia di più e dice a che punto è un batch bloccato; la sorveglianza delle emergenze del keeper nomina i suoi contratti a gruppi, i suoi testi di errore conservano di un indirizzo RPC solo l'host, e legge ogni mercato tramite Multicall3; l'app non mostra mai come fatta una transazione che il wallet ha annullato, e per un minuto legge a un blocco non anteriore a quello della sua ultima transazione. L'adapter del bridge della testnet è stato aggiornato e ha portato il suo batch successivo. Passano 662 test Foundry (655 fuori dai file di fork, e i sette del file di fork di Robinhood Chain sul suo RPC pubblico; le tre suite di fork di Ethereum saltate in assenza di un RPC), con i 2 del progetto dell'esecuzione su testnet con LayerZero; passano i 400 test del keeper, i 51 del pacchetto condiviso, i 9 del back end e i 210 del worker. Vedi Test e verifica. Non deployato sulla mainnet
• I residui di un ciclo interrotto completati al ciclo successivo, deciso il 2026-09-27: il keeper fa proseguire il cash che un vault detiene ancora, qualunque sia la soglia, al più tardi nella finestra successiva

Un ordine di implementazione, in passaggi che lasciano il repository compilabile, è registrato in projet/docs/FUNCTIONAL_AUDIT_2026-09-28.md.

Deciso il 2026-09-27, non ancora implementato

Più nulla. Il passaggio giornaliero dell'airdrop nel keeper e la schermata di riscossione degli holder nella dapp sono nel codice dal 2026-10-05, e i residui di un ciclo interrotto vengono completati al ciclo successivo, con il keeper che fa proseguire il cash che un vault detiene ancora, qualunque sia la soglia: vedi sopra.

I documenti in doc/ e la specifica della landing sono stati allineati a questa decisione il 2026-09-27. Nel codice è stata completata la rimozione del buyback del creatore, dal 2026-10-04 c'è il contratto dell'airdrop, con il suo calcolo delle quote e le sue riscossioni, e dal 2026-10-05 il passaggio del keeper e la schermata di riscossione.

Deciso il 2026-09-28, non ancora implementato

• Gli adapter delle azioni che portano le azioni wrapped su Ethereum, uno per azione: l'adapter lockbox su Robinhood Chain e il suo OFT su Ethereum. Richiedono il pacchetto oft-evm di LayerZero e non sono nel repository per la mainnet; i test usano dei mock, e l'esecuzione su testnet con LayerZero del 2026-10-06 ha usato adapter di test costruiti su quel pacchetto. La riscossione su Ethereum è implementata dal 2026-10-04, e la sua schermata nella dapp dal 2026-10-05
• La configurazione LayerZero degli adapter delle azioni, detenuta dall'owner, senza periodo di attesa e senza limite ai prelievi

Deciso il 2026-09-11, propagato parzialmente

Il passaggio da Ondo a Robinhood Chain è definito e il codice del rail esiste. Non tutti i documenti sorgente del progetto sono stati aggiornati — vedi Errata corrige delle fonti.

Mai verificato in condizioni reali

• Non è avvenuto alcun deploy su mainnet
• Non è stato messo alla prova alcun trasporto LayerZero sulla mainnet. Il 2026-10-06 l'esecuzione su testnet con LayerZero ha portato i batch del bridge e le consegne dell'airdrop tra Sepolia e la 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. Ha usato azioni di test, adapter di test, un USDG di test e feed simulati: non dimostra né la coppia USDG di Paxos, né le azioni di Robinhood e i loro adapter, né feed e liquidità reali, né il gas, le commissioni e la finalità della mainnet. Vedi Il rail Robinhood
• Le prove formali esistenti non coprono l'attuale rail cross-chain
• Sette regole della specifica formale del LiquidityLock restano indecise sul prover per un metodo, lockProtocolLiquidity, anche con un limite di tempo più lungo; valgono su tutti gli altri metodi. La nuova esecuzione del 2026-10-01, sul codice corretto, non ha trovato alcuna regola violata
• Le specifiche formali sono in corso di adeguamento alla riprogettazione del 2026-10-02: la loro ultima esecuzione completa sul prover, il 2026-10-01, la precede. Per l'airdrop del 2026-10-04, le cinque specifiche che toccano i contratti modificati superano il controllo dei tipi, senza alcuna esecuzione sul prover. Il 2026-10-05 le specifiche sono state aggiornate per le impostazioni, poi per i cicli di audit di quel giorno, che hanno aggiunto regole sui debiti e su ciò che è disperso nell'hook, sulle quote conservate dal lock e su ogni rescue: superano il controllo dei tipi, senza alcuna esecuzione sul prover dal 2026-10-01. Lo stesso vale per le nuove regole dell'oracolo per le sue protezioni dei feed di prezzo, scritte il 2026-10-06
• I pagamenti dei debiti del keeper, l'incasso delle commissioni LP, le allerte e il file di stato, scritti il 2026-10-05, sono coperti dai suoi test e, dal 2026-10-06, da una prova generale su una chain privata: conversioni una volta per finestra, l'airdrop, un vault che rifiuta ETH e i suoi debiti pagati, interruzioni a metà operazione con il file di stato e il suo lock, le commissioni LP. Il rail del bridge non ha girato lì; ha girato da un capo all'altro nell'esecuzione su testnet con LayerZero del 2026-10-06, con il keeper, mai in condizioni reali
• Non è stata condotta alcuna revisione esterna

Ancora da definire prima della mainnet

• Un rilevamento aggiornato della copertura dei feed su Robinhood Chain e, se Chainlink pubblicasse un feed di uptime del sequencer per quella chain, la sua impostazione sull'oracolo (non ne esiste alcuno al 2026-10-06)
• Il limite di dimensione del percorso LayerZero che l'USDG di Paxos segue verso Robinhood Chain, letto prima del primo batch, e il tetto di mercati di un batch del bridge impostato di conseguenza se differisce dai 10.000 byte di default (dal decimo ciclo di audit)
• FDV iniziale e limite superiore della posizione $STOCKFUN
• Il lavoro che resta sull'airdrop, elencato sopra: gli adapter delle azioni. I suoi parametri sono fissati dal 2026-10-04: nessun invio da parte del keeper, nessun tetto, nessun minimo, nessuna scadenza, una lista di esclusione per token
• La metrica che sostituisce il Treasury Ratio, e lo slogan e la tagline, che descrivono una tesoreria che si accumula
• I rilievi del secondo round dell'audit, il 2026-10-01, ancora in attesa della decisione dell'owner: il lato contratti del margine dell'ultima azione, che cambia la regola di allocazione documentata (R2T-1); e, facoltativamente, far deployare il vault di $STOCKFUN dalla factory stessa (R2F-2). Dal 2026-10-05 un vault che rifiuta ETH non ferma più il suo mercato, per cui il blocco descritto da R2F-2 non deriva più da un vault del genere

Risolti il 2026-10-05. Dell'audit del 2026-09-29: le attestazioni Ondo spendibili da chiunque ne vedesse una (M-7) e i router che accettavano sé stessi come destinatario (L-4) sono corretti, e la rotazione dell'adapter del bridge (M-2, e L-8, a essa collegato) resta com'è, per decisione dell'owner. Del secondo round: prelevare la tassa sugli acquisti come claim del PoolManager (R2F-1, option b) è stato scartato, e la tassa resta prelevata come oggi; un'emergenza sul cash registrato dell'hub remoto, le cui registrazioni venivano poi pagate con il cash di altri mercati (R2H-1), è coperta dagli strumenti di sistemazione dei conti dei cicli di audit di quel giorno più una procedura, in cui l'owner mette in pausa l'hub remoto prima del trasferimento sul rail canonico; e un token cash che rifiuta un vault speculare (R2H-2) non blocca più nulla dal quarto ciclo di audit: la consegna a quel vault attende a sé, e gli altri mercati vengono pagati.