Modalità di emergenza

Dal 2026-08-29, l'owner di StockFun può spostare gli asset di una tesoreria, o di qualsiasi contratto che detiene i fondi del protocollo, verso qualsiasi indirizzo. Dal 2026-10-05 il trasferimento è immediato: nessun preavviso, nessun periodo di attesa, e nessuna impostazione può aggiungerne uno. È la modifica più carica di conseguenze del progetto, e ha cambiato ciò che il prodotto è autorizzato a dire.

Cosa consente

emergencyTransfer(asset, amount, to), chiamata sul contratto che detiene l'asset, sposta quell'importo di qualsiasi asset — ETH, USDC, USDG, azioni tokenizzate, token dei mercati — verso to, subito. Cinque contratti ne dispongono: il TreasuryVault, il BridgeHub e, dal 2026-10-04, il contratto dell'airdrop, AirdropDistributor, su Ethereum; il RemoteHub e i vault speculari su Robinhood Chain. Solo il loro admin di emergenza può chiamarla: l'owner della factory su Ethereum e, su Robinhood Chain, lo stesso indirizzo così come l'ha trasportato l'ultimo batch del bridge. L'owner può usarla su ognuno di questi contratti, in qualsiasi momento.

Ogni trasferimento riceve un id sequenziale ed emette un evento pubblico, EmergencyExecuted, con l'asset, l'importo e il destinatario. Nulla lo annuncia prima.

Fino al 2026-10-05 l'owner programmava lo spostamento: un evento pubblico lo annunciava, l'owner poteva annullarlo per 48 ore, e in seguito chiunque poteva eseguirlo. Quella programmazione non esiste più, e il periodo di attesa non è un parametro: un'emergenza agisce non appena l'owner la usa, mai dopo un'attesa. Con essa scompare l'eccezione prevista per i fondi dell'airdrop bloccati in un vault speculare, che non è mai stata implementata: il trasferimento immediato li copre già.

Accanto a questo: una pausa delle conversioni e del bridging — immediata, senza spostare fondi — e la sostituzione dell'adapter del bridge per gli invii futuri, changeAdapter, anch'essa immediata dal 2026-10-05. Sul contratto dell'airdrop, la pausa ferma gli invii, l'apertura dei cicli (openCycle) e il collocamento delle azioni messe da parte (assignUnassigned); non sposta nulla e non ferma mai una riscossione.

Dal 2026-10-01 un hub remoto in pausa applica comunque i cambi di keeper e di admin di emergenza che ogni batch trasporta, così un cambio di owner raggiunge sempre Robinhood Chain; il cash che riceve nel frattempo vi attende, registrato per mercato, fino a uno sweep dopo la fine della pausa.

L'audit di sicurezza del 2026-09-29 ha rilevato che la sostituzione dell'adapter non può funzionare da un capo all'altro: l'hub remoto accetta solo i batch dell'adapter originale, quindi ogni batch inviato dopo una sostituzione resterebbe in attesa sull'hub remoto finché la modalità di emergenza non lo recuperasse (M-2). Il 2026-10-05 l'owner ha deciso di lasciare le cose come sono: un adapter si cambia facendone l'upgrade sul posto, allo stesso indirizzo, e un nuovo indirizzo richiederebbe prima un upgrade dell'hub remoto per accettarlo.

Su un vault, dalla pipeline di sicurezza del 2026-10-01, un trasferimento di emergenza che fa scendere il cash sotto le riserve delle azioni le azzera tutte: ciò che resta, e ogni afflusso successivo, viene ripartito da capo secondo i pesi del basket. Un'emergenza che prende solo cash non riservato, o un altro asset, le conserva. Il cash spostato fuori e poi rimandato a un vault viene ripartito come qualsiasi afflusso, non restituito all'azione a cui era riservato.

Il secondo round dell'audit, il 2026-10-01, ha rilevato che sull'hub remoto un'emergenza che prende cash già registrato per un mercato lascia la registrazione al suo posto, da pagare con il cash di altri mercati (R2H-1). Dal 2026-10-05 a un trasferimento segue una sistemazione dei conti (vedi più avanti), e quel caso è coperto dai suoi strumenti più una procedura: sul rail canonico, l'owner di StockFun mette in pausa l'hub remoto prima del trasferimento. Dal quarto ciclo di audit di quel giorno, un trasferimento può anche essere imputato a un solo mercato, i cui conti vengono sistemati nella stessa chiamata.

Dopo un trasferimento: sistemare i conti

Dal 2026-10-05, dopo i cicli di audit di quel giorno. Il trasferimento in sé non cambia: immediato, senza alcuna condizione. Ma due contratti detengono asset che coprono ciò che è dovuto a più mercati: il contratto dell'airdrop e l'hub remoto. Dopo un trasferimento fuori dall'uno o dall'altro, i conti vengono sistemati, mai pagati a spese di un altro mercato. O gli asset tornano, o l'owner di StockFun imputa la perdita al mercato che l'ha subita.

Entrambi i contratti conteggiano ciò che copre i loro conti, mai il loro saldo. Il saldo comprende anche token arrivati ma non ancora accreditati: una consegna di azioni il cui ultimo passaggio su Ethereum non è stato eseguito o, sul rail USDG, il cash di un batch il cui ultimo passaggio su Robinhood Chain non è stato eseguito. Quei token non coprono ancora nulla, e possono appartenere a un altro mercato. Fino al secondo ciclo di audit del 2026-10-05 i contratti leggevano il saldo, quindi tali token potevano riaprire le riscossioni di un ciclo svuotato e pagarle con le azioni di un altro mercato.

Un trasferimento di emergenza prende innanzitutto da ciò che copre i conti. I token non si possono distinguere tra loro, e considerare usciti per primi quelli accreditati non fa mai fare a un mercato le spese di un altro. Ciò che prende oltre quanto copre i conti proveniva da token non ancora accreditati: il contratto lo registra (taken, cashTaken), e le consegne successive di quell'asset lo ripianano prima di coprire qualsiasi cosa.
Gli asset tornano tramite restore. Chiunque può chiamarla; preleva i token dal chiamante. Un semplice trasferimento verso il contratto non copre nulla. Dal terzo ciclo di audit del 2026-10-05, restore restituisce prima ciò che un trasferimento ha preso oltre a ciò che copre i conti (taken, cashTaken), e copre i conti con il resto: i token di una consegna ancora in attesa non pagano mai un mercato svuotato.
Token dispersi. I token che hanno raggiunto il contratto dell'airdrop, o l'hub remoto sul rail USDG, senza mai essere accreditati, inviati lì per errore, vengono anch'essi scalati da ciò che copre i conti se un trasferimento di emergenza li porta fuori. Un trasferimento di emergenza li porta fuori solo per ripristinarli; altrimenti il loro importo va imputato al ciclo o al mercato su cui ricade, o azzerato con un upgrade.
Il contratto dell'airdrop tiene il conto, azione per azione, di ciò che deve e di ciò che lo copre, e paga un'azione solo finché ciò che lo copre è sufficiente per ciò che deve. Dopo un trasferimento che ha preso una parte di un'azione, le riscossioni di quell'azione attendono, in ogni mercato che la detiene, finché l'azione non torna tramite restore o finché l'owner non imputa la perdita al ciclo che l'ha subita (writeDownCycle), o alle azioni che un mercato tiene da parte (writeDownUnassigned). Finché nessuno ha riscosso quell'azione dal ciclo, l'owner può stralciarne una parte qualsiasi, e ogni holder del ciclo perde nella stessa proporzione; una volta pagati alcuni holder, l'owner può solo stralciare l'intero residuo, che perdono gli holder non ancora pagati, oppure far tornare l'azione. 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. Nessun altro ciclo ne fa le spese. Dal quarto ciclo di audit una riscossione differisce solo l'azione che attende (ClaimDeferred) e paga le altre nella stessa chiamata; fino ad allora falliva per intero. Il contratto dell'airdrop non ha un trasferimento imputato a un solo ciclo: il suo limite di dimensione non lasciava spazio. La procedura che non lascia mai i suoi conti scoperti imputa prima la perdita al ciclo, o alle azioni messe da parte, e poi sposta l'azione; un trasferimento fatto prima mantiene l'attesa generale descritta sopra.
L'hub remoto, sul rail USDG, conteggia il cash che copre ciò che deve e rifiuta di pagare (sweep) finché questo è insufficiente. Dopo un trasferimento che ha preso più di questo, i batch successivi vengono registrati invece che consegnati finché non lo hanno compensato. L'owner fa tornare il cash (restore), oppure stralcia un importo andato perso, o che il trasferimento ha consegnato a mano al vault speculare del mercato (writeOffPending). Dal quarto ciclo di audit l'owner può anche imputare un trasferimento a un solo mercato: emergencyTransferFromPending(marketId, amount, to) sposta ciò che l'hub deve a quel mercato e lo stralcia nella stessa chiamata, così i conti non restano mai scoperti e nessun altro mercato attende.
L'hub remoto, sul rail canonico, deve le registrazioni della sua coda e non tiene alcun conteggio del genere: la protezione è una procedura. L'owner mette in pausa l'hub prima del trasferimento, sposta il cash, elimina la registrazione a cui apparteneva quel cash (writeOffRecord), poi toglie la pausa, così la coda non paga mai quella registrazione una seconda volta con il cash di un altro mercato. Dal quarto ciclo di audit una sola chiamata lo fa per una registrazione: emergencyTransferRecord(index, to) sposta l'intero importo della registrazione e la elimina. Dal quinto, quella chiamata è per una registrazione il cui deposito è arrivato: il cash della coda è comune, per cui rifiuta un importo oltre il cash non trattenuto per le quote rifiutate (RecordNotCovered); una registrazione il cui deposito è andato perso viene eliminata con writeOffRecord. Una quota che un vault speculare ha rifiutato, tenuta a parte per il suo mercato (undeliverable), viene spostata e stralciata con emergencyTransferFromPending.

Ogni stralcio emette un evento pubblico (WrittenDown, PendingWrittenOff), e lo stesso fa ogni ritorno (Restored) e ogni riscossione differita (ClaimDeferred).

Rescue: ciò che un modulo detiene per errore

Dal 2026-10-05, in base alla regola del fondatore secondo cui tutto ciò che può detenere fondi ha una leva (vedi Architettura), i contratti senza modalità di emergenza hanno un proprio rescue, per ciò che è stato inviato loro per errore o lasciato da un'operazione fallita. Solo l'owner di StockFun lo chiama: l'owner della factory su Ethereum, l'admin dell'hub remoto su Robinhood Chain, lo stesso indirizzo che fa l'upgrade dei moduli. Ogni rescue emette un evento pubblico.

I moduli che non conservano nulla di nessuno tra una transazione e l'altra — la factory, la Lens, gli oracoli, il registratore della detenzione, gli stock router, il router di swap ufficiale e gli adapter del bridge — hanno rescue(asset, amount, to), per l'ETH (l'indirizzo zero) o qualsiasi token
L'hook porta fuori solo ciò che è disperso: al massimo l'ETH inviatogli da chiunque non sia il PoolManager (strayEth), e qualsiasi token, poiché non ne detiene mai. I saldi dei creatori, del team e del buyback e i debiti verso i vault non escono mai per quella via. L'ETH forzato senza chiamata non viene contato, e attende un upgrade
Il lock della liquidità, che non è upgradabile, porta fuori qualsiasi token, e l'ETH oltre le quote che conserva per vault e creatori (totalOwed), che non escono mai per quella via; dal quinto ciclo di audit anche i claim v4 accreditati a suo favore nel PoolManager (rescueClaims) e un NFT inviatogli con un semplice trasferimento (rescueNft). Non ha alcuna chiamata generica: attraverso il PoolManager, si potrebbe arrivare al recupero della modalità di chiusura senza i suoi 30 giorni. Le sue posizioni restano raggiungibili solo tramite la modalità di chiusura
Il BuybackBurner porta fuori un token in qualsiasi momento, e il suo ETH solo quando nessun burn potrebbe più spenderlo: prima che il mercato del protocollo venga indicato, o una volta che la modalità di chiusura ha recuperato il pool di $STOCKFUN. Finché quel pool è bloccato, il suo ETH esce solo tramite i burn
I token, che non sono upgradabili, portano fuori ciò che è stato inviato al loro stesso indirizzo: i loro stessi token, notificati al registratore della detenzione come qualsiasi trasferimento, qualsiasi altro token, l'ETH forzato e, dal quinto ciclo di audit, i claim v4 e gli NFT (rescue, rescueClaims, rescueNft). Nessun saldo di un holder può muoversi per quella via
I contratti di implementazione dietro i proxy non vengono mai usati direttamente. Su quelli della factory e dell'hub remoto, che tengono il loro admin nello storage del proxy, la leva per ciò che viene inviato al loro stesso indirizzo è l'indirizzo che ne ha fatto il deploy; ogni altra implementazione legge il proprio admin tramite la sua autorità, l'owner del protocollo

I vault, i due hub e il contratto dell'airdrop mantengono invece la modalità di emergenza, poiché tengono conti propri. I due deployer su Ethereum e il deployer dei vault speculari non detengono stato, non accettano ETH e non hanno owner: non hanno bisogno di leve.

Cosa non consente

La modalità di emergenza non tocca il registro dei feed. Sposta asset; non cambia i limiti di esecuzione, che sono impostazioni separate dell'owner. Non può far comprare a un vault qualsiasi cosa a qualsiasi prezzo; può prendere, subito, ciò che c'è in un vault.

Non può nemmeno toccare la liquidità bloccata né i token degli holder. Lo stesso vale per l'airdrop: la modalità di emergenza può spostare le azioni del contratto dell'airdrop, ma non può cambiare come un ciclo viene ripartito tra i suoi holder. Le quote restano come sono; dal 2026-10-05 una riscossione viene pagata solo finché ciò che copre i conti del contratto è sufficiente per tutto ciò che deve in quell'azione, e una perdita che non rientrerà viene imputata al ciclo che l'ha subita, mai a un altro (vedi sopra).

Non è però l'unica via dell'owner verso un vault. Dal 2026-10-02 l'owner di StockFun può anche fare l'upgrade di un vault, o dell'oracolo che il vault legge, con effetto immediato. La liquidità bloccata ha una propria uscita, la modalità di chiusura, annunciata con 30 giorni di anticipo: l'unico periodo di attesa fisso del protocollo. Vedi Modello di fiducia.

Perché esiste

La revisione dei modi di guasto cross-chain ha posto una domanda semplice: cosa succede quando un percorso fallisce, un messaggio del bridge va perso, o un contratto ha un bug?

Senza un percorso di recupero la risposta è "i fondi sono persi, definitivamente". Il protocollo ha scelto un percorso di recupero controllato, detenuto dal suo owner e registrato onchain, piuttosto che l'eleganza di un sistema che non può riparare nulla. Dal 2026-10-05 quel percorso agisce non appena viene usato.

Dal 2026-10-01 è anche il modo in cui il cash di un mercato il cui basket è stato rifiutato da Robinhood Chain esce dal vault speculare di quel mercato, che resta non inizializzato: vedi Il rail Robinhood.

Quanto costa

L'owner può spostare gli asset di una tesoreria verso qualsiasi indirizzo, subito e senza preavviso. È scritto nel modello di fiducia del progetto.

Soprattutto, la formulazione validata sostituisce ogni promessa precedente.

Gli asset sono detenuti dal vault del mercato e governati dalle sue regole. Il team StockFun può spostare gli asset di una tesoreria in caso di emergenza, dopo un periodo di attesa pubblico di 48 ore.

Dal 2026-10-05 il periodo di attesa di questa frase non esiste più: il trasferimento è immediato. La frase è da rivedere, e la sua nuova formulazione da validare. Dal 2026-10-02 non copre nemmeno gli upgrade dei vault, che hanno effetto subito.

Il prodotto non può più dire non-custodial, trustless, tesoreria immutabile o nessuno può toccare la tesoreria. Queste espressioni sono bandite dalle regole di branding; l'audit automatico dei testi non le verifica, la revisione sì.

La modalità di emergenza non viene mai descritta come una protezione o una garanzia contro le perdite. È un potere detenuto dal team, con effetto immediato. Niente di più.

Cosa vede l'utente

Fino al 2026-10-05 un banner doveva annunciare un recupero programmato su ogni superficie interessata, con la data di esecuzione. Un trasferimento è ora immediato, quindi non c'è nulla da annunciare in anticipo: diventa visibile a cose fatte, nell'evento EmergencyExecuted del contratto da cui è uscito.