blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">Il kit di firma di Ledger destinato agli sviluppatori di wallet invia un rapporto a un server di Ledger ogni volta che qualcuno firma una transazione Ethereum o Solana con un dispositivo Ledger attraverso un wallet che mantiene le impostazioni predefinite del kit. A segnalarlo su X, il 10 novembre 2026, è stato Kaloyan Kosev, sviluppatore del produttore di wallet Ambire. Il codice sul GitHub di Ledger mostra che cosa esce: la rete, l’indirizzo a cui è destinata la transazione, il modello del dispositivo e il firmware, la versione dell’app Ledger installata sul dispositivo e se l’utente ha firmato alla cieca. Il team di sicurezza di Ledger, Ledger Donjon, ha risposto a tarda sera che questo «fa parte del funzionamento di Clear Signing» e che Ledger non conserva alcun dato, ha riferito Unchained.
Il tema è la privacy di Ledger, non un furto. Nessuna fonte, nemmeno tra i critici di Ledger, sostiene che i rapporti possano spostare fondi o esporre una chiave privata: contengono metadati su ciascuna firma, non segreti. La discussione riguarda chi decide se gli utenti di un wallet vengano contati e se questa raccolta debba essere attiva finché qualcuno non la spegne.
L’invio dei rapporti si trova in @ledgerhq/context-module, un pacchetto del Device Management Kit open source di Ledger che i wallet di terze parti integrano nelle proprie app. Non è nel firmware del dispositivo. Lo hanno detto su X sia Ledger Donjon sia Yu Xian della società di sicurezza SlowMist, dopo che lo sviluppatore Lefteris Karapetsas aveva chiesto se i dispositivi con l’ultimo firmware «telefonassero a casa», secondo Unchained.
Che cosa invia il kit di firma di Ledger, campo per campo
Coindaro ha letto il codice del pacchetto così com’era sul ramo develop di Ledger alle 05:50 UTC del 12 novembre. Per una transazione Ethereum, ogni rapporto contiene l’ID della catena, l’indirizzo to della transazione (il destinatario, oppure il contratto chiamato), il codice di quattro byte della funzione del contratto quando c’è, il metodo di firma, se lo schermo ha usato un formato di clear signing di base o ERC-7730, un conteggio degli errori di contesto parziali e un sì o un no sulla firma alla cieca, con il motivo. Per i dati tipizzati firmati, l’indirizzo è il contratto indicato nel messaggio.
Ogni rapporto riporta inoltre il modello del dispositivo, la versione dell’app Ethereum o Solana installata sul Ledger, la versione del firmware e un’etichetta source, che per impostazione predefinita vale “third-party”. Il formato prevede campi facoltativi per la piattaforma del wallet, la sua versione e il sistema operativo del telefono o del computer, ma il codice predefinito di Ledger per Ethereum e Solana li lascia vuoti; un wallet che scrive un proprio reporter può compilarli. A ogni rapporto viene assegnato un identificativo composto da sei caratteri casuali e dall’ora della firma al millisecondo.
I rapporti Solana elencano i programmi chiamati dalla transazione e quelli che Ledger non ha saputo riconoscere. L'”indirizzo di destinazione” è qui il primo programma diverso dal System Program di Solana, quindi un semplice trasferimento di SOL non riporta alcuna destinazione. Il formato ha lo spazio per la firma della transazione Solana, che indicherebbe l’esatta transazione on-chain, ma il codice Solana predefinito non la compila.
Conta anche ciò che manca. L’indirizzo dell’utente non è un campo in nessuno dei due formati, come aveva già notato anche Ambire nella sua pull request del 24 settembre. Nemmeno l’indirizzo IP compare tra i campi del carico utile, anche se il server di Ledger, come qualsiasi server, vede l’indirizzo internet da cui arriva ogni richiesta. Su Ethereum, un wallet alla versione 2.7.0 o successiva invia due rapporti per ogni firma: uno tramite il reporter originale e uno tramite il più recente “sign reporter”, inviato a /v2/blind-signing-events.
Da un server di prova di Ledger in aprile a Solana in ottobre
La funzione è arrivata per tappe, tutte elencate nel changelog del pacchetto. La versione 1.16.0, pubblicata su npm il 14 aprile 2026, ha aggiunto un “blind signing reporter” e lo ha collegato al modulo. A quel punto l’indirizzo predefinito era un server di prova (staging) di Ledger. La versione 2.1.0, il 26 maggio, ha spostato l’impostazione predefinita sull’endpoint di produzione https://blind-signing.api.ledger.com. Protos, che ha raccontato la vicenda l’11 novembre, fa risalire al 26 marzo il primo commit del reporter.
Un secondo reporter multichain è comparso nella 2.5.0 a fine agosto ed è stato disattivato di nuovo prima che quella versione uscisse. La pull request n. 1966, aperta e unita l’8 ottobre (unita alle 13:54 UTC), lo ha riacceso per Ethereum e Solana. La sua descrizione dice che gli eventi di firma “are now posted to” l’endpoint v2 per entrambe le catene e chiama la funzione “Multichain blind-sign tracking”. La modifica è arrivata su npm con la versione 2.7.0 il 16 ottobre. L’ultima release, la 2.8.0 del 21 ottobre, la mantiene, e alle 05:50 UTC del 12 novembre non risultava unita né aperta alcuna modifica ai reporter.
| Data (2026) | Versione del pacchetto o evento | Che cosa è cambiato |
|---|---|---|
| 14 aprile | context-module 1.16.0 | Aggiunti i rapporti di firma per Ethereum, indirizzati a un server di prova di Ledger |
| 26 maggio | 2.1.0 | Indirizzo predefinito spostato su blind-signing.api.ledger.com (produzione) |
| 28 agosto | 2.5.0 | Aggiunto un secondo reporter multichain, poi disattivato prima del rilascio |
| Dal 24 al 30 settembre | Pull request Ambire n. 2730 | Ambire disattiva i rapporti per impostazione predefinita, solo con consenso dell’utente |
| 8 ottobre | Pull request Ledger n. 1966 unita | Reporter multichain attivato per Ethereum e Solana |
| 16 ottobre | 2.7.0 | Prima release con l’interruttore acceso; la 2.8.0 è seguita il 21 ottobre |
| 10 novembre | Post di Kosev, risposta di Donjon in serata | L’impostazione predefinita diventa pubblica; Ledger dice di non conservare dati |
La risposta di Ledger: Clear Signing richiede la consultazione e nulla viene conservato
Clear Signing è il nome con cui Ledger indica la visualizzazione di una transazione sullo schermo del dispositivo in parole che una persona può verificare, come il token, l’importo e il contratto di uno swap, invece di una stringa esadecimale. Si basa su file descrittori scritti secondo ERC-7730, uno standard Ethereum in bozza creato nel febbraio 2024, che spiega a un wallet come etichettare e formattare una determinata chiamata a un contratto. Quando nessun descrittore corrisponde, all’utente viene chiesto di firmare alla cieca, cioè di approvare dati che lo schermo non sa spiegare.
L’argomento di Ledger Donjon, come lo riferiscono Unchained e Protos, è che questi file sono troppo grandi per stare sul dispositivo, quindi il modulo predefinito li cerca sui server di Ledger al momento della firma. «Questo richiede l’invio dei dettagli della transazione necessari per trovare il descrittore giusto», ha scritto Donjon, secondo Protos. Ledger dice di non conservare nessuno di questi dati e che i produttori di wallet possono inserire un modulo proprio.
Il codice conferma una parte di questa spiegazione e ne lascia aperta un’altra. Nel kit, le richieste dei descrittori vanno a un indirizzo Ledger diverso, il servizio Crypto Assets List all’indirizzo global.api.prd.ledger.com/cal/v1. I rapporti, invece, vanno all’endpoint di blind signing dopo che il kit ha stabilito se la firma era chiara o alla cieca, e riportano quel verdetto. Più che la consultazione in sé, somigliano a un registro di quanto spesso il clear signing fallisce e su quali contratti, il che si accorda con il nome della funzione. Ledger non ha pubblicato che cosa faccia con i rapporti, per quanto tempo i suoi server conservino i log delle richieste, né un’informativa sulla privacy specifica per questo endpoint. Nessuno al di fuori di Ledger ha verificato l’affermazione secondo cui nulla viene conservato.
Chi è coinvolto: i wallet costruiti sul kit, non il dispositivo
Non è stato pubblicato alcun elenco dei wallet che usano il kit con le impostazioni predefinite. Protos ha scritto che le app devono rinunciare esplicitamente e che «la stragrande maggioranza non lo fa», senza indicare un numero. Ambire è l’unico caso citato, e dice che nessuna versione con i rapporti attivi è arrivata nella sua app in produzione: il suo codice li tiene ora spenti a meno che l’utente non li attivi nelle impostazioni sulla privacy, secondo Unchained.
Per chi possiede un Ledger Nano X o un altro Ledger, i rapporti non partono dal dispositivo. Li invia l’app del wallet sul telefono o sul computer, che comunica con internet; il dispositivo si limita a firmare. Un aggiornamento del firmware non li modifica, e Ledger non ha chiesto a nessuno di spostare fondi o di cambiare la frase di recupero. La vicenda è inoltre distinta dai dispositivi Ledger manomessi su cui la polizia di Singapore ha lanciato un avviso in ottobre.
Come disattivare i rapporti di firma di Ledger
Per gli utenti, l’unica leva è il wallet. Gli utenti di Ambire hanno già i rapporti disattivati se non li abilitano loro. Chi usa altri wallet che si collegano a un Ledger può chiedere al produttore se includa il context-module di Ledger con il reporter predefinito, e in quale versione: rapporti Ethereum dalla 1.16.0 (verso la produzione dalla 2.1.0), rapporti Solana e secondo rapporto Ethereum dalla 2.7.0.
Per i produttori di wallet, il builder di Ledger offre tre strade nel codice attuale:
setReporterConfigcambia l’indirizzo a cui scrivono entrambi i reporter, per esempio verso un server gestito dal wallet stesso.setBlindSigningReportersostituisce il reporter originale con uno scritto dal wallet, che può anche non fare nulla.- Un wallet può fornire al signer un proprio context module, la strada indicata da Ledger Donjon.
Non esiste un interruttore del builder per sostituire da solo il nuovo reporter multichain; un wallet che voglia eliminarlo deve reindirizzare l’indirizzo o fornire un modulo proprio. Un’impostazione predefinita di Ledger che non invii nulla renderebbe superfluo tutto questo.
Privacy per impostazione predefinita e le domande senza risposta di Ledger
«Sostengo che la privacy dovrebbe essere l’impostazione predefinita», ha scritto Kosev, secondo Unchained. Un indirizzo e un modello di dispositivo non sono segreti in sé. Inviato a ogni firma insieme a una versione del firmware, però, un indirizzo di destinazione può essere confrontato con il registro pubblico e con marca temporale di una blockchain, e i rapporti arrivano a Ledger a meno che il produttore del wallet non cambi l’impostazione. Nicolas Bacca, cofondatore di Ledger che ha lasciato l’azienda nel 2023, ha detto che l’impostazione predefinita potrebbe essere stata «trascurata», ha riferito Protos.
Ledger è un’azienda con sede a Parigi e, secondo la normativa europea sulla protezione dei dati, un’informazione riconducibile a una persona identificabile può rientrare tra i dati personali. Al 12 novembre nessuna autorità per la protezione dei dati aveva commentato pubblicamente, e Ledger non ha pubblicato alcun post sul blog né avviso sui rapporti.
La prossima mossa spetta a Ledger. Può portare l’impostazione predefinita su spento con una nuova release del context-module, pubblicare che cosa conserva l’endpoint di blind signing e per quanto tempo, oppure lasciare che i wallet rinuncino uno alla volta. Chi sta configurando un dispositivo può vedere come l’app del wallet con cui lo abbina tratta i dati nella nostra guida alla configurazione di un hardware wallet.