Il 31 luglio 2026, tra le 01:31 e le 01:56 UTC, circa 594,48 BTC — oltre 38 milioni di dollari — sono stati prelevati da circa 500 wallet Bitcoin in una finestra di venticinque minuti. Nessun phishing. Nessun malware. Nessun accesso fisico ai dispositivi. L'attaccante ha semplicemente calcolato le chiavi private.
È il tipo di evento che l'industria del cold storage teme da sempre, perché non colpisce l'utente: colpisce il presupposto su cui l'intero modello di sicurezza si regge. Se la casualità con cui viene generato un seed non è realmente casuale, ogni altro strato — secure element, air gap, PIN, anti-tampering — diventa decorativo.
Questa è l'analisi di cosa è successo, perché è successo, e quali domande ogni possessore di cold wallet dovrebbe porsi da oggi in avanti.
Nella notte tra il 30 e il 31 luglio 2026, un attaccante ha eseguito uno sweep coordinato su circa 500 wallet single-signature Bitcoin. Secondo la ricostruzione on-chain riportata da CoinDesk, i fondi sono stati prelevati con circa 500 transazioni; 562 BTC sono stati successivamente consolidati su un unico indirizzo, rimasto poi fermo. Rob Hamilton, CEO di AnchorWatch, ha contato 1.324 output spesi (UTXO) coinvolti nello sweep.
Il totale potrebbe non essere definitivo. Clay Garrett, ingegnere di Block, ha individuato ulteriori 695 transazioni con la stessa firma comportamentale, per 488,1 BTC: se collegate allo stesso attore, il bottino complessivo salirebbe intorno ai 1.082 BTC. Al momento della pubblicazione il collegamento non è confermato.
La causa è stata identificata dai team di Bitcoin engineering e security di Block, che hanno pubblicato la propria analisi tecnica mentre l'attacco era ancora in corso — una scelta esplicitamente motivata dall'urgenza, a testing ancora incompleto. Coinkite, il produttore di Coldcard, ha confermato i risultati e pubblicato un proprio backgrounder tecnico e un advisory ai clienti.
Il verdetto: per anni, i dispositivi Coldcard hanno generato seed phrase con un'entropia effettiva drammaticamente inferiore a quella dichiarata.
Il difetto non è un errore crittografico. È un errore di build — e questo lo rende molto più interessante, e molto più istruttivo.
Il firmware Coldcard è costruito su MicroPython. Sulla board di produzione, la macro di configurazione MICROPY_HW_ENABLE_RNG è impostata a 0: la scelta era intenzionale, perché Coinkite non voleva usare il generatore di MicroPython, bensì un proprio wrapper hardware dedicato al TRNG (True Random Number Generator) del chip.
Il problema è che la libreria crittografica libngu verificava soltanto se la macro esistesse, non quale valore avesse: un #ifndef MICROPY_HW_ENABLE_RNG dove sarebbe servito un #if !MICROPY_HW_ENABLE_RNG. Con la macro definita a zero, il controllo passava comunque, e il codice ricadeva silenziosamente sul generatore software di MicroPython — l'algoritmo deterministico Yasmarang.
Come nota Coinkite nel proprio backgrounder, il problema è che "la versione sbagliata di una funzione chiamata rng_get() è finita nel codice sorgente ed è stata usata praticamente ovunque servisse entropia". Le due implementazioni — quella hardware e quella software — avevano firma identica. Nessun errore di compilazione, nessun warning, nessuna differenza visibile in fase di review.
Ed è qui che il difetto smette di essere teorico. Il seeding del PRNG software si basava su:
c
pad = UID_low32 ^ SysTick->VAL;
n = RTC->TR; // registro orario
d = RTC->SSR; // sottosecondiTradotto: numero seriale del chip (dato di fabbrica, fisso, non segreto) e registri di clock (stato temporale che un attaccante può restringere o misurare). Nessuna di queste è una sorgente crittografica. Sono metadati. Block precisa inoltre che questi valori vengono inizializzati una sola volta, alla prima chiamata di rng_get(), e che da quel momento non viene mai raccolta nuova entropia.
Per un dispositivo di cui si conosca l'UID e si possano stimare le condizioni di boot, la generazione del wallet diventa completamente deterministica.
Modello | Firmware | Entropia effettiva | Fonte |
|---|---|---|---|
Mk2 / Mk3 | v4.0.0 – v4.1.9 | ~40 bit (invece di 128) — generazione deterministica | Coinkite / Block |
Mk4 / Mk5 | precedenti a 5.6.0 | ~72 bit (Coinkite) / ~2³¹ tentativi medi per il reseed (Block) | Coinkite / Block |
Q | precedenti a 1.5.0Q | come sopra | Coinkite |
Mk1, e Mk2/Mk3 fino a v3.2.2 | — | non interessati | Block |
Nota sull'intervallo Mk3. Le fonti non concordano sul limite superiore. Il backgrounder tecnico di Coinkite e l'analisi di Block indicano v4.0.x–v4.1.9; l'advisory Coinkite dedicato all'Mk3 estende però il rischio fino a v5.0.3, l'ultima release per quel modello. In dubbio, tratta come affetto qualunque seed generato su Mk3 dal 4.0.1 in poi. Si consideri inoltre che il primo advisory Coinkite dichiarava Mk4/Mk5/Q "non affetti sulla base dell'analisi preliminare": posizione poi ribaltata dal backgrounder tecnico. Questa tabella riflette la posizione più recente.
Per Mk2/Mk3, Block quantifica lo spazio di ricerca in circa 2⁴⁰·⁷, che scende fino a ~2¹⁶·³ se l'RTC risulta stabile durante un cold boot — una cifra alla portata di un laptop. Per Mk4, Q e Mk5 l'entropia del secure element era comunque presente (40 byte: 32 da SE1, 8 da SE2), ma troncata a quattro byte dopo l'hashing SHA256d che alimentava il reseed — una riduzione sufficiente a rendere la ricerca computazionalmente affrontabile.
Un dettaglio spesso trascurato: il difetto non riguarda solo i seed. Secondo l'analisi di Block, lo stesso percorso RNG alimentava anche chiavi private secp256k1 dei paper wallet, maschere Seed XOR, chiavi ECDH effimere per cloning, cifratura USB e Key Teleport, password delle Secure Notes, segreti e nonce Web2FA.
Maggio 2018 — il codice di fallback Yasmarang entra in MicroPython upstream (commit f68e722, "stm32/rng: Use Yasmarang for rng_get() if MCU doesn't have HW RNG").
1 marzo 2021 — commit b18723dd: la migrazione di libreria che attiva di fatto il fallback nella generazione dei seed. Il firmware v4.0.0 viene rilasciato il 17 marzo 2021; Coinkite fissa l'esposizione degli utenti a partire da 4.0.1.
30 luglio 2026 — Block identifica la causa radice.
31 luglio 2026, 01:31 → 01:56 UTC — lo sweep.
Oltre cinque anni tra l'introduzione del difetto e il suo sfruttamento pubblico.
Coinkite è stata trasparente su questo punto: le review precedenti avevano verificato che il codice TRNG fosse presente nel binario, ma non avevano tracciato quale delle due implementazioni venisse effettivamente eseguita durante la generazione del seed. Firme identiche, risoluzione a build time, nessun segnale.
Il contributor di Bitcoin Core noto come instagibbs ha confermato il difetto riproducendolo su un Mk3 appena inizializzato.
Coinkite ha dichiarato di ritenere che "qualcuno abbia usato l'AI per revisionare le versioni precedenti del nostro firmware".
Il dettaglio che rende la vicenda emblematica: poche settimane prima dell'attacco, Coinkite aveva condotto una propria review di sicurezza assistita da AI, usando — a loro dire — uno dei migliori modelli disponibili sul proprio codebase. Quell'analisi non aveva trovato questo bug né altro di serio.
Lo stesso strumento, nelle mani di difensore e attaccante, ha prodotto risultati opposti. Non perché il modello fosse peggiore per il difensore, ma perché l'attaccante aveva un vantaggio strutturale: poteva permettersi di analizzare anni di versioni firmware storiche, cercando la singola discrepanza, senza vincoli di tempo, ambito o costo.
La lezione operativa non è "l'AI è pericolosa". È che lo storico completo del firmware di un dispositivo chiuso è una superficie d'attacco, e che il costo marginale di analizzarlo è appena crollato.
Va segnalato per completezza: la portata esatta resta in via di definizione. Max Guise, responsabile dello sviluppo di Bitkey in Block, ha avvertito che il difetto tocca un insieme di modelli più ampio di quanto inizialmente comunicato — Mk2, Mk3, Mk4, Q e Mk5 — con severità variabile, e che il rischio si estende anche a configurazioni multisig in cui più chiavi siano state generate su dispositivi affetti. Guise ha confermato che i prodotti Block, incluso Bitkey, non sono coinvolti. Coinkite ha inoltre precisato che TAPSIGNER, OPENDIME e SATSCARD usano codebase separati e non sono interessati.
Prima di ogni considerazione architetturale, la parte pratica. Un aggiornamento firmware non ripara un seed già generato. La matematica è già stata fatta; gli indirizzi esistono già.
Considera compromesso ogni seed generato su Mk3 con firmware 4.0.1 o successivo. Coinkite avverte tutti gli utenti che hanno generato un seed su Mk3 con la versione 4.0.1 (marzo 2021) o qualunque versione successiva che i loro fondi potrebbero essere a rischio.
Mk4 / Mk5 / Q: aggiorna a 5.6.0+ (o 1.5.0Q+), poi genera un seed completamente nuovo e trasferisci i fondi.
Migra, non rigenerare l'indirizzo. Servono un seed nuovo e indirizzi nuovi. Spostare la stessa seed phrase su un altro wallet non risolve nulla.
Verifica il fingerprint del wallet prima di muovere fondi.
Attenzione alle passphrase deboli. Guise ha avvertito che il rischio persiste anche dopo il trasferimento della recovery phrase, in particolare per wallet protetti da passphrase facilmente indovinabili.
Controlla i backup su carta e i paper wallet generati con lo stesso dispositivo: condividono la stessa sorgente di casualità.
Se usi multisig, verifica l'origine di ogni chiave. Il multisig protegge solo se le chiavi provengono da sorgenti di entropia realmente indipendenti.
È tentante trattare l'incidente come un bug isolato. Non lo è. È l'espressione di tre scelte architetturali che l'intero settore del cold storage hardware ha adottato come standard:
Sorgente di entropia unica. Se quella sorgente fallisce silenziosamente, non c'è ridondanza.
Firmware embedded chiuso, compilato, con risoluzione dei simboli a build time. Il difetto era invisibile perché il linker sceglieva l'implementazione sbagliata senza segnalarlo.
Nessun percorso di verifica indipendente per l'utente. Nessun possessore di Coldcard aveva modo di controllare se il proprio seed fosse stato generato con entropia reale.
XColdPro nasce da premesse diverse su tutti e tre i punti. Non perché sia immune — nessun software lo è, e lo diremo esplicitamente più avanti — ma perché la classe di guasto che ha colpito Coldcard incontra qui una struttura differente.
XColdPro non si affida a un solo generatore. Ogni seed phrase nasce da un pool alimentato da più classi indipendenti di casualità — hardware, sistema operativo, input umano e ambientale — in modo che nessuna di esse, da sola, determini il risultato. L'insieme esatto delle sorgenti, il loro peso e il modo in cui vengono combinate sono dettagli implementativi che scegliamo deliberatamente di non pubblicare; ciò che conta sul piano architetturale è la proprietà che ne deriva, dichiarata nel manuale in una riga che, alla luce di oggi, si legge in modo diverso:
"…la compromissione di una singola sorgente di entropia non compromette la sicurezza della seed phrase."
Questa è esattamente la contromisura al fallimento di Coldcard. Nel modello Coldcard, il fallback silenzioso dal TRNG al PRNG software ha collassato l'intero spazio delle chiavi. In un modello a pool multi-sorgente, il cedimento di una sorgente degrada l'entropia; non la azzera. Perché il seed diventi predicibile occorrerebbe il cedimento simultaneo di tutte le classi — sorgenti che non condividono né implementazione né fornitore né superficie di guasto.
Il difetto Coldcard è esistito perché due funzioni con firma identica sono state risolte in modo errato durante la compilazione, sotto il controllo di una macro del preprocessore C valutata scorrettamente.
XColdPro è scritto in Python, senza dipendenze JavaScript o npm. Questa scelta era stata pensata principalmente contro gli attacchi alla supply chain — ma ha una conseguenza rilevante anche qui: non esiste un preprocessore, e la risoluzione dei simboli non avviene a build time. Gli import sono espliciti e valutati a runtime. La specifica meccanica di guasto — una macro definita a zero che supera un controllo di esistenza, e un linker che seleziona silenziosamente l'implementazione sbagliata tra due omonime — non ha un equivalente diretto in questo modello di esecuzione.
Va detto con onestà: questo non rende XColdPro immune agli errori di implementazione. Nessun linguaggio lo fa. Elimina questa categoria di ambiguità silenziosa, che è cosa diversa e più modesta — ma è precisamente la categoria che è costata 38 milioni di dollari.
Il TRNG di Coldcard era plumbing custom su hardware chiuso: revisionato internamente, non verificabile dall'esterno, e — come si è visto — non tracciato fino al percorso di esecuzione effettivo.
XColdPro si appoggia invece alle primitive di casualità già fornite dal sistema operativo e a librerie crittografiche open source consolidate e ampiamente adottate, anziché a plumbing crittografico sviluppato in casa. Sono tra i componenti crittografici più scrutinati al mondo: mantenuti da migliaia di sviluppatori, sottoposti a fuzzing continuo, con storie di vulnerabilità pubbliche e documentate.
Il ragionamento è semplice: un difetto nel CSPRNG del kernel Linux verrebbe individuato da un ordine di grandezza in più di occhi, in un ordine di grandezza in meno di tempo, rispetto a un difetto nel percorso RNG del firmware di un singolo produttore hardware.
Nessun possessore di Coldcard poteva verificare l'entropia del proprio seed. XColdPro adotta esclusivamente standard aperti e pubblicati — BIP-39, BIP-44 — con una conseguenza pratica diretta:
I seed generati da XColdPro importano correttamente in qualunque wallet BIP39-compatibile, e viceversa.
L'implementazione può essere confrontata con i test vector di riferimento BIP39 e con i vettori crittografici NIST.
La derivazione degli indirizzi è verificabile rispetto alle implementazioni di riferimento.
Non è una garanzia assoluta di correttezza, ma è la differenza tra "fidati del nostro firmware" e "controlla tu stesso l'output rispetto allo standard".
Un possessore di Coldcard che avesse potuto confrontare l'entropia effettiva del proprio dispositivo con un riferimento indipendente avrebbe potuto individuare l'anomalia in cinque anni. Non ha mai avuto quello strumento.
L'osservazione più importante dell'intera vicenda: gli utenti Coldcard con una BIP-39 passphrase forte sono stati in larga misura protetti, perché la passphrase introduce entropia che non proviene dal generatore difettoso. Coinkite lo conferma esplicitamente: se il seed Mk3 affetto è stato usato con una passphrase BIP-39, l'analisi preliminare indica un rischio minimo per i fondi. La stessa Coinkite raccomanda ora passphrase forti o tiri di dado come entropia aggiuntiva.
XColdPro tratta questo strato come funzione di prima classe, non come opzione avanzata:
Hidden & Decoy Wallets. Il sistema implementa i wallet nascosti tramite la passphrase opzionale BIP-39 — la cosiddetta "25ª parola". Tecnicamente funziona come entropia additiva: la passphrase entra nella derivazione standard BIP-39 e produce un percorso di derivazione interamente diverso. Seed A + password X produce il wallet 1; seed A + password Y produce il wallet 2; seed A senza password produce il wallet 3. Tutti e tre validi, tutti e tre funzionanti, crittograficamente scorrelati.
La funzione è nata per la plausible deniability — resistenza alla coercizione, attraversamenti di frontiera, "$5 wrench attack". Ma la stessa matematica offre resistenza alla debolezza dell'RNG: un attaccante che sappia calcolare il tuo seed non arriva comunque ai tuoi fondi senza la passphrase, che non è mai passata dal generatore.
Generatore di password a livelli. Le passphrase sono generate esclusivamente con randomness crittografica — mai con generatori pseudo-casuali generici — su più livelli di robustezza selezionabili, inclusa un'opzione in formato mnemonico, facile da trascrivere a mano.
Import di seed esterni. XColdPro accetta qualunque seed BIP39/BIP44-compatibile. Chi voglia entropia completamente indipendente dal software — tiri di dado, lanci di moneta, qualunque procedimento fisico verificabile — può generare il seed esternamente e importarlo. Il manuale accompagna questa possibilità con un avvertimento esplicito: XColdPro non può verificare l'origine né la storia di gestione di un seed generato altrove, e l'import avviene a rischio dell'utente.
SeedVault (Shamir Secret Sharing). Divisione del seed in N share con soglia M-of-N: qualunque insieme di M share ricostruisce il wallet, M−1 share rivelano zero informazione in senso teorico-informativo. Non è una difesa contro un RNG debole — nessuno schema di condivisione lo è — ma è la differenza tra "un backup compromesso equivale a fondi perduti" e "un backup compromesso non è nulla".
Citadel Protocol. Approvazione multi-parte 100% air-gapped, senza coordinamento online e senza smart contract. Qui va detta una cosa che l'incidente Coldcard rende evidente e che troppo marketing ignora: il multisig non protegge se tutte le chiavi provengono dalla stessa sorgente di entropia difettosa. È esattamente il punto sollevato da Guise. Il valore del multisig sta nell'indipendenza delle sorgenti — dispositivi diversi, implementazioni diverse, idealmente fornitori diversi. Un'architettura software-based e vendor-independent come quella di XColdPro rende questa diversificazione praticabile invece che costosa.
C'è un punto finale, e non è tecnico.
Chi possedeva un Coldcard Mk3 nel 2021 non aveva modo di sapere che il vendor avesse spedito un difetto. Non aveva modo di verificarlo. Non aveva modo di uscirne senza migrare l'intero patrimonio.
XColdPro trasforma qualunque unità USB o SSD in un hardware wallet crittograficamente sigillato tramite il sistema BootVault. I dispositivi ColdGuardian esistono, ma il manuale è esplicito: sono "una scelta di comodità e di manifattura, non un requisito". L'entropia proviene dalla tua macchina, dal tuo sistema operativo, dal tuo input — non dal firmware sigillato di un singolo produttore che nessuno all'esterno può ispezionare.
Quando la fiducia è distribuita su più sorgenti indipendenti, nessun singolo fornitore può fallire per te in silenzio per cinque anni.
Stay Cold — Stay Secure.
XColdPro è sviluppato da XdRiP Digital Management LLC. Turn any USB into a Hardware Wallet.
Aprile 2026 ha ricordato alla DeFi una verità scomoda: il punto debole non è più sempre lo smart contract. Da Drift a KelpDAO fino a Purrlend, gli attaccanti si sono mossi attraverso persone, permessi, bridge e infrastrutture off-chain. È esattamente per questo che la cold storage deve andare oltre la comodità degli hot wallet e dei dispositivi connessi.