Blog

Il 30 ottobre 2026 Bitcoin è sceso sotto i 78.000 dollari in una giornata segnata dall’attacco informatico a Binance. Il furto è stato stimato in 6,3 miliardi di dollari ed è indicato come il maggiore caso di frode nel settore delle criptovalute finora registrato. Per il mercato degli asset digitali, l’episodio riporta al centro un rischio che le fasi di espansione tendono a lasciare sullo sfondo: la sicurezza delle infrastrutture alle quali gli utenti affidano negoziazione e custodia.

Binance ha sospeso temporaneamente i prelievi e ha dichiarato di avere congelato circa 3 miliardi di dollari dei fondi coinvolti. L’exchange ha inoltre affermato che i fondi degli utenti sono al sicuro e che coprirà tutte le perdite con risorse proprie. Si tratta, per ora, di impegni comunicati dalla piattaforma: non definiscono autonomamente l’esposizione residua né sostituiscono gli esiti dell’indagine. Binance ha annunciato un rapporto tecnico dettagliato al termine degli accertamenti.

Le cifre richiedono una distinzione precisa. I 6,3 miliardi di dollari rappresentano la stima del valore sottratto, mentre i circa 3 miliardi riguardano fondi che Binance dichiara di essere riuscita a congelare. La distanza fra i due importi non permette di stabilire quali somme potranno essere recuperate, quali restino movimentabili o quale sarà il costo finale dell’incidente per l’exchange. Sono aspetti che dipenderanno dalla ricostruzione tecnica e finanziaria dell’attacco.

Il gruppo Lazarus, ritenuto legato alla Corea del Nord, è stato identificato come responsabile dell’operazione. L’attribuzione resta un elemento rilevante, ma non chiarisce da sola le modalità dell’intrusione, gli strumenti utilizzati, la durata dell’eventuale accesso ai sistemi né il percorso seguito dai fondi dopo il furto. Questi dettagli non sono stati resi disponibili e saranno centrali per comprendere le vulnerabilità emerse e la risposta della piattaforma.

La sospensione dei prelievi evidenzia il compromesso che si crea durante una crisi di sicurezza presso un intermediario centralizzato. Il blocco può servire a contenere ulteriori trasferimenti e a preservare le risorse coinvolte; nello stesso tempo, limita temporaneamente la possibilità degli utenti di disporre dei propri asset. In un exchange centralizzato, la piattaforma svolge funzioni operative essenziali per l’accesso al mercato e per la custodia. Quando tali funzioni subiscono un incidente, la rapidità dell’intervento diventa decisiva, ma la continuità del servizio può essere interrotta proprio per ragioni di protezione.

Il calo di Bitcoin sotto i 78.000 dollari va descritto come un movimento verificatosi nel contesto dell’attacco, senza presentarlo come prova di un rapporto causale esclusivo. Le quotazioni degli asset digitali dipendono da molteplici fattori, tra cui domanda e offerta, liquidità e posizionamento degli operatori. Un incidente che coinvolge un grande exchange può tuttavia accrescere l’incertezza sul rischio di controparte: il rischio, cioè, che un intermediario non riesca temporaneamente a garantire l’operatività o ad adempiere ai propri obblighi verso i clienti.

La tensione ha interessato anche il mercato azionario, con pressione al ribasso sulle azioni tecnologiche e una maggiore avversione al rischio tra gli investitori. Anche qui non è possibile ricavare dal solo andamento simultaneo una causa unica della debolezza dei listini. Il dato segnala però che un evento di sicurezza di queste dimensioni può inserirsi in un clima più ampio di cautela, nel quale gli investitori riducono l’esposizione alle attività percepite come più rischiose o sensibili all’innovazione tecnologica.

Per utenti e imprese, la vicenda richiama una differenza concreta tra proprietà di un asset e disponibilità operativa immediata. Conservare criptovalute presso un intermediario può semplificare l’accesso alla negoziazione e alle conversioni, ma espone anche alle conseguenze di procedure interne, interruzioni del servizio o incidenti di sicurezza. La custodia diretta riduce la dipendenza da un exchange, ma trasferisce al titolare la responsabilità della protezione delle credenziali necessarie a movimentare gli asset. Non è una scelta priva di rischi: cambiano il soggetto responsabile e il tipo di protezione richiesto.

L’impegno di Binance a coprire le perdite con fondi propri è quindi il punto più sensibile sul piano della fiducia. La sua effettiva tenuta potrà essere valutata solo con informazioni più complete sull’ammontare definitivo del danno, sulla quota congelata e sulle misure adottate dopo l’attacco. Il rapporto tecnico annunciato dovrà chiarire quanto accaduto senza anticipare conclusioni su componenti dell’infrastruttura che non sono state finora dettagliate.

L’episodio mostra che la crescita della finanza digitale non elimina la necessità di valutare la resilienza degli intermediari. La tecnologia blockchain può registrare trasferimenti sulle reti pubbliche, ma la tracciabilità non equivale automaticamente al recupero dei fondi, all’identificazione certa dei responsabili o al rimborso dei clienti. Nel caso Binance restano aperte le domande sulla protezione effettiva degli utenti durante la sospensione dei prelievi, sul recupero delle somme coinvolte e sulla capacità dell’exchange di rispettare l’impegno dichiarato. La risposta sarà giudicata non soltanto per le somme recuperate, ma anche per la chiarezza con cui verranno spiegate le vulnerabilità e le contromisure adottate.

BitGo e Jupiter hanno annunciato un’integrazione che, nelle intenzioni delle società, permetterà ai clienti istituzionali di BitGo di effettuare staking di SOL attraverso il validatore Jupiter senza uscire dai conti di custodia già utilizzati. L’annuncio, datato 28 ottobre 2026, porta una funzione nativa della rete Solana dentro un flusso pensato per operatori che gestiscono asset digitali con procedure di custodia e autorizzazione strutturate.

Lo staking è uno dei meccanismi con cui una blockchain proof-of-stake come Solana viene supportata. I possessori di SOL possono delegare i token a un validatore, ossia un soggetto che partecipa alla validazione delle transazioni e al funzionamento della rete. In cambio della partecipazione, il protocollo prevede ricompense di staking. Jupiter, nota per servizi di finanza decentralizzata su Solana, afferma di operare anche un validatore; è questa componente dell’infrastruttura a essere collegata ai servizi di BitGo.

Il punto dell’accordo non è una modifica delle regole di Solana, ma dell’accesso operativo allo staking. Per chi conserva SOL presso BitGo, la delega al validatore Jupiter dovrebbe poter avvenire nello stesso ambiente di custodia, evitando il passaggio verso un fornitore separato. Secondo le due società, questa impostazione è destinata a ridurre la complessità connessa alla gestione di asset presso più operatori e a inserire lo staking nei processi già adottati dalla clientela istituzionale.

La distinzione è rilevante perché custodia e partecipazione a una rete blockchain rispondono a esigenze diverse. La custodia riguarda la conservazione e la gestione dell’accesso agli asset; lo staking riguarda invece la delega dei token a un validatore. Riunire le due attività nella medesima infrastruttura può rendere più lineare l’operatività, ma non trasforma lo staking in un prodotto privo di rischi né modifica l’esposizione dell’investitore a SOL.

Le ricompense sono infatti denominate nell’asset della rete e il loro valore in valuta tradizionale dipende anche dal prezzo di SOL, che può variare. Inoltre, il risultato economico dello staking dipende dalle regole del protocollo e dal funzionamento del validatore. La possibilità di ricevere ricompense non equivale quindi a un rendimento fisso o garantito. La scelta del validatore resta un elemento rilevante, poiché collega la delega dell’utente all’operatività dell’infrastruttura che contribuisce alla rete.

BitGo presenta l’integrazione come un’estensione delle opportunità di staking offerte alla propria clientela istituzionale. Nel comunicato, la società dichiara di offrire custodia regolamentata, conservazione a freddo e protezioni indicate come bankruptcy-remote, oltre a una copertura assicurativa fino a 250 milioni di dollari. L’annuncio non dettaglia però le condizioni applicabili al nuovo servizio, i limiti della copertura, le commissioni, i tempi operativi o i criteri di accesso dei clienti. Questi aspetti restano necessari per valutare concretamente il perimetro della proposta.

Per Jupiter, l’accordo amplia il ruolo attribuito al proprio validatore oltre le attività per cui la piattaforma è maggiormente conosciuta, come scambi, contratti perpetui e lending. Per BitGo, il collegamento aggiunge un’opzione di staking SOL all’interno dell’offerta di infrastrutture per asset digitali. Le due società descrivono l’operazione come un ponte tra la custodia istituzionale e la partecipazione diretta alla rete Solana.

L’annuncio non fornisce dati sui volumi di SOL che potranno essere delegati, sul numero dei clienti interessati o sull’effettivo utilizzo del servizio. Non consente quindi di misurarne l’impatto commerciale o sulla distribuzione dello staking nella rete. Indica tuttavia un passaggio operativo preciso: lo staking, nato come funzione eseguibile direttamente sulla blockchain, viene proposto anche attraverso servizi di custodia rivolti a istituzioni. La portata dell’integrazione dipenderà dalle condizioni rese disponibili ai clienti e dall’esecuzione del servizio, in un contesto in cui restano presenti i rischi di mercato e quelli propri dell’infrastruttura blockchain.

Canton Strategic Holdings (CNTN) ha annunciato un accordo con TSV LLC per rendere disponibili le proprie azioni ordinarie su una piattaforma di trading tokenizzata basata sulla rete Canton. L’avvio delle negoziazioni è previsto per il 2 novembre 2026. L’operazione riguarda quindi le azioni della società, rappresentate e scambiate attraverso un’infrastruttura tokenizzata, non l’emissione di un nuovo criptoasset.

Il modello indicato è quello della tokenizzazione sponsorizzata dall’emittente: è Canton Strategic Holdings a sostenere l’iniziativa relativa ai propri titoli. Secondo l’annuncio, questa struttura evita il processo di obiezione di 30 giorni previsto per terze parti non affiliate. TSV LLC potrebbe così avviare il trading tokenizzato prima dell’iniziativa della joint venture tra OKX e ICE, prevista nel nuovo framework della Securities and Exchange Commission statunitense.

La distinzione procedurale descritta dall’azienda non equivale però a un’esenzione generale dalle regole applicabili ai titoli. Né chiarisce da sola quali tutele, modalità di accesso o condizioni operative saranno disponibili agli investitori. La tokenizzazione può cambiare il modo in cui un’azione viene emessa, registrata e trasferita, ma non definisce automaticamente la titolarità dei diritti, la trasferibilità del titolo, la custodia o la liquidità degli scambi.

Le azioni tokenizzate dovrebbero essere emesse da Fairmint, indicata come agente di trasferimento on-chain. TSV LLC dovrebbe invece ospitare le negoziazioni tramite il protocollo Tradecraft sulla rete Canton. L’architettura annunciata separa dunque almeno sul piano funzionale l’emissione e la registrazione del titolo dalla sede in cui avvengono gli scambi, pur collocando entrambe le attività sulla stessa infrastruttura di rete.

L’annuncio richiama inoltre l’esenzione all’innovazione della SEC, alla quale viene collegata la possibilità di negoziare senza interruzioni, 24 ore su 24 e sette giorni su sette, con regolamento atomico. Quest’ultimo indica un meccanismo nel quale il trasferimento del titolo e quello del corrispettivo avvengono insieme oppure non avvengono. Il suo impiego mira a evitare che una sola parte della transazione sia completata; le condizioni effettive dipenderanno tuttavia dalle regole della piattaforma e dalle modalità con cui il sistema verrà applicato.

L’estensione dell’orario di negoziazione rappresenta una differenza rispetto ai mercati azionari organizzati attorno a finestre temporali definite. Un mercato disponibile in via continuativa non implica però, di per sé, scambi costanti: la liquidità resta legata alla presenza di acquirenti e venditori e alle condizioni con cui gli operatori possono accedere alla piattaforma.

Per chi detiene o intende acquistare le azioni, la novità riguarda soprattutto l’infrastruttura di emissione, registrazione e trasferimento. La rappresentazione tokenizzata non modifica automaticamente il valore economico del titolo né elimina i rischi legati al prezzo, alla liquidità, al funzionamento tecnico o alle controparti coinvolte. Il calendario indicato fissa al 2 novembre 2026 il primo banco di prova dell’iniziativa: sarà allora possibile osservare l’avvio del modello annunciato per le azioni ordinarie di Canton Strategic Holdings.

Tre vulnerabilità di Bitcoin Core, il software open source utilizzato per eseguire nodi della rete Bitcoin, sono state corrette dopo essere state individuate da un’iniziativa di analisi automatizzata basata su modelli linguistici. Due difetti potevano provocare un consumo progressivo della memoria fino all’arresto del nodo; il terzo riguardava file impiegati nella gestione delle riorganizzazioni della blockchain. Gli avvisi non riportano casi di sfruttamento attivo, ma descrivono rischi che potevano compromettere la capacità dei nodi vulnerabili di restare connessi e di elaborare i dati della rete.

Le correzioni sono state distribuite nelle versioni 29.5, 30.4, 31.2 e 32.1 di Bitcoin Core. La pubblicazione degli aggiornamenti è stata seguita a breve distanza dalla divulgazione dei problemi, coerentemente con la politica di sicurezza del progetto per debolezze considerate individuabili con relativa facilità, anche mediante scansioni assistite dall’intelligenza artificiale. Per chi gestisce un nodo, l’aggiornamento riguarda quindi la continuità operativa: un nodo che esaurisce la memoria o si arresta perde la possibilità di rimanere collegato e di svolgere le proprie funzioni sulla rete finché non viene ripristinato.

Il difetto ritenuto più immediatamente sfruttabile interessava nodi in esecuzione su Windows, macOS e BSD. Un peer malevolo avrebbe potuto inviare dati di rete costruiti in modo da aggirare le protezioni previste per limitare il traffico in ingresso. La memoria impiegata dal processo avrebbe potuto crescere fino al crash del software. Linux non era coinvolto in questa specifica vulnerabilità, perché usa un meccanismo diverso per monitorare le connessioni di rete. Il caso mostra come una debolezza di questo tipo non riguardi indistintamente Bitcoin, ma determinate configurazioni del client e dei sistemi operativi sui quali viene eseguito.

Il secondo problema, classificato di gravità media, riguardava la comunicazione con peer meno recenti che non supportano una funzione di rete introdotta dal Bitcoin Improvement Proposal 31. In questo scenario, un peer ostile avrebbe potuto far accumulare senza limite messaggi in uscita. L’impatto indicato raggiungeva fino a 2 megabyte all’ora per ciascuna connessione in entrata e fino a 5 megabyte all’ora per ciascuna connessione in uscita. Il dato non descrive un consumo istantaneo, ma una pressione che può crescere nel tempo fino a esaurire le risorse disponibili del nodo e interromperne la connessione alla rete.

La terza vulnerabilità, valutata a bassa gravità, coinvolgeva i file usati da Bitcoin Core per gestire il ripristino delle transazioni durante una riorganizzazione della blockchain. In circostanze altamente inusuali, un miner avrebbe potuto generare una quantità di dati tale da superare i limiti della posizione nei file, con il rischio di corrompere i registri necessari al processo e di causare l’arresto dei nodi interessati. Sugli ordinari sistemi a 64 bit, lo sfruttamento richiederebbe migliaia di blocchi appositamente costruiti e una riorganizzazione della catena estremamente precisa: condizioni alla base della minore severità attribuita al problema.

Le anomalie sono state rilevate inizialmente da Project Loupe, un’iniziativa di scansione automatizzata fondata sui grandi modelli linguistici e sviluppata da Elias Rohrer presso Spiral. Gregory Sanders ne ha successivamente convalidato i risultati e ha avvisato il team di sicurezza di Bitcoin Core. La prima vulnerabilità è stata individuata l’8 luglio, una seconda il 15 settembre e il difetto relativo all’esaurimento della memoria su Windows e macOS il 23 ottobre. Le patch sono state completate il 26 ottobre e le versioni aggiornate sono state rilasciate nei due giorni successivi.

L’episodio non equivale a una sostituzione della revisione tecnica con l’intelligenza artificiale. Nel percorso descritto, l’analisi automatizzata ha contribuito a individuare possibili anomalie; la convalida, la valutazione dell’impatto e la correzione sono passate attraverso il lavoro degli sviluppatori. Il rilievo della vicenda sta proprio nella combinazione fra strumenti capaci di analizzare una base di codice complessa e una procedura di risposta che porta rapidamente alla distribuzione delle patch. Se difetti di questo genere diventano più semplici da cercare, anche la tempestività degli aggiornamenti diventa un elemento essenziale della sicurezza dell’infrastruttura.

Le patch, tuttavia, non eliminano ogni esposizione nelle configurazioni meno aggiornate. Bitcoin Core ha avvertito che i sistemi a 32 bit e i nodi che archiviano i dati della blockchain su file system FAT32 possono restare vulnerabili al problema di overflow in condizioni specifiche. Le serie 29.x e precedenti hanno inoltre raggiunto la fine del supporto: l’installazione della patch 29.5 non rende queste diramazioni nuovamente mantenute per futuri aggiornamenti. Il passaggio alla versione 32.1 richiede anche macOS 14 o una versione successiva, oppure Windows 10 versione 1903 o successiva; per chi proviene da release obsolete può essere necessaria ulteriore attenzione alla migrazione della directory dei dati.

La vicenda riporta l’attenzione su una componente meno visibile della rete Bitcoin: la sicurezza del software che consente ai nodi di validare transazioni e blocchi e di comunicare tra loro. L’assenza di sfruttamenti attivi segnalati non riduce l’utilità degli aggiornamenti, soprattutto quando le debolezze sono state rese pubbliche dopo il rilascio delle correzioni. Per gli operatori, la distinzione non è soltanto tecnica: mantenere software e sistemi supportati è una condizione pratica per ridurre l’esposizione a problemi già identificati e corretti dal progetto.