Taproot e BitVM: i rollup su Bitcoin senza un nuovo fork

Un campo dimenticato di Taproot torna protagonista

Quando Taproot si è attivato nel novembre 2021, al blocco 709.632, venne raccontato soprattutto come un aggiornamento di privacy ed efficienza: firme più piccole, script più economici, indirizzi che iniziano con bc1p. Cinque anni dopo, la sua eredità più importante è un’altra. Taproot ha fornito i mattoni crittografici che oggi rendono Bitcoin programmabile senza toccarne le regole di consenso, e quasi nessuno dei Layer 2 nati nel 2026 esisterebbe senza di essi (CoinDesk).

La prova più recente è arrivata ai primi di ottobre 2026. Robin Linus, l’autore di BitVM, ha aperto la pull request numero 36466 su Bitcoin Core per rendere standard la propagazione dell’annex di Taproot, un campo riservato dal 2021 e rimasto quasi senza un uso concreto (BTC++ Insider). È una modifica tecnica e in apparenza marginale, ma racconta una storia più grande.

Nel 2026 i Layer 2 che stanno crescendo su Bitcoin, dal rollup Citrea alle statechain di Spark fino ai contratti con oracolo, poggiano quasi tutti su primitive introdotte da Taproot. E lo fanno mentre il protocollo resta immobile: Taproot è l’ultimo soft fork riuscito, e dal 2021 Bitcoin non ne ha approvato un altro. Questo articolo spiega come un aggiornamento venduto per la privacy sia diventato la fondazione della programmabilità di Bitcoin, perché l’annex conti più di quanto sembri, e dove si fermano davvero questi nuovi livelli.

Cosa aveva introdotto Taproot nel 2021

Taproot non è stato un singolo cambiamento, ma un pacchetto di tre BIP attivati insieme con il metodo Speedy Trial, dopo oltre il 90% di segnalazione dei miner nel giugno 2021. BIP-340 ha portato le firme Schnorr (autori Pieter Wuille, Jonas Nick e Tim Ruffing), BIP-341 ha introdotto la struttura Taproot e gli alberi di script MAST, BIP-342 ha definito Tapscript, la versione dello scripting usata negli output Taproot.

Per i Layer 2 contano soprattutto tre proprietà. Le firme Schnorr sono lineari, quindi si possono aggregare (con schemi come MuSig2 e FROST) e trasformare in adaptor signature, cioè firme condizionate alla rivelazione di un segreto. MAST permette di impegnarsi a un albero di script anche enorme rivelando on-chain solo il ramo effettivamente usato, un dettaglio che diventa decisivo per BitVM. Tapscript, infine, introduce un versioning che lascia spazio a estensioni future senza rompere nulla.

L’adozione racconta bene la parabola. Dopo aver superato il 40% delle transazioni all’inizio del 2024, trainata dalla febbre di Ordinals e Runes, la quota di output Taproot si è poi normalizzata su livelli più bassi e più organici, legati a wallet e protocolli invece che alla speculazione sulle iscrizioni. Il punto non è più quante transazioni usano Taproot, ma cosa ci si può costruire sopra.

Un esempio concreto aiuta a capire la portata del cambiamento. Con le vecchie firme ECDSA, un multisig a tre firme su cinque appariva on-chain come tale, pesante e riconoscibile. Con Schnorr e lo schema MuSig2 le chiavi possono essere aggregate in una sola firma, e una spesa multisig diventa indistinguibile da un pagamento ordinario: più privacy, meno byte, commissioni più basse. È lo stesso principio che permette a protocolli come Spark di usare FROST, una firma a soglia che distribuisce il controllo tra più operatori senza mai mostrarlo alla rete. Il multisig, con Taproot, è diventato invisibile.

L’annex: il contenitore inutilizzato che ora serve ai Layer 2

L’annex è un campo opzionale nella struttura witness di ogni input Taproot. Le regole di consenso lo prevedono dal 2021, ma lo hanno lasciato vuoto e privo di significato, in attesa di un uso futuro. Per anni quell’uso non è arrivato, e l’annex è rimasto un pezzo di Bitcoin presente ma spento.

La pull request 36466 di Robin Linus prova a cambiare le cose. Linus, oltre a BitVM, sviluppa Glass Coins (in precedenza Shielded CSV), un protocollo a validazione client-side: per impedire la doppia spesa deve pubblicare piccoli dati di controllo sulla blockchain, e l’annex è il posto naturale dove metterli. Il problema è che Bitcoin Core, il client di riferimento, non propaga per impostazione predefinita le transazioni che contengono un annex, quindi oggi quel campo è di fatto inutilizzabile sulla rete pubblica.

Il dibattito si è acceso in fretta. Lo sviluppatore noto come Rearden ha fatto notare che implementazioni alternative del nodo, come LibreRelay e rbitcoin, già propagano gli annex, quindi l’infrastruttura esiste in parte altrove (BTC++ Insider). Standardizzare il comportamento nel client dominante, però, è un’altra cosa, perché definisce ciò che migliaia di nodi considerano una transazione normale.

La vicenda è istruttiva proprio perché non riguarda il consenso. L’annex è già legale secondo le regole di Bitcoin: qui si discute solo di politica di propagazione, cioè di cosa i nodi accettano di inoltrare. È l’ennesimo caso in cui Taproot offre spazio di progettazione senza bisogno di un soft fork, perché la capacità c’era già e bisogna solo decidere di usarla.

C’è anche una dimensione economica. Ogni byte che finisce on-chain compete per lo spazio di blocco, la stessa risorsa scarsa che i miner vendono al mercato e che determina le commissioni; un uso ordinato dell’annex eviterebbe che gli stessi dati vengano infilati in modi più dispersivi, come già accade con alcune iscrizioni. È un tema che si intreccia con l’economia della sicurezza di Bitcoin, dove la corsa per lo spazio e per l’energia pesa su chi mina, come abbiamo raccontato analizzando la difficoltà di Bitcoin come un’asta per l’energia.

BitVM: calcolo arbitrario su Bitcoin senza soft fork

BitVM è l’idea che ha riaperto la discussione su cosa Bitcoin possa davvero fare. Presentata da Robin Linus, fondatore di ZeroSync, nell’ottobre 2023, propone un modo per verificare computazioni arbitrarie su Bitcoin senza modificare il consenso, sfruttando un modello a prova di frode (whitepaper BitVM).

Il meccanismo si appoggia direttamente a Taproot. Grazie a MAST, un intero programma può essere spezzato in centinaia di foglie Tapscript e impegnato in un unico output Taproot; on-chain si rivela soltanto la foglia che serve. Le firme pre-costruite e i timelock incatenano le transazioni in una sequenza prevedibile, mentre gli hashlock legano i vari pezzi tra loro. Senza gli alberi di script di Taproot, un programma del genere non entrerebbe in una transazione Bitcoin.

Il modello è ottimistico, come i rollup di Ethereum, ma vive dentro i vincoli stretti di Script. Un operatore afferma un risultato e, se mente, chiunque può pubblicare una prova di frode che esegue on-chain il pezzo di computazione contestato, dimostra l’inganno e gli fa perdere la cauzione. Nel caso normale, quando tutti sono onesti, non accade nulla di costoso: la sola minaccia della prova di frode basta a tenere in riga gli operatori.

Da BitVM a BitVM2 e BitVM3

La prima versione di BitVM aveva un limite pratico: richiedeva lunghi giochi interattivi di bisezione tra due parti fissate in anticipo, uno schema poco adatto a un bridge aperto. BitVM2, presentato nell’agosto 2024, ha reso le prove di frode succinte: la verifica di una SNARK viene spezzata su più foglie Tapscript, chiunque può fare da sfidante senza bisogno di permessi, e nel caso contestato bastano tre transazioni on-chain per risolvere la disputa (paper BitVM2).

La ricerca non si è fermata. BitVM3, descritto in un paper del 2026, punta a bridge ancora più efficienti usando i garbled circuit, una tecnica che riduce i dati da pubblicare on-chain. L’obiettivo dichiarato è rendere economicamente sostenibile ciò che BitVM2 ha reso tecnicamente possibile.

Il punto che conta per questa storia è uno solo: niente di tutto questo richiede un soft fork. BitVM gira con il Bitcoin di oggi, così com’è uscito da Taproot. È la ragione per cui i primi Layer 2 trust-minimized del 2026 sono stati costruiti su BitVM invece di aspettare l’attivazione dei covenant, un processo che in Bitcoin può richiedere anni di dibattito e non è affatto garantito.

Resta il fatto che BitVM non è gratis. Gli operatori di un ponte devono immobilizzare capitale come garanzia, i periodi di contestazione introducono attese prima che un prelievo sia definitivo, e la pubblicazione delle prove di frode, nel caso peggiore, costa spazio di blocco prezioso. Sono compromessi accettabili per muovere valore tra Bitcoin e un secondo livello, ma spiegano perché un covenant nativo, se mai venisse attivato, renderebbe questi ponti molto più economici. BitVM è la prova che si può fare oggi, non la dimostrazione che sia la soluzione definitiva.

Citrea, il primo ZK-rollup in produzione su Bitcoin

Il progetto che ha portato questa teoria in mainnet è Citrea, che il 27 gennaio 2026 è diventato il primo ZK-rollup in produzione a regolare direttamente su Bitcoin (The Block). È un rollup di tipo Type 2 zkEVM, quindi compatibile con gli smart contract scritti per Ethereum.

Il funzionamento è quello di un rollup a conoscenza zero adattato a Bitcoin. Citrea esegue le transazioni EVM fuori dalla catena, raggruppa i risultati e genera prove STARK (tramite RISC Zero) che vengono poi compresse in una SNARK; questa prova, insieme alle differenze di stato, viene pubblicata su Bitcoin in una busta simile a un’iscrizione. Bitcoin funge così sia da livello di disponibilità dei dati sia da livello di regolamento, e lo stato del rollup resta ricostruibile a partire dalla sola blockchain di Bitcoin (documentazione Citrea).

Per un utente, in pratica, Citrea assomiglia a una catena EVM qualsiasi: si collega un wallet, si usano exchange decentralizzati, si deposita cBTC in protocolli di prestito. La differenza sta sotto il cofano, dove la sicurezza non dipende da un validator set proprio ma dall’ancoraggio a Bitcoin. Il punto debole, comune a quasi tutti i rollup giovani, è il sequencer: all’avvio è centralizzato, e la decentralizzazione della produzione dei blocchi resta un obiettivo futuro, non una realtà del primo giorno.

Sul fronte degli asset, il gas nativo è cBTC, cioè Bitcoin stesso portato sul rollup, mentre la stablecoin ctUSD è emessa da MoonPay sull’infrastruttura di M0. Al lancio Citrea contava oltre 30 applicazioni, tra exchange decentralizzati, strumenti di liquidità e protocolli di prestito. Dietro il progetto c’è un percorso di finanziamento solido: 2,7 milioni di dollari di seed guidato da Galaxy nel 2023 e 14 milioni di dollari di Series A guidato da Founders Fund nell’ottobre 2024, la prima scommessa del fondo di Peter Thiel sull’ecosistema Bitcoin, con la partecipazione di Delphi, Figment e di angel come Jameson Lopp (CoinDesk). L’arrivo di stablecoin native e di custodia programmabile su Bitcoin è esattamente il terreno su cui le banche italiane stanno passando dalla difesa all’attacco.

Il ponte Clementine e il modello 1-di-N

Il punto più delicato di qualsiasi Layer 2 di Bitcoin è il ponte, cioè il luogo dove i BTC restano bloccati mentre una loro rappresentazione circola sul secondo livello. Qui si concentra la maggior parte del rischio, come insegna la lunga lista di bridge svuotati negli anni. Citrea affronta il problema con Clementine, un ponte basato su BitVM.

Clementine adotta un’assunzione di fiducia descritta come 1-di-N: finché anche un solo verificatore, in un insieme predefinito, si comporta onestamente, nessuno può rubare i BTC in custodia. Il meccanismo usa Light Client Proof che incorporano le batch proof di Citrea provate in modo ricorsivo, e questo consente una verifica ottimistica delle prove a conoscenza zero direttamente su Bitcoin tramite BitVM (documentazione Citrea).

È un salto netto rispetto ai bridge federati tradizionali, dove bisogna fidarsi di una maggioranza di firmatari, per esempio 8 su 15. Ma 1-di-N non significa fiducia zero: l’insieme dei verificatori è fisso, la disponibilità del servizio dipende dagli operatori, e la complessità stessa del codice è un rischio. La storia dei Layer 2 insegna che i ponti si rompono più per bug e per chiavi gestite male che per debolezze del modello teorico.

Vale la pena insistere su un punto, perché è qui che molti progetti inciampano. Un modello 1-di-N presuppone che almeno un verificatore onesto sia non solo presente, ma anche online e capace di agire entro le finestre temporali previste. Serve dunque qualcuno che vigili, un ruolo simile a quello delle watchtower su Lightning, e serve che il codice del ponte sia stato verificato a fondo. La teoria regge; è l’ingegneria, con le sue chiavi, i suoi aggiornamenti e i suoi errori umani, a fare la differenza tra un ponte sicuro e il prossimo titolo di cronaca.

Spark e le statechain: self-custody e firme FROST

Non tutti i Layer 2 inseguono gli smart contract. Spark, protocollo open-source lanciato da Lightspark, punta sui pagamenti ad alta velocità e sull’emissione di stablecoin e token, ed è costruito sulla tecnologia delle statechain, con elementi di atomic swap, compatibilità con Lightning e idee prese da Ark (NoBSBitcoin).

Una statechain trasferisce la proprietà di una UTXO on-chain senza trasmettere alcuna transazione. Invece di muovere i bitcoin, il protocollo ruota le chiavi tra mittente, destinatario e un coordinatore: la UTXO non si sposta mai, cambia soltanto chi ha la capacità di spenderla. Spark usa un modello a due firme su due, dove una chiave appartiene all’utente e l’altra è detenuta collettivamente dagli operatori tramite firma a soglia FROST, costruita sulle firme Schnorr di Taproot. Nessuna delle due parti può muovere i fondi da sola, e la self-custody resta intatta perché l’utente conserva transazioni di uscita pre-firmate.

L’innovazione pratica è l’architettura a foglie, che permette di dividere e ricombinare i saldi in un albero fuori catena e quindi di trasferire importi arbitrari, superando un limite storico delle statechain. Anche qui l’assunzione di sicurezza è di tipo 1-di-N, ma l’approccio è diverso da quello di un rollup: niente macchina virtuale generalista, bensì massima efficienza sui pagamenti e sui token (Spark).

Il senso pratico di Spark si vede nei pagamenti e nelle stablecoin. Un wallet può ricevere e inviare valore in tempo reale a costo quasi nullo, con la possibilità di uscire su Lightning quando serve interoperabilità, e gli emittenti possono coniare token e stablecoin direttamente sul protocollo. È un posizionamento diverso da quello di Citrea: non la DeFi generalista, ma i trasferimenti di valore ad alta frequenza, un terreno dove Lightning ha aperto la strada e dove la concorrenza tra secondi livelli è destinata a crescere.

I Discreet Log Contracts: derivati e oracoli nativi

C’è poi una categoria che non sposta fiducia su un ponte né su un rollup, ma resta tra due sole parti: i Discreet Log Contracts, o DLC, proposti da Tadge Dryja del MIT nel 2018. Un DLC è un contratto condizionale tra due controparti che si regola in base a un dato del mondo reale (un prezzo, l’esito di un evento) senza rivelare on-chain i dettagli del contratto (Bitcoin Optech).

Il cuore crittografico è l’adaptor signature, cioè una firma Schnorr incompleta che può essere completata solo quando viene rivelato un segreto specifico; in un DLC quel segreto deriva dall’attestazione di un oracolo sull’esito. La parte elegante è che l’oracolo non sa nemmeno di essere usato: si limita a firmare pubblicamente un risultato, e quella firma sblocca la transazione giusta tra le due parti. Senza le firme Schnorr arrivate con Taproot, questa versione privata ed efficiente dei DLC non esisterebbe (Spark).

Le applicazioni sono derivati, opzioni e soprattutto mercati predittivi nativi su Bitcoin, un ambito in cui il confine tra previsione e scommessa è sottile, come abbiamo visto raccontando i mercati predittivi in cui l’AI prevede come il mercato ma non guadagna. A differenza di un rollup, i DLC non introducono un custode collettivo: sono perfetti per contratti bilaterali, meno adatti a una DeFi generalista con tanti partecipanti.

I Layer 2 di Bitcoin a confronto

Non esiste un unico Layer 2 di Bitcoin, ma un ventaglio di soluzioni con compromessi diversi su tre assi: quanta fiducia richiedono, se permettono all’utente di uscire da solo e quanto si appoggiano alle primitive di Taproot. La tabella qui sotto riassume le principali famiglie (Spark Research).

La differenza di fondo sta nel tipo di scalabilità. Lightning e Spark scalano i pagamenti, portando la velocità dalle circa sette transazioni al secondo del livello base a trasferimenti quasi istantanei e a costo irrisorio. I rollup come Citrea scalano invece la computazione, spostando fuori catena l’esecuzione di smart contract complessi e lasciando a Bitcoin il ruolo di ancora di sicurezza. I DLC, infine, non scalano nulla: aggiungono espressività a singoli contratti. Sono approcci complementari, non alternativi.

Come si sceglie, allora? La domanda giusta non è quale Layer 2 vinca, ma quale compromesso serve. Per i pagamenti quotidiani contano velocità e costo, e qui Lightning e Spark sono avanti. Per smart contract e DeFi serve espressività, terreno dei rollup come Citrea. Per contratti bilaterali con un oracolo bastano i DLC. E in ogni caso la domanda chiave resta sempre la stessa: che cosa succede ai miei fondi se l’operatore sparisce? La risposta, cioè la qualità dell’uscita unilaterale, conta più di qualunque promessa di rendimento.

Il nodo dei covenant: CTV, CAT e l’ultimo soft fork

BitVM dimostra che si può fare molto senza nuovi opcode, ma a un prezzo: i ponti costruiti su BitVM sono complessi, costosi in termini di script e difficili da rendere eleganti. Un covenant, cioè un vincolo su come una certa UTXO potrà essere spesa in futuro, renderebbe ponti e vault molto più semplici e sicuri. È per questo che nel 2026 la discussione sui covenant è tornata al centro del tavolo.

Lo stato delle proposte, però, resta incerto. OP_CTV (BIP-119, di Jeremy Rubin) è la più vicina al traguardo, con parametri di attivazione concreti per la prima volta, ma la segnalazione dei miner è rimasta vicina allo zero. OP_CAT (BIP-347, di Ethan Heilman e Armin Sabouri) ha un numero di BIP ma nessuna road map di attivazione, mentre proposte come OP_CSFS e il pacchetto LNHANCE completano il quadro (BlockEden).

Il dibattito ha un peso che va oltre la tecnica. Adam Back, amministratore delegato di Blockstream, il primo ottobre 2026 ha definito gli opcode covenant un possibile «last soft fork», cioè un ultimo aggiornamento capace di ridurre la necessità di modifiche future e, unito alla verifica formale, di rendere lo scripting di Bitcoin più sicuro (CryptoBriefing). È una posizione che riassume la tensione del momento: aggiungere poco, una volta sola, per non dover più aggiungere nulla.

Ossificazione contro evoluzione: la politica di Bitcoin

La vicenda dell’annex è un microcosmo di una frattura più profonda. Non è un cambio di consenso, solo politica di propagazione, eppure divide. Da un lato c’è chi teme che ogni aggiunta apra la porta a usi non monetari della catena, un timore già visto nella guerra sul campo OP_RETURN e attorno al client Knots. Dall’altro c’è chi vede nella programmabilità l’unica strada perché Bitcoin resti rilevante accanto a catene più flessibili.

Andrew Poelstra, ricercatore di Blockstream e tra gli autori delle proposte legate a Taproot, in un’intervista a Bitcoin Magazine del 2024 invitava a parlare apertamente con chi vuole congelare il protocollo, gli «ossificationists», e sosteneva che gli sviluppatori devono «argue passionately and correctly», cioè argomentare con passione e in modo corretto, a favore dei cambiamenti utili a Bitcoin (Bitcoin Magazine). Due anni dopo, quella discussione è ancora apertissima.

Il paradosso è evidente. Taproot è stato l’ultimo soft fork riuscito, a novembre 2021, e da allora Bitcoin vive la fase di quiete più lunga della sua storia sul fronte del consenso, un tema che abbiamo analizzato spiegando perché Taproot resta l’ultimo fork, tra BIP-54 e rischio quantistico. Proprio perché cambiare il consenso è così difficile, l’innovazione si è spostata su ciò che si può fare senza fork: BitVM, rollup e statechain.

Eppure anche Taproot potrebbe doversi evolvere. Il 13 ottobre 2026 un gruppo di ricercatori, tra cui Dan Boneh di Stanford e Scott Aaronson, ha pubblicato per conto di Coinbase un documento che chiede di avviare subito la migrazione post-quantistica di Bitcoin, proponendo architetture di output flessibili come P2MR (il BIP-360) o una ipotetica P2TRv2, insieme a costrutti ibridi 1-di-2 che tengano insieme una firma classica e una post-quantistica (The Block). La minaccia, scrivono, non è imminente ma è ormai chiaramente all’orizzonte, e il NIST raccomanda di completare la transizione entro il 2035. L’idea stessa di una Taproot versione due dice molto: l’aggiornamento del 2021 non è un punto d’arrivo.

Cosa cambia per gli investitori italiani

Un punto va chiarito subito: nessun regolatore approva o blocca questi sviluppi. MiCA, applicata in Italia con Consob per la condotta di mercato e la tutela degli investitori e con Banca d’Italia per gli aspetti prudenziali e sulle stablecoin, regola i fornitori di servizi (CASP) e gli emittenti, non il protocollo Bitcoin, non i soft fork e non gli indirizzi bc1p. Un rollup come Citrea o un ponte come Clementine non ricevono un timbro da nessuna autorità.

Sul piano degli strumenti, invece, la distinzione conta. I derivati costruiti con i DLC, così come future e perpetui sulle piattaforme, restano strumenti finanziari sotto la MiFID II e la vigilanza di Consob, non sotto MiCA, che copre i soli crypto-asset spot e i relativi servizi. Chi tratta questi prodotti deve guardare al regime dei mercati finanziari, non a quello dei crypto-asset.

C’è poi il fisco, dove l’Italia resta un caso particolare in Europa. Un dettaglio tecnico ma importante riguarda i trasferimenti: spostare i propri bitcoin tra tipi di indirizzo che si controllano, per esempio da un indirizzo SegWit bc1q a uno Taproot bc1p, oppure verso un Layer 2 self-custodial, non è una cessione e non realizza una plusvalenza. L’imposta scatta quando si vende o si converte, non quando si cambia il formato tecnico del proprio portafoglio, un tema che si lega al più ampio dibattito su l’anomalia italiana dell’aliquota al 33%.

Sul fronte istituzionale la direzione è chiara. Una custodia trust-minimized e stablecoin regolamentate ancorate a Bitcoin abbassano la barriera per banche e gestori che finora guardavano al settore con diffidenza. Non significa che un rollup diventi improvvisamente adatto a un cliente retail prudente: significa che l’infrastruttura su cui gli intermediari possono costruire prodotti è più solida di un anno fa, e che la distanza tra sperimentazione tecnica e offerta di mercato si sta accorciando.

Resta infine il contesto di mercato. Al 14 ottobre 2026 Bitcoin vale circa 73.364 euro, in calo del 2,1% nelle ultime 24 ore e dell’1,6% in sette giorni (CoinGecko). È un prezzo che pesa sulle valutazioni dei progetti Layer 2, spesso legate alla loro token economy, ma che non cambia la sostanza tecnica: la programmabilità di Bitcoin cresce a prescindere dal ciclo di prezzo.

Cosa aspettarsi ora

Nel breve periodo la partita si gioca su tre tavoli. Il primo è l’annex: la pull request 36466 aprirà un confronto sulla politica di propagazione di Bitcoin Core, con LibreRelay e rbitcoin già a fare da apripista; l’esito dirà quanto il client di riferimento sia disposto a lasciar spazio a usi nuovi dei dati.

Il secondo tavolo è quello dei covenant. Senza una segnalazione dei miner che oggi non si vede, OP_CTV rischia di restare al palo, e in quel caso BitVM continuerà a essere la via maestra per costruire ponti senza aspettare un soft fork. Il terzo è l’espansione dei rollup: Citrea ha aperto la strada, altri progetti seguiranno, e la variabile critica saranno proprio i ponti, perché un modello 1-di-N non è fiducia zero e la liquidità, insieme alla centralizzazione dei sequencer, resta un rischio concreto.

Sopra tutto aleggia l’orologio quantistico, non imminente ma sempre più citato, che spinge verso una Taproot evoluta. La morale, a cinque anni dall’attivazione, è che l’eredità di Taproot non è la privacy che prometteva nel 2021, ma lo spazio di progettazione che ha aperto. Bitcoin non è diventato programmabile cambiando le sue regole, bensì sfruttando fino in fondo quelle che Taproot gli aveva già dato.

Domande frequenti

Che cos’è l’annex di Taproot e perché se ne parla ora?

È un campo opzionale nella struttura witness di un input Taproot, previsto dal 2021 per contenere dati aggiuntivi ma rimasto senza un uso chiaro. Nell’ottobre 2026 Robin Linus, l’autore di BitVM, ha aperto la pull request 36466 su Bitcoin Core per renderne standard la propagazione, in modo da poterlo usare nei protocolli a validazione client-side come Glass Coins.

BitVM richiede un soft fork di Bitcoin?

No. BitVM e la sua versione BitVM2 funzionano con Bitcoin così com’è, sfruttando gli alberi di script MAST e Tapscript introdotti da Taproot. È proprio per questo che i primi Layer 2 trust-minimized del 2026 sono stati costruiti su BitVM invece di attendere l’attivazione dei covenant.

Che cos’è Citrea e come usa Bitcoin?

Citrea è il primo ZK-rollup in produzione che regola direttamente su Bitcoin, attivo in mainnet dal 27 gennaio 2026. Esegue transazioni EVM fuori dalla catena, genera prove a conoscenza zero e le pubblica su Bitcoin, che fa da livello di disponibilità dei dati e di regolamento; il suo ponte Clementine usa BitVM con un’assunzione di fiducia 1-di-N.

Spostare i miei bitcoin su un indirizzo Taproot o su un Layer 2 è un evento fiscale in Italia?

Trasferire i propri bitcoin tra indirizzi che si controllano, per esempio da un indirizzo SegWit a uno Taproot, o verso un Layer 2 self-custodial, non è una cessione e non realizza una plusvalenza. L’imposta scatta quando si vende o si converte in euro o in un altro asset; per la propria posizione specifica conviene comunque verificare con un professionista.

Qual è la differenza tra un rollup come Citrea e una statechain come Spark?

Un rollup come Citrea esegue smart contract fuori dalla catena e ne pubblica le prove su Bitcoin, puntando alla DeFi generalista; una statechain come Spark trasferisce la proprietà delle UTXO ruotando le chiavi tra utente, destinatario e operatori, ed è pensata soprattutto per pagamenti, stablecoin e token. Entrambe si appoggiano a un’assunzione di fiducia 1-di-N, ma con architetture molto diverse.

Di Marcus Okafor, redazione HOGE Wire.