Modello di fiducia

Chi può fare cosa. La risposta onesta, non quella del marketing.

Dal 2026-10-02 quasi ogni contratto del protocollo è upgradabile: l'owner di StockFun può sostituirne il codice, con effetto immediato. Dal 2026-10-05 anche i numeri del protocollo, dalla tassa al ciclo dell'airdrop, sono impostazioni onchain dell'owner, anch'esse con effetto immediato: le cifre che questo libro riporta sono i loro valori di default, elencati più avanti insieme a ciò che resta fisso. Ogni regola che questo libro attribuisce a un modulo è la regola della sua implementazione attuale. Fuori dal potere di upgrade: i token, il lock della liquidità e, su Robinhood Chain, il deployer dei vault speculari.

Cosa non può fare nessuno

Questi punti poggiano su contratti non upgradabili. Valgono qualunque upgrade faccia o qualunque impostazione cambi l'owner.

• Coniare nuovi token. La supply viene coniata una sola volta, nel costruttore, e i token non sono upgradabili
• Spostare i token di un holder senza una sua autorizzazione. Il setter dei token, setRecorder, non sposta alcun saldo, e i loro rescue, dal 2026-10-05, spostano solo ciò che è stato inviato all'indirizzo stesso del token
• Rimuovere la liquidità di un pool senza un preavviso pubblico di 30 giorni. Il lock non è upgradabile, la sua unica uscita è la modalità di chiusura, più avanti, e i suoi 30 giorni sono una costante, non un'impostazione. I suoi rescue, dal 2026-10-05, non raggiungono né le posizioni né le quote di commissioni che conserva per i loro destinatari
• Cambiare la commissione LP o il tick spacing di un pool attivo. Ogni pool mantiene quelli con cui è stato creato: fanno parte della sua chiave, che il lock conserva

Cosa esclude il codice attuale

Con le implementazioni attuali nessuno può fare queste cose, owner compreso. Ognuna poggia su un modulo di cui l'owner può fare l'upgrade.

• Aggiungere liquidità a un pool StockFun. Solo il lock della liquidità può farlo, dal 2026-10-01
• Bloccare il trading tramite un wallet delle commissioni o un vault. Solo la quota della tesoreria viene pagata durante un trade, e dal 2026-10-05 a un vault che la rifiuta l'importo resta invece dovuto; le altre vengono riscosse in seguito
• Cambiare la composizione di un basket dopo la creazione
• Cambiare i feed di prezzo che legge un vault esistente. Ogni feed viene scritto una sola volta, all'inizializzazione dell'oracolo, e ogni vault mantiene il proprio oracolo; gli heartbeat dei feed sono impostazioni e, dal 2026-10-06, anche le due protezioni dell'oracolo su Robinhood Chain, che possono solo trattenere un prezzo, mai cambiarlo
• Inviare i token del buyback di $STOCKFUN altrove che al burn
• Scegliere chi riceve un airdrop, o riscuotere la quota di qualcun altro. La ripartizione deriva dalla detenzione registrata, pro rata, e solo l'holder riscuote

Cosa può fare un creatore

• Percepire la voce del creatore di ogni trade sul proprio mercato, il 2 % di default, e riscuoterla, dal 2026-10-05 anche verso un altro indirizzo se lo desidera (claimCreatorFeesTo)
• Stabilire la whitelist anti-snipe del proprio mercato, i cui indirizzi pagano la normale tassa durante i primi blocchi: al massimo 20 indirizzi di default, fissati nella transazione di creazione, pubblici, e non modificabili in seguito
• Comprare e vendere il proprio token, come chiunque

Non riceve alcuna allocazione, non controlla la liquidità, e non può mettere in pausa il proprio mercato. Non ha alcun potere sulla tesoreria: riceve azioni solo come qualsiasi holder.

Cosa può fare il keeper

Attivare le conversioni, in un momento a sua scelta, in importi che indica, sui percorsi che propone. Sempre dentro i limiti oracolo del vault e la riserva di ogni azione, e senza mai scegliere chi riceve cosa. Dal 2026-10-01, saltare un'azione non cambia più i pesi del basket: quell'azione conserva la propria quota per dopo. Dal 2026-10-05 il vault applica il minimo che il keeper indica a ciò che arriva effettivamente. Dal 2026-10-06 il keeper converte l'ETH di un vault una volta per finestra dell'airdrop, come deciso il 2026-09-27: è una regola propria del keeper, che il vault non impone; il vault registra solo quando il suo ETH è stato convertito per l'ultima volta.

Dal 2026-10-05 è anche l'unico che invia un batch del bridge (bridgeReady) e, insieme all'owner di StockFun, l'unico che deploya in anticipo il vault speculare di un mercato su Robinhood Chain (predeploy). Fino ad allora entrambe le operazioni erano aperte a chiunque. L'hub remoto apprende chi è il keeper da un batch, quindi prima del primo batch l'owner di StockFun deploya in anticipo il vault del primo mercato, e un mercato il cui vault il keeper non può deployare in anticipo viene lasciato fuori dal suo batch.

Sull'airdrop, dal 2026-10-04: aprire il ciclo di un mercato (openCycle), inviare le azioni di un vault al contratto dell'airdrop (sendToAirdrop, pagando le commissioni LayerZero da Robinhood Chain) e collocare le azioni messe da parte (assignUnassigned). Sceglie quando, mai quanto, cosa, dove o per chi: l'importo è il saldo del vault, la destinazione è il contratto indicato dal protocollo, e la ripartizione deriva dalla detenzione. Chiunque può aprire un ciclo o collocare le azioni messe da parte, con lo stesso risultato chiunque chiami. Un invio che arriva dopo l'orario di chiusura successivo, le 13:00 UTC di default, viene misurato sulla finestra del giorno dopo. Il suo passaggio giornaliero è scritto dal 2026-10-05: vedi Il keeper. Dal settimo ciclo di audit, il 2026-10-06, invia un'azione solo una volta che vale quanto costa inviarla, il che decide solo quando parte quell'azione: ciò che attende resta nel vault per una finestra successiva. Dal nono, lo stesso giorno, indica anche il gas che ogni consegna riceve su Ethereum, che l'hub remoto mantiene tra il minimo e il massimo fissati dall'owner di StockFun, e riesegue dalla propria chiave una consegna bloccata sull'endpoint di LayerZero su Ethereum, cosa che chiunque può fare: nessuna delle due cambia ciò che viene consegnato, né dove.

Dal 2026-10-05 paga anche, a ogni ciclo, ciò che l'hook e il lock conservano per un destinatario che lo ha rifiutato (payTreasury, payOwed), e incassa le commissioni LP di un pool creato con una commissione (collectFees). Chiunque può fare queste tre chiamate, che pagano solo i destinatari indicati dai contratti.

La sua chiave è una hot key. Non sceglie mai dove va un asset.

Cosa può fare l'owner di StockFun

È qui che risiede la vera fiducia. L'owner di StockFun è l'owner del protocollo: l'owner della factory su Ethereum, che l'hub remoto rispecchia su Robinhood Chain.

• Fare l'upgrade di ogni modulo tranne i token, il lock della liquidità e il deployer dei vault speculari, con effetto immediato e senza preavviso. I vault ricevono l'upgrade uno per uno, mercato per mercato, su entrambe le chain
• Cambiare i numeri del protocollo, con effetto immediato e senza preavviso: la tassa, la sua ripartizione e l'anti-snipe, la commissione di creazione, la forma dei nuovi mercati, la soglia di conversione e i limiti di prezzo dei vault, il ciclo dell'airdrop, e gli altri elencati più avanti
• Avviare la modalità di chiusura del lock e, 30 giorni dopo, recuperare l'intera liquidità di ogni pool, compresa quella di $STOCKFUN, verso qualsiasi indirizzo
• Indicare il registratore della detenzione a cui ogni token notifica i propri trasferimenti. Se la notifica fallisce, il trasferimento fallisce: è l'unica eccezione voluta alla regola secondo cui un guasto non blocca mai il resto (vedi Architettura), con due leve immediate, setRecorder(0), che ferma la registrazione del token, e un upgrade sul posto del registratore. Dal 2026-10-05 un token rifiuta un registratore legato a un PoolManager di Uniswap diverso da quello del suo pool. Il registratore riceve l'upgrade sul posto, il che ne conserva la cronologia, e non viene sostituito su un token attivo: dal 2026-10-05 un sostituto parte dalla supply del token al di fuori del PoolManager di Uniswap, quindi il trading continua, e l'airdrop non misura alcuna finestra iniziata prima di esso; ma considera gli holder di cui non ha visto alcun movimento come se non avessero detenuto nulla fino al loro movimento successivo, per cui una finestra che li include paga loro di meno, e a nessuno di più. Fino al 2026-10-05 un registratore nuovo faceva fallire ogni vendita e rompeva le quote dell'airdrop dei cicli aperti in seguito
• Registrare i basket, prima che vengano congelati
• Impostare gli indirizzi a scrittura singola, una volta sola
• Impostare il keeper e i wallet delle commissioni. Una riscossione paga il wallet impostato al momento della riscossione, quindi un cambio reindirizza anche il saldo del team o del buyback non ancora riscosso
• Cambiare lo swap router ufficiale registrato nella factory, quello attraverso cui l'hook riconosce la whitelist anti-snipe
• Indirizzare i vault futuri verso un altro stock router o un altro registro di oracoli; i vault esistenti mantengono i propri
• Associare ogni azione di un basket al suo token su Robinhood Chain, in sola aggiunta
• Impostare la lista di esclusione dell'airdrop di ogni token, per le finestre che si chiudono dopo (setExclusions); registrare l'OFT di ogni azione su Ethereum (registerStockOft)
• Indicare il contratto dell'airdrop a cui i vault inviano (setAirdropDistributor); uno sostituito mantiene ogni ciclo riscuotibile dove si trova. Su Robinhood Chain, indicare la rotta dell'airdrop, il contratto e il gas di ogni consegna (setAirdrop), e l'adapter di ogni azione (setStockAdapter); dal 2026-10-06, impostare il default, il minimo e il massimo del gas che ogni consegna riceve su Ethereum (setAirdropReceiveGas, setAirdropComposeGas)
• Sostituire l'adapter del bridge per gli invii futuri, subito (changeAdapter), con un adapter che mantiene esattamente gli stessi indirizzi fissati: lo stesso hub, la stessa factory, gli stessi token cash, lo stesso hub remoto e la stessa destinazione. L'audit di sicurezza del 2026-09-29 ha rilevato che l'hub remoto rifiuterebbe i batch del nuovo adapter (M-2); il 2026-10-05 l'owner ha deciso di lasciare le cose come sono, per cui un adapter si cambia facendone l'upgrade sul posto, allo stesso indirizzo
• Mettere in pausa conversioni e bridging, immediatamente. Un hub remoto in pausa applica comunque i cambi di ruolo che ogni batch trasporta. Sul contratto dell'airdrop, la pausa ferma gli invii, le aperture e il collocamento delle azioni messe da parte, mai una riscossione
• Spostare qualsiasi asset fuori da una tesoreria, da un bridge hub o dal contratto dell'airdrop, verso qualsiasi indirizzo, subito e senza preavviso (emergencyTransfer), su entrambe le chain, in qualsiasi momento; sull'hub remoto, dal 2026-10-05, anche imputandolo a un solo mercato, i cui conti vengono sistemati nella stessa chiamata (emergencyTransferFromPending, emergencyTransferRecord)
• Dopo un trasferimento del genere fuori dal contratto dell'airdrop o dall'hub remoto, imputare la perdita al ciclo o al mercato che l'ha subita (writeDownCycle, writeDownUnassigned, writeOffPending, writeOffRecord, dal 2026-10-05). 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, e ciò che raggiunge il ciclo in seguito viene di nuovo ripartito pro rata tra tutti i suoi holder. Nessun altro mercato ne fa le spese; finché la perdita non viene imputata o gli asset non tornano tramite restore, che chiunque può chiamare, i pagamenti di ciò che manca attendono, e gli altri proseguono: una riscossione paga le altre azioni. Entrambi i contratti conteggiano ciò che copre i loro conti, mai il loro saldo: gli asset in transito verso un altro mercato non pagano mai la perdita, e un semplice trasferimento verso di essi non copre nulla
• Portare fuori ciò che un modulo detiene per errore (rescue, dal 2026-10-05): ETH o token inviati a un modulo che non conserva nulla di nessuno; ciò che è disperso nell'hook, mai ciò che deve; ciò che il lock detiene oltre le quote di commissioni che conserva, mai le sue posizioni; l'ETH del BuybackBurner solo quando nessun burn potrebbe più spenderlo; ciò che è stato inviato all'indirizzo stesso di un token. Vedi Modalità di emergenza
• Cambiare la configurazione LayerZero degli adapter delle azioni dell'airdrop, senza preavviso e senza limite ai prelievi

L'upgrade è il più ampio di questi poteri: raggiunge in un colpo solo ogni regola del secondo elenco qui sopra. Insieme alle impostazioni, alla modalità di chiusura, al trasferimento di emergenza e alla configurazione degli adapter delle azioni, significa che StockFun non è trustless e non pretende di esserlo. La tesoreria è presidiata dal protocollo con un percorso di recupero controllato dall'owner.

Le impostazioni

Dal 2026-10-05 i numeri del protocollo sono impostazioni onchain dell'owner di StockFun, su entrambe le chain. Ognuna ha effetto nella transazione che la imposta, senza preavviso, emette un evento, e rifiuta i valori impossibili: un'aliquota oltre il 100 %, una ripartizione più grande della tassa, una forma di lancio che un pool non può contenere. I valori qui sotto sono quelli di default, quelli che questo libro riporta.

• Ogni pool, dallo swap successivo. Un cambio della tassa o dell'anti-snipe vale dallo swap successivo su ogni pool, compreso un pool ancora dentro i suoi blocchi anti-snipe: la decrescita viene calcolata con le impostazioni in vigore, a partire dal blocco di lancio del pool. L'anti-snipe non preleva mai meno della tassa. Il tetto della whitelist si applica quando viene creato un mercato
• Solo i nuovi mercati, per la loro forma. Una nuova supply, nuove bande, un nuovo tick spacing o una nuova commissione LP valgono per i mercati creati in seguito. Ogni pool mantiene la commissione LP e il tick spacing con cui è stato creato, e la Lens li fornisce, mercato per mercato; il pool di $STOCKFUN prende quelli in vigore al momento del suo lancio
• In tempo reale, per i vault. Ogni vault legge la soglia di conversione e i propri limiti di prezzo a ogni conversione, e il lock legge le quote delle commissioni LP a ogni incasso
• I cicli aperti mantengono la loro finestra. Una nuova programmazione dei cicli dell'airdrop vale per le finestre non ancora aperte, e le ridisegna, comprese quelle che le azioni messe da parte devono ancora esaminare

Ciò che resta fisso:

• Il preavviso di 30 giorni della modalità di chiusura, END_DELAY, una costante del lock della liquidità, che non è upgradabile
• L'immediatezza del trasferimento di emergenza: non ha alcun periodo di attesa, e nessuna impostazione può aggiungerne uno
• Unità e codifiche: il punto base, l'ora come unità del registro della detenzione e delle finestre dell'airdrop, l'indirizzo di burn, i formati dei messaggi
• I collegamenti: i feed di prezzo, i pool su cui compra lo stock router su Ethereum, l'OFT USDG, gli endpoint LayerZero del bridge, l'hub remoto, il pool Curve. Sono fissati al deploy o scritti una sola volta; cambiarne uno significa puntare a un altro contratto, il che richiede un upgrade

Gli upgrade

Dal 2026-10-02 ogni modulo è un proxy che riceve l'upgrade tramite UUPS, tranne i contratti elencati sotto. Come è costruito: vedi Architettura.

• Immediato. Un upgrade ha effetto nella transazione che lo esegue: nessun timelock, nessun preavviso, come per le impostazioni e il trasferimento di emergenza
• Controllato. Solo l'owner del protocollo può fare un upgrade. Una nuova implementazione deve rispondere alla stessa autorità di upgrade, e quelle dell'hook e del registratore della detenzione devono mantenere lo stesso PoolManager
• Mercato per mercato. Ogni vault è un proxy a sé. Una nuova implementazione dei vault indicata nella factory vale per i mercati creati in seguito; i vault esistenti ricevono l'upgrade uno per uno
• Storage in sola aggiunta, mai riordinato. Il layout dello storage di ogni modulo è registrato, e uno script lo verifica prima di ogni upgrade, a ogni livello di ogni struct dal 2026-10-05

Questi contratti non sono upgradabili:

• I token, i token di mercato e $STOCKFUN: semplici ERC-20 la cui supply viene coniata una sola volta, senza mint, burn, pausa né blacklist. Il loro unico setter, setRecorder, e i loro rescue appartengono all'owner del protocollo
• Il lock della liquidità, il cui codice è ciò che mantiene la liquidità nei pool. La sua unica uscita per la liquidità è la modalità di chiusura; i suoi rescue non raggiungono né le posizioni né le quote che conserva
• Il deployer dei vault speculari, su Robinhood Chain: l'indirizzo di ogni vault speculare deriva dal suo

I due deployer su Ethereum, che non detengono alcuno stato, vengono sostituiti tramite la factory anziché ricevere un upgrade.

La modalità di chiusura

L'unica uscita del lock della liquidità, aggiunta il 2026-10-02 per il caso in cui il progetto chiuda. L'owner di StockFun chiama end(). Da quel momento nessun nuovo mercato può essere lanciato, mentre il trading continua su ogni pool. Trenta giorni dopo l'owner può recuperare l'intera liquidità di ogni pool, verso qualsiasi indirizzo. L'owner può annullare in qualsiasi momento finché la chiusura è in sospeso; i pool già recuperati restano vuoti. I 30 giorni sono il preavviso degli holder. Dettagli in Il lancio a due posizioni.

Dipendenze esterne

Nessuna di queste dipendenze è nascosta, e nessuna può spostare un asset fuori da un vault verso un indirizzo.

Rischi accettati

• Un upgrade, un cambio di impostazione e un trasferimento di emergenza hanno effetto subito: gli holder non ne ricevono alcun preavviso, a differenza della modalità di chiusura, annunciata 30 giorni prima
• Ogni trasferimento di token dipende dal registratore della detenzione: una notifica che fallisce fa fallire il trasferimento. È l'unica eccezione voluta alla regola secondo cui un guasto non blocca mai il resto: una notifica a cui fosse permesso fallire lascerebbe che un holder saltasse il registro e aumentasse la propria quota dell'airdrop. Le sue leve sono immediate: setRecorder(0) sul token, o un upgrade sul posto del registratore
• Una quota il cui destinatario la rifiuta attende quel destinatario, sull'hook, sul lock, sull'hub remoto o sul contratto dell'airdrop, invece di fermare il resto; e un trasferimento di emergenza non imputato ad alcun mercato fa attendere i pagamenti di quell'asset finché non viene sistemato
• Nessuna tesoreria si accumula: tutto viene distribuito, e un airdrop può essere zero se nessuno fa trading
• L'airdrop è pagato in azioni wrapped su Ethereum: valgono solo quanto le azioni bloccate su Robinhood Chain e la configurazione LayerZero, e un congelamento degli Stock Token da parte del loro emittente immobilizzerebbe le azioni bloccate
• Un mercato potrebbe non esaurire mai la sua prima banda di liquidità
• Un'andata e ritorno costa il 9,75 % prima di qualsiasi movimento di prezzo, con la tassa di default del 5 %
• Il rail cross-chain non era stato messo alla prova in condizioni reali al momento della stesura di questo libro