MuSig2 e FROST: le firme a soglia che cambiano il multisig Bitcoin

A giugno 2026 BitGo è entrata nella classifica Fortune 500 come prima azienda di infrastrutture per asset digitali a riuscirci, con circa 16,2 miliardi di dollari di ricavi dichiarati per il 2025 secondo il comunicato ufficiale, e una banca fiduciaria autorizzata a livello federale negli Stati Uniti, BitGo Bank & Trust. Dietro l’annuncio c’è un dettaglio meno pubblicizzato ma più interessante dal punto di vista tecnico: buona parte dei wallet istituzionali che BitGo gestisce oggi non firma più le transazioni Bitcoin come faceva fino a qualche anno fa. Al posto di uno script che elenca tre, cinque o sette chiavi pubbliche, molti di quei wallet producono una singola firma Schnorr, indistinguibile da quella di un utente che spende da un indirizzo personale.

Il meccanismo si chiama MuSig2 (BIP-327) e ha un parente più giovane, FROST, ancora in fase di standardizzazione come BIP-445, pensato per gli scenari in cui non tutti i firmatari sono sempre disponibili. Entrambi esistono solo perché Taproot, attivato il 14 novembre 2021, ha portato le firme Schnorr al posto delle sole firme ECDSA. Con Bitcoin che secondo CoinGecko vale circa 54.500 euro all’inizio di agosto 2026, non è un dettaglio da poco: qualunque risparmio in commissioni o riduzione della superficie d’attacco per un grande custode si traduce rapidamente in cifre concrete. Questo articolo entra nel dettaglio di come funzionano MuSig2 e FROST, perché i grandi custodi li stanno adottando, perché qualcuno invece ha scelto deliberatamente di non farlo ancora, e cosa cambia per chi in Italia deve rispettare gli obblighi di custodia previsti da MiCA.

Taproot in breve: da tre BIP a un nuovo modo di firmare

Taproot non è un singolo cambiamento ma un pacchetto di tre proposte: BIP-340 (firme Schnorr), BIP-341 (l’output Taproot vero e proprio, con la struttura MAST) e BIP-342 (Tapscript), firmate principalmente da Pieter Wuille, Jonas Nick e Tim Ruffing. Il soft fork è stato bloccato al blocco 687.284 il 12 giugno 2021 con oltre il 90% del segnale dei miner tramite il meccanismo Speedy Trial, ed è entrato in vigore al blocco 709.632 il 14 novembre 2021. Gli indirizzi che usano Taproot iniziano con il prefisso bc1p, diverso da bc1q di SegWit.

La parte che interessa questo articolo è il passaggio da ECDSA a Schnorr. Le firme Schnorr hanno una proprietà che ECDSA non offre in modo pratico: la linearità. Più chiavi pubbliche e più firme possono essere combinate matematicamente in un’unica chiave e un’unica firma valide, invece di essere elencate una per una dentro lo script. È la base di tutto ciò che segue in questo pezzo. La stessa proprietà, applicata in modo diverso, è anche dietro Ordinals e Runes, di cui abbiamo scritto in un pezzo dedicato, e dietro le Silent Payments, lo standard per ricevere fondi senza pubblicare un indirizzo riutilizzabile, approfondito qui. Chi cerca invece il dibattito sulla resistenza quantistica delle chiavi esposte da Taproot può leggere l’analisi che abbiamo dedicato al tema: qui ci concentriamo su un problema diverso, quello della firma multipla.

Il problema del multisig tradizionale: costi e privacy

Prima di Taproot, un wallet a firma multipla su Bitcoin funzionava quasi sempre con script P2SH o P2WSH, basati sull’opcode OP_CHECKMULTISIG: lo script elenca esplicitamente le chiavi pubbliche coinvolte e richiede che un certo numero di firme, ad esempio due su tre, venga allegato alla transazione. Funziona da anni ed è ancora oggi lo schema più diffuso, ma ha due difetti strutturali. Il primo è il costo: più firmatari servono, più lo script si allunga, e più byte occupa la transazione. Un input 2-di-3 in SegWit nativo pesa circa 104,5 vB secondo la documentazione tecnica di Bitcoin Optech, mentre configurazioni più ampie possono avvicinarsi a diverse centinaia di vB per un singolo input. Su una rete dove le commissioni si pagano a vByte, un custode con centinaia di prelievi al giorno paga quel sovrapprezzo ogni volta.

Il secondo difetto è la privacy, meno ovvio ma più delicato per chi fa custodia istituzionale. Uno script multisig è visibile in chiaro sulla blockchain: chiunque analizzi la mempool o un esploratore di blocchi vede che quell’indirizzo richiede, ad esempio, tre firme su cinque. Prima di Taproot, una transazione con quella struttura era essa stessa un segnale: comunicava che lì dentro c’era probabilmente molto valore, organizzato con una procedura complessa. Non è un caso che i furti più grandi degli ultimi anni, quelli che ripercorriamo più avanti, abbiano preso di mira proprio wallet multisig identificabili come tali fin dalla loro struttura on chain.

MuSig2 (BIP-327): tante chiavi, una firma sola

MuSig2 è lo schema che rende possibile aggregare le chiavi pubbliche di più firmatari in un’unica chiave, e le loro firme in un’unica firma Schnorr valida. È stato descritto per la prima volta da Jonas Nick, Tim Ruffing e Yannick Seurin in un paper accademico presentato alla conferenza CRYPTO 2021, poi formalizzato come BIP-327 da Nick, Ruffing ed Elliott Jin, creato il 22 marzo 2022 e oggi con stato Deployed. Rispetto alla versione precedente, MuSig1, che richiedeva tre round di comunicazione tra i firmatari, MuSig2 ne richiede solo due: ogni firmatario genera più nonce per la sessione di firma e li invia tutti nel primo round, eliminando il bisogno di un round di commitment separato. Nella pratica significa wallet più reattivi e meno scambi di rete tra dispositivi hardware.

Il vincolo di MuSig2 è che serve la collaborazione di tutti i firmatari coinvolti: è uno schema n-di-n, non a soglia. Se anche uno solo dei partecipanti è offline o si rifiuta di firmare, la transazione non si completa. In cambio, il risultato finale è indistinguibile da una spesa a chiave singola: nessuno script visibile, nessun indizio sul numero di firmatari coinvolti. BitGo, che ha contribuito attivamente alla specifica finale del BIP, ha pubblicato dati concreti sul risparmio: un input firmato in key path con MuSig costa circa 57,5 vB, contro i 104,5 vB di un input SegWit nativo e i 107,5 vB di un tapscript a profondità 1, circa il 45% in meno secondo il report tecnico di Bitcoin Optech firmato dall’ingegnere BitGo Brandon Black. Lo stesso report descrive un contributo tecnico di BitGo alla specifica finale: solo l’ultimo firmatario della sequenza può usare un nonce deterministico, il che permette di firmare da un modulo hardware (HSM) stateless, senza dover conservare stato tra un round e l’altro.

Per portare MuSig2 nei wallet serviva anche un formato dati condiviso per scambiarsi chiavi pubbliche, nonce e firme parziali durante il processo multi-round. Lo ha fornito il BIP-373, scritto dalla core developer Ava Chow e completato il 4 giugno 2024, che aggiunge i campi necessari al formato PSBT (Partially Signed Bitcoin Transaction). Senza quello standard, ogni wallet avrebbe dovuto inventarsi un proprio formato non interoperabile. Il 4 marzo 2026 Bitcoin Core ha unito la pull request numero 34219, che aggiunge la validazione dei pubnonce e delle firme parziali MuSig2 durante la deserializzazione dei PSBT: un tassello tecnico minore ma che conferma quanto lo stack software attorno a MuSig2 sia ancora in fase di rifinitura attiva, quattro anni dopo la nascita del BIP.

Il limite di MuSig2: cosa succede se un firmatario sparisce

Lo schema n-di-n di MuSig2 funziona bene quando i firmatari sono pochi e sempre raggiungibili, il caso tipico di un wallet aziendale 2-di-3 dove le tre chiavi sono su dispositivi controllati dalla stessa organizzazione. Diventa un problema quando i firmatari sono distribuiti tra parti indipendenti, con fusi orari diversi, dispositivi in manutenzione, o quando il modello di sicurezza prevede esplicitamente che una minoranza di partecipanti possa essere offline, in errore o addirittura malevola senza bloccare l’operatività. Un consiglio di custodia composto da cinque membri che richiede tutti e cinque per muovere fondi non è resiliente: basta un dispositivo rotto o una persona irraggiungibile per congelare i fondi.

Per questi scenari serve uno schema a soglia vero e proprio, in cui basta che un sottoinsieme t di n partecipanti collabori. È esattamente il problema che risolve FROST.

FROST (BIP-445): firme a soglia t-di-n

FROST, acronimo di Flexible Round-Optimized Schnorr Threshold signatures, è stato proposto nel 2020 da Chelsea Komlo (University of Waterloo e Zcash Foundation) e Ian Goldberg (University of Waterloo) in un paper accademico poi diventato lo standard IETF RFC 9591, pubblicato nel giugno 2024. Per Bitcoin, l’adattamento compatibile con le firme BIP-340 è in corso di standardizzazione come BIP-445, assegnato a gennaio 2026 e attualmente ancora in stato di bozza: la specifica vive nel repository bip-frost-signing dello sviluppatore Sivaram Dhakshinamoorthy, con la pull request corrispondente ancora aperta su bitcoin/bips. Un progetto complementare guidato da Blockstream Research definisce il protocollo di generazione distribuita delle chiavi (DKG) necessario a FROST, che può appoggiarsi a un dealer fidato secondo lo schema di RFC 9591 oppure a un protocollo DKG senza dealer come ChillDKG, ancora sotto sviluppo.

La differenza pratica con MuSig2 è nel modello di fiducia. Con FROST, la chiave privata non esiste mai per intero in nessun momento: durante la generazione distribuita, ogni partecipante calcola un proprio pezzo di chiave a partire da un polinomio segreto, e la chiave privata del gruppo esiste solo implicitamente, come somma dei termini costanti dei polinomi di tutti i partecipanti. Per firmare basta che una soglia t di n partecipanti collabori: se il gruppo è configurato come 3 di 5, due partecipanti possono essere offline, in errore o non disponibili senza bloccare la spesa. Il risultato, anche in questo caso, è un’unica firma Schnorr indistinguibile da una spesa a chiave singola. FROST supporta anche il rinnovo periodico delle quote di chiave: si possono rigenerare i pezzi assegnati a ciascun partecipante, invalidando eventuali copie compromesse, senza mai cambiare l’indirizzo pubblico su cui sono depositati i fondi.

Il caso d’uso più avanzato oggi è Spark, il layer 2 di Lightspark per Bitcoin, che usa FROST per il proprio modello di fiducia: l’utente detiene una quota della chiave, un insieme di operatori indipendenti ne detiene collettivamente un’altra tramite FROST, e basta che un solo operatore si comporti onestamente perché i fondi restino al sicuro, un modello descritto come 1-di-n. Anche le transazioni Spark che si regolano infine su Bitcoin layer 1 appaiono come normali spese Taproot, senza rivelare nulla sulla struttura interna del sistema di custodia sottostante.

ROAST: cosa succede se un firmatario si comporta male

FROST tollera che una minoranza di partecipanti sia assente, ma ha un punto debole nella fase di coordinamento: se un firmatario partecipa al primo round e poi sparisce, o invia dati scorretti apposta, l’intera sessione di firma può fallire e va ricominciata da capo, un problema soprattutto in contesti dove i partecipanti non si conoscono o non si fidano pienamente l’uno dell’altro. La soluzione si chiama ROAST, Robust Asynchronous Schnorr Threshold signatures, pubblicata da Blockstream Research il 24 maggio 2022 a firma di Tim Ruffing, Elliott Jin, Jonas Nick e alcuni collaboratori accademici. ROAST avvolge FROST con una logica che fa partire più tentativi di firma in parallelo e usa il primo che va a buon fine, garantendo che i firmatari onesti riescano comunque a produrre una firma valida anche in presenza di partecipanti disonesti o di una rete inaffidabile, come spiegato nel post tecnico di Blockstream.

Per chi gestisce custodia istituzionale, questo dettaglio non è secondario: un consiglio di firma che si blocca ogni volta che un partecipante è lento o malevolo è un rischio operativo, non solo teorico. ROAST è oggi il complemento naturale di qualsiasi implementazione FROST pensata per ambienti dove i firmatari sono davvero indipendenti tra loro, ad esempio operatori di un layer 2 come Spark o membri di un consiglio di custodia distribuito su più organizzazioni.

Multisig legacy, MuSig2 e FROST a confronto

Riassumere le differenze in una tabella aiuta a capire quale schema conviene in quale scenario. Nessuno dei tre è strettamente migliore in assoluto: sono strumenti con compromessi diversi tra semplicità, tolleranza ai guasti e maturità dello standard.

Chi sta già usando queste firme, in pratica

L’adozione non è più solo teorica. BitGo ha distribuito MuSig2 sui propri wallet Taproot caldi ed è oggi, dopo la quotazione a Wall Street nel gennaio 2026 (NYSE: BTGO), la prima azienda di infrastrutture per asset digitali entrata nella classifica Fortune 500, con BitGo Bank & Trust che opera come banca fiduciaria per asset digitali autorizzata a livello federale dall’OCC statunitense fin dall’approvazione finale di dicembre 2025. Il CEO Mike Belshe ha commentato l’ingresso in classifica dicendo che si tratta di «un traguardo importante per BitGo e per l’industria degli asset digitali», aggiungendo che «le istituzioni cercano fiducia, trasparenza, solidità regolamentare e resilienza operativa», come riportato nel comunicato ufficiale del 10 giugno 2026.

Ledger ha aggiunto il supporto a MuSig2 nella sua app Bitcoin a partire dalla versione 2.4.0, rilasciata nell’aprile 2025. Nunchuk ha lanciato un wallet multisig basato interamente su Taproot e MuSig2. Sul fronte Lightning, LND, l’implementazione più diffusa di nodi Lightning, ha portato i Simple Taproot Channels in produzione con la versione 0.21-beta di giugno 2026, che usa firme parziali MuSig2 con nonce just in time anche per la chiusura cooperativa dei canali con RBF. Jameson Lopp, CTO di Casa, aveva già sintetizzato il vantaggio di fondo per la privacy dei firmatari in una presentazione del 2022 poi trascritta integralmente sul suo sito: con Taproot i wallet multisig «non devono più rivelare quali chiavi stavano partecipando» e possono «confondersi con la folla», come si legge nella trascrizione integrale dell’intervento. E come già visto, Spark costruisce l’intero modello di sicurezza del proprio layer 2 attorno a FROST.

Il contrappunto: perché Unchained frena su Taproot multisig

Non tutti i custodi si sono mossi allo stesso ritmo, ed è un dettaglio che vale la pena raccontare perché bilancia l’entusiasmo attorno a queste tecnologie. Unchained Capital, uno dei nomi di riferimento negli Stati Uniti per la collaborative custody multisig, ha scelto pubblicamente di non adottare ancora MuSig2 o le firme Schnorr a soglia per i propri vault, preferendo restare su schemi basati su OP_CHECKSIGADD con più foglie k-di-k dentro lo script Tapscript. Il motivo, spiegato nel suo blog tecnico aggiornato ad aprile 2026, riguarda proprio la gestione dei nonce nei protocolli di firma interattivi: aggregare firme Schnorr richiede uno scambio di nonce tra i partecipanti che, se gestito male, con nonce riutilizzati o generati in modo prevedibile, può esporre le chiavi private, un rischio ben documentato nella letteratura crittografica sugli schemi di firma multi-round.

La differenza con BitGo non è tanto tecnologica quanto operativa: BitGo firma con dispositivi e software che controlla direttamente, e può quindi gestire la generazione dei nonce con margini di sicurezza noti. Unchained lavora invece in un modello di custodia collaborativa dove cliente e istituzione condividono le chiavi su hardware wallet di terze parti, spesso di marche diverse, e non può imporre aggiornamenti software unilaterali a tutti i partecipanti. Come nota lo stesso blog, per quello scenario «non esistono ancora best practice consolidate» per il multisig su Taproot. È un promemoria utile: l’adozione di MuSig2 e FROST non è un interruttore acceso o spento per l’intero settore, ma una scelta che ogni custode pesa in base al proprio modello di minaccia specifico.

Bybit, WazirX: cosa cambia (e cosa no) con le firme native

I furti multisig più grandi della storia recente delle crypto non sono nati da chiavi rubate, ma da firmatari che hanno approvato qualcosa di diverso da quello che pensavano di approvare. Bybit ha perso circa 1,5 miliardi di dollari il 21 febbraio 2025, il furto crypto più grande mai registrato, dopo che un aggressore ha compromesso il dispositivo di uno sviluppatore di Safe{Wallet} e alterato l’interfaccia al momento della firma, così che i firmatari legittimi hanno autorizzato un trasferimento diverso da quello mostrato a schermo: le chiavi non sono mai state rubate, come ha ricostruito un’indagine indipendente che ha attribuito l’attacco al gruppo Lazarus. WazirX ha perso circa 230 milioni di dollari nel luglio 2024, quasi metà delle sue riserve, con una dinamica simile: uno scarto tra quello che l’interfaccia di custodia di Liminal mostrava e i dati reali della transazione ha convinto quattro firmatari su sei ad approvare un payload nascosto, come ricostruito da Halborn. Un copione simile, per decine di milioni di dollari, ha colpito pochi mesi dopo anche Radiant Capital.

Questi tre casi riguardano wallet smart contract su reti EVM, non il multisig nativo di Bitcoin, ma la lezione si applica anche a MuSig2 e FROST: aggregare le firme in un’unica firma Schnorr elimina lo script visibile e quindi il segnale che comunica un bersaglio di alto valore, ma non elimina di per sé il problema di fondo, cioè sapere con certezza cosa si sta firmando. Un coordinatore di firma malevolo o compromesso potrebbe in teoria presentare a un firmatario dati diversi da quelli reali, esattamente come è successo con l’interfaccia di Safe. La differenza è che il protocollo di firma di Bitcoin, tramite PSBT, è pensato per essere verificato in chiaro riga per riga, destinatari, importi, fee, su un dispositivo separato prima di firmare. Alcune regole operative restano valide indipendentemente dallo schema di firma scelto:

• Verificare sempre indirizzo di destinazione, importo e fee sui dati grezzi della transazione, non solo su quanto mostra l’interfaccia
• Firmare da un dispositivo dedicato, possibilmente air gapped, diverso da quello usato per navigare o comunicare
• Usare hardware wallet di produttori diversi tra i vari firmatari, per non dipendere da un singolo fornitore compromesso
• Prevedere timelock e un canale di verifica fuori banda, una chiamata video o un messaggio firmato, prima di eseguire trasferimenti di importo rilevante

MiCA, Consob e la custodia dei CASP italiani

Chi in Italia offre servizi di custodia di cripto-attività a clienti retail non sceglie lo schema di firma per hobby: lo fa anche perché la normativa impone di rendere conto di come protegge quei fondi. L’articolo 75 del regolamento MiCA impone ai prestatori di servizi per le cripto-attività (CASP) che offrono custodia e amministrazione di adottare una policy interna che minimizzi il rischio di perdita per frode, minaccia informatica o negligenza, di segregare gli asset dei clienti da quelli della società, di tenere un registro delle posizioni di ciascun cliente e di garantire procedure di restituzione rapida dei fondi. Nessun articolo di MiCA impone uno schema di firma specifico: MuSig2, FROST o il multisig legacy sono tutti compatibili con l’articolo 75, purché la policy del CASP dimostri che il rischio operativo è gestito correttamente.

Il 1° luglio 2026 si è chiuso il periodo transitorio di MiCA in Italia, e da quella data solo i soggetti autorizzati possono offrire servizi su cripto-attività a clienti europei. Consob e Banca d’Italia hanno comunicato congiuntamente il 30 giugno 2026 che in Italia risultano abilitati nove soggetti, otto CASP più un intermediario bancario, come riportato nel comunicato ufficiale. Ne abbiamo ricostruito la mappa completa, servizio per servizio, in un pezzo dedicato; qui vale la pena elencare chi può, oggi, custodire legalmente cripto-attività per conto di clienti italiani.

Consob raccomanda comunque di verificare l’elenco aggiornato nel registro ESMA prima di affidare fondi a uno qualsiasi di questi soggetti, dato che le autorizzazioni possono evolvere nel tempo. Per chi valuta come esporsi a Bitcoin, la scelta tra un wallet autocustodito protetto da MuSig2 o FROST e uno strumento regolamentato come un ETP quotato in borsa resta anche una questione fiscale, non solo tecnica: ne parliamo in questo approfondimento sulla differenza di trattamento tra un ETP su Bitcoin e un wallet diretto.

Cosa aspettarsi da qui in avanti

Lo stato attuale è quello di uno stack a due velocità. MuSig2 è uno standard maturo: BIP-327 ha stato Deployed, BIP-373 per i PSBT è Complete, e i principali wallet hardware e software lo supportano già in produzione da almeno un anno. FROST è invece ancora un cantiere aperto: BIP-445 è in bozza, la pull request su bitcoin/bips non è ancora stata unita, e le implementazioni di produzione, Spark in testa, per ora convivono con l’assenza di uno standard Bitcoin definitivo, appoggiandosi a RFC 9591 lato crittografia generica. È un percorso già visto con MuSig2 stesso, che ha impiegato circa due anni tra la pubblicazione del paper accademico e lo stato Deployed del BIP.

Il fattore che probabilmente accelererà l’adozione non è puramente tecnico ma regolamentare ed economico allo stesso tempo: più la custodia istituzionale cresce, come dimostra l’ingresso di BitGo nella Fortune 500, più il risparmio in vByte e la riduzione della superficie d’attacco diventano argomenti che si misurano direttamente nei margini di un custode e nei requisiti di sicurezza di un CASP. Vale la pena continuare a seguire da vicino gli sviluppi di BIP-445, i primi audit indipendenti delle implementazioni FROST in produzione, e se e quando anche i wallet pensati per la custodia collaborativa, come quelli di Unchained, decideranno che le best practice attorno alla gestione dei nonce sono finalmente abbastanza mature da giustificare il passaggio.

Domande frequenti

Cos’è MuSig2 su Bitcoin?

MuSig2 è uno schema definito nel BIP-327 che permette a più firmatari di combinare le proprie chiavi pubbliche in un’unica chiave e le proprie firme in un’unica firma Schnorr valida, richiedendo che tutti i partecipanti collaborino, uno schema n-di-n. Il risultato è una transazione indistinguibile da una spesa a chiave singola, più economica in termini di vByte e più privata rispetto a un multisig tradizionale basato su script.

Qual è la differenza tra MuSig2 e FROST?

MuSig2 richiede la collaborazione di tutti i firmatari coinvolti, mentre FROST, in fase di standardizzazione come BIP-445, è uno schema a soglia t-di-n: basta che un sottoinsieme dei partecipanti collabori, tollerando che gli altri siano offline, in errore o non disponibili. Entrambi producono in output un’unica firma Schnorr indistinguibile da una spesa a chiave singola, ma solo FROST offre tolleranza ai guasti.

Taproot rende il wallet multisig più sicuro?

Taproot, tramite MuSig2 e FROST, riduce i costi e nasconde sulla blockchain il fatto che un indirizzo sia gestito da più firmatari, eliminando un segnale che in passato poteva attirare gli attacchi. Non elimina però il rischio di firmare dati manipolati da un’interfaccia compromessa, lo stesso vettore usato contro Bybit e WazirX: resta comunque necessario verificare sempre i dati grezzi della transazione prima di firmare, qualunque sia lo schema di firma usato.

I CASP italiani regolati da MiCA possono usare MuSig2 o FROST?

Sì. L’articolo 75 di MiCA impone ai CASP di adottare una policy di custodia che minimizzi i rischi operativi, ma non impone uno schema di firma specifico: MuSig2, FROST e il multisig legacy sono tutti compatibili, a condizione che il CASP autorizzato da Consob e Banca d’Italia dimostri di gestire correttamente il rischio associato allo schema scelto.

Quali wallet supportano già MuSig2 o FROST?

Sul fronte MuSig2, BitGo lo ha distribuito sui propri wallet Taproot caldi, Ledger lo supporta dalla versione 2.4.0 della sua app Bitcoin e Nunchuk offre un wallet multisig dedicato basato su MuSig2. Sul fronte FROST, l’esempio di produzione più avanzato è Spark, il layer 2 di Lightspark, che lo usa come base del proprio modello di custodia a soglia con operatori indipendenti.

Articolo a cura della redazione di HOGE Wire.