OP_CAT è un opcode di Bitcoin che unisce due dati presenti nello stack in uno solo, ed è attualmente al centro di uno dei dibattiti più longevi nello sviluppo di Bitcoin. Faceva parte del codice originale di Bitcoin, ma è stato rimosso da Satoshi Nakamoto nel 2010 per motivi di sicurezza; negli ultimi anni è stato proposto come soft fork (BIP 347) in grado di sbloccare una nuova categoria di comportamenti simili agli smart contract su Bitcoin. A luglio 2026 non è attivo sulla mainnet di Bitcoin, sebbene sia già in funzione su alcune reti correlate a Bitcoin, dove viene sottoposto in modo discreto a test di stress in pubblico.
Ciò che rende OP_CAT degno di attenzione non è solo il codice. Sono i protagonisti che lo circondano: gli sviluppatori di Bitcoin Core che discutono se la modifica sia sicura, un progetto NFT basato sui meme che ha raccolto decine di milioni di dollari per fare pressione affinché venisse ripristinato, e una sidechain in rapida crescita che lo ha già messo in pratica. Questa guida spiega in dettaglio cosa fa OP_CAT, perché è stato disabilitato, quali possibilità potrebbe offrire e qual è esattamente la situazione attuale.
Utilizza la multichain App Bitcoin.com Wallet, scelto da milioni di persone per inviare, ricevere, acquistare, vendere, scambiare, utilizzare e gestire Bitcoin e criptovalute in modo semplice e sicuro.
Punti chiave
- OP_CAT (abbreviazione di "operation concatenate") unisce due elementi presenti nello stack di Bitcoin in un unico elemento. Questa è l'intera funzione.
- Era presente nel codice iniziale di Bitcoin, ma è stato poi disattivato da Satoshi Nakamoto nel 2010 a causa del rischio di attacchi denial-of-service.
- La proposta per reintrodurla, la BIP 347, è stata redatta da Ethan Heilman e Armin Sabouri e le è stato assegnato il numero BIP nell'aprile 2024.
- OP_CAT non è di per sé un patto, ma, combinato con altri opcode, può essere utilizzato per creare restrizioni di spesa simili a quelle dei patti, compresi i vault.
- A metà del 2026, OP_CAT non era ancora stato attivato sulla rete principale di Bitcoin. I principali candidati per il prossimo soft fork di consenso di Bitcoin sono OP_CTV (BIP 119) e OP_CHECKSIGFROMSTACK (BIP 348), non OP_CAT da solo.
- OP_CAT è già operativo su Fractal Bitcoin, una sidechain allineata a Bitcoin, dove è alla base dello standard del token CAT20, ed è in funzione da anni su Liquid Network e Bitcoin Cash senza che siano stati segnalati casi di exploit.
- Un progetto NFT basato su Bitcoin chiamato Quantum Cats, creato da Taproot Wizards, ha trasformato il supporto a OP_CAT in una campagna meme che ha raccolto oltre 37 milioni di dollari a favore dello sviluppo legato a OP_CAT.
Come funziona OP_CAT
Il modo più chiaro per comprendere OP_CAT è immaginare il sistema di scripting di Bitcoin come una piccola pila di mattoncini. Bitcoin Script, il linguaggio di programmazione alla base di ogni transazione Bitcoin, è un linguaggio basato su pila. I dati vengono inseriti nella pila, i codici operativi agiscono su ciò che si trova in cima e il risultato determina se una transazione è valida.
OP_CAT preleva i primi due elementi dello stack e li concatena, ovvero li unisce uno dopo l’altro in un unico elemento combinato, che viene poi riposto in cima allo stack. Se lo stack contiene i valori "1" e "2", l'esecuzione di OP_CAT rimuove entrambi e li sostituisce con "12". Secondo le specifiche ufficiali in BIP 347, OP_CAT inserirebbe x1 || x2 nello stack, dove il simbolo delle due barre indica la concatenazione.
C'è un limite importante. OP_CAT fallisce se nello stack sono presenti meno di due valori, oppure se la loro unione darebbe origine a un valore combinato superiore a 520 byte, che è la dimensione massima consentita per un elemento dello script in Bitcoin. Questo limite di byte è molto significativo per la storia di questo opcode, di cui parleremo tra poco.
Di per sé, unire due stringhe di dati non sembra una funzionalità particolarmente potente. Tuttavia, il linguaggio di scripting di Bitcoin non ha mai offerto un metodo generico per combinare i valori presenti nello stack, e questa lacuna ha limitato le possibilità degli sviluppatori di integrare direttamente nuove funzionalità nelle transazioni Bitcoin. Come Bitcoin Optech spiega, Tapscript di Bitcoin non dispone di un metodo generico per combinare gli oggetti presenti nello stack, il che limita l'espressività di Tapscript e impedisce, tra le altre cose, di costruire e valutare alberi di Merkle e altre strutture dati basate su hash direttamente in Tapscript. OP_CAT è la soluzione proposta per colmare questa specifica lacuna.
Perché OP_CAT è stato disabilitato nel 2010?
OP_CAT faceva parte della primissima versione di Bitcoin. Satoshi Nakamoto lo ha rimosso, insieme a diversi altri codici operativi come OP_MUL, OP_DIV e OP_OR, nel 2010. La motivazione ufficiale era legata al rischio di un attacco denial-of-service: uno script che utilizzasse ripetutamente OP_CAT avrebbe potuto, in teoria, generare una quantità di dati in crescita esponenziale, sufficientemente grande da rallentare o mandare in crash i nodi che cercavano di convalidarlo.
All’epoca non esisteva un limite rigido alla dimensione massima di un singolo elemento nello stack di Bitcoin. Ciò significava che uno script dannoso avrebbe potuto continuare a concatenare valori fino a produrre una stringa di dati sufficientemente pesante da intasare la rete. La rimozione di OP_CAT, insieme agli altri opcode disabilitati, è stata una mossa prudente che ha privilegiato la stabilità della rete rispetto a funzionalità di cui la rete, ancora agli esordi, non aveva bisogno.
La situazione è cambiata nel novembre 2021, quando Bitcoin ha attivato l’aggiornamento Taproot. Taproot ha introdotto Tapscript, un nuovo contesto di scripting con regole proprie, una delle quali limita ogni singolo elemento dello stack a 520 byte. Tale limite di byte blocca direttamente la via di attacco originaria. Uno script può ancora richiamare OP_CAT, ma non potrà mai produrre un valore sufficientemente grande da creare quel tipo di problema di esaurimento delle risorse che preoccupava Satoshi nel 2010. È proprio questo dettaglio tecnico ad aver riaperto la strada al ritorno di OP_CAT, limitatamente però a Tapscript anziché all’intero Bitcoin Script.
OP_CAT è un Covenant?
No, non di per sé, e questo è uno degli aspetti più comunemente fraintesi riguardo a OP_CAT. Un “covenant”, nel gergo di Bitcoin, è una restrizione sulle modalità con cui un output di transazione non speso (UTXO) potrà essere speso in futuro. Il normale script di Bitcoin può solo verificare se una spesa è autorizzata in quel momento, in genere controllando una firma. Un covenant va oltre, verificando non solo se una spesa è autorizzata, ma anche se la transazione risultante soddisfa una serie specifica di condizioni.
OP_CAT non include alcun meccanismo integrato per l'analisi dei dati delle transazioni. Ciò che offre è un modo per combinare elementi di dati presenti nello stack, che risulta utile per i covenant solo se abbinato ad altri codici operativi che verificano le firme rispetto a tali dati combinati. Lo stesso BIP 347 afferma chiaramente che OP_CAT, sebbene sia stato proposto per essere riattivato in Tapscript, non è un "covenant". È più corretto descriverlo come un elemento costitutivo che, combinato con gli opcode di verifica delle firme, può essere utilizzato per emulare un comportamento simile a quello di un "covenant".
Questo è importante perché la flessibilità di OP_CAT è proprio ciò che lo rende interessante e controverso. Sebbene OP_CAT non sia di per sé un covenant, può emularne il funzionamento grazie a una particolarità nel modo in cui operano le firme Schnorr. In combinazione con un opcode chiamato CheckSigFromStack (CSFS), che verifica una firma rispetto a dati arbitrari anziché solo alla transazione stessa, OP_CAT può essere utilizzato per creare lo stesso tipo di restrizioni di spesa che gli opcode dedicati ai covenant sono progettati per generare.
Per cosa potrebbe essere utilizzato OP_CAT?
Poiché OP_CAT è una primitiva di uso generale piuttosto che una funzionalità con un ambito ristretto, gli sviluppatori ne hanno proposto un’ampia gamma di applicazioni. Tra quelle più frequentemente discusse figurano:
- Casseforti. Un "vault" è un tipo di contratto che richiede diverse fasi, spesso distribuite su transazioni e blocchi distinti, prima che i fondi possano essere trasferiti. Ciò introduce un ritardo intrinseco che concede al proprietario il tempo necessario per individuare e bloccare eventuali spese non autorizzate, migliorando così le configurazioni di cold storage e di custodia condivisa.
- Contratti di non equivoco. Queste misure possono penalizzare un partecipante a un canale di pagamento, come il Lightning Network, che tenti di diffondere uno stato del canale non aggiornato o fraudolento, rafforzando così la sicurezza dei sistemi di pagamento off-chain.
- Tre firme. OP_CAT consente di creare script multisignature compatti, la cui dimensione cresce solo in modo logaritmico con il numero di firmatari; ciò significa che una transazione di meno di 1 kilobyte potrebbe teoricamente supportare condizioni di spesa relative a milioni di chiavi pubbliche.
- Costruzione e verifica dell'albero di Merkle. Poiché la creazione e la verifica di un albero di Merkle richiedono fondamentalmente la concatenazione e l'hash dei valori, OP_CAT fornisce a Bitcoin Script l'elemento mancante necessario per eseguire queste operazioni in modo nativo.
- Firme post-quantistiche. OP_CAT può abilitare le firme Lamport, uno schema di firma considerato resistente agli attacchi dei computer quantistici, poiché le firme Lamport richiedono semplicemente la capacità di eseguire l'hash e concatenare i valori presenti nello stack.
- Attività tokenizzate e ponti cross-chain. Consentendo script più espressivi, OP_CAT potrebbe supportare l'emissione di token direttamente su catene allineate a Bitcoin e la creazione di ponti tra Bitcoin e altre reti che riducano al minimo la necessità di affidarsi a terze parti.
Vale la pena essere chiari anche in questo caso sui compromessi. La stessa flessibilità che rende OP_CAT utile per tutti gli scopi sopra citati è ciò che induce alcuni sviluppatori di Bitcoin a considerarlo con cautela. Poiché OP_CAT è uno strumento generico piuttosto che specifico per uno scopo preciso, apre quello che gli sviluppatori talvolta definiscono un ampio spazio di progettazione, il che significa che è più difficile prevedere tutti i modi in cui potrebbe eventualmente essere combinato con altri opcode. Tale incertezza è al centro del dibattito in corso, non una questione secondaria.
OP_CAT vs. OP_CTV: un confronto tra le due principali proposte di covenant
Di solito si parla di OP_CAT insieme a OP_CTV (OP_CheckTemplateVerify), proposto nel BIP 119 dallo sviluppatore Jeremy Rubin. Entrambi mirano a dotare Bitcoin di una qualche forma di funzionalità relativa ai patti, ma adottano approcci progettuali quasi opposti.
La differenza pratica sta nell’ambito di applicazione. OP_CTV consente a un output di transazione di impegnarsi in un’unica, precisa transazione di spesa futura, specificando dettagli quali la versione, il locktime, gli output e il numero di input. Se il modello corrisponde, la spesa viene eseguita. In caso contrario, non va a buon fine. Questa limitatezza è intenzionale. CTV non è ricorsivo, il che significa che una transazione a cui si vincola non può a sua volta vincolarsi a ulteriori restrizioni in modo da creare una catena permanente di vincoli. I sostenitori ritengono che questa sia la forma più sicura e contenuta di patto.
OP_CAT adotta una filosofia opposta. Anziché risolvere un problema specifico, offre agli sviluppatori una primitiva flessibile e permette loro di costruire su di essa. Mentre CTV è un opcode dal campo di applicazione ben definito, progettato per consentire una serie specifica di casi d’uso, OP_CAT è una primitiva, ovvero la concatenazione di stringhe nello stack, che era già presente nel linguaggio di scripting originale di Bitcoin prima di essere disabilitata nel 2010 a causa di preoccupazioni relative agli attacchi denial-of-service, che non sono più applicabili con i limiti di dimensione degli script post-Taproot. È proprio questa flessibilità che consente a OP_CAT di supportare i covenant ricorsivi, in cui una restrizione può dar luogo a un’altra restrizione a cascata, una proprietà che OP_CTV evita deliberatamente.
OP_CAT è attivo oggi su Bitcoin?
Non sulla rete principale di Bitcoin. Il BIP 347 ha raggiunto lo stato “Complete” come documento di specifica, il che significa che la proposta in sé è completa e ben definita. Ciò è una cosa diversa dall’implementazione, che richiederebbe alla più ampia comunità di Bitcoin e agli operatori dei nodi di attivarla effettivamente tramite un soft fork.
A metà del 2026, OP_CAT non è il candidato principale per il prossimo cambiamento di consenso di Bitcoin. Tale posizione spetta attualmente a OP_CTV insieme a OP_CHECKSIGFROMSTACK (BIP 348), un opcode correlato che consente a uno script di verificare una firma rispetto a dati arbitrari anziché solo alla transazione di spesa stessa. Secondo un Guida di riferimento aggiornata sui BIP di Bitcoin, a metà del 2026, i principali candidati per il prossimo soft fork di consenso sono le proposte di covenant BIP 119 (OP_CHECKTEMPLATEVERIFY) e BIP 348 (OP_CHECKSIGFROMSTACK), che consentirebbero nuove funzionalità di scripting per i vault, le channel factory e protocolli di livello 2 più efficienti, sebbene non sia stata ancora stabilita una tempistica per l’attivazione e il consenso della comunità sia ancora in fase di formazione.
OP_CTV è a uno stadio più avanzato nel processo di attivazione rispetto a OP_CAT. Gli sviluppatori hanno pubblicato parametri di segnalazione concreti per un soft fork in stile BIP9: una data di inizio della segnalazione fissata al 30 marzo 2026, un periodo di timeout di un anno che si conclude il 30 marzo 2027, un’altezza minima di attivazione intorno a maggio 2027 e una soglia di segnalazione dei miner del 90% in ciascun periodo di difficoltà di due settimane. Ciò sottopone CTV allo stesso tipo di meccanismo che ha attivato Taproot nel 2021, sebbene il raggiungimento della soglia del 90% sia tutt’altro che garantito, vista la controversia che le proposte relative ai covenant continuano a suscitare all’interno della comunità degli sviluppatori.
Nulla di tutto ciò significa che OP_CAT sia ormai superato. Significa semplicemente che il dibattito sul “prossimo” soft fork del 2026 è attualmente incentrato su una coppia diversa di opcode, e che il futuro di OP_CAT, se ce ne sarà uno, dipenderà probabilmente dall’esito del dibattito su CTV e CSFS.
OP_CAT è già in funzione altrove
Sebbene OP_CAT sia ancora in attesa di essere implementato sulla mainnet di Bitcoin, non per questo rimane inattivo. Da anni, infatti, è in funzione in modo discreto su una manciata di reti legate a Bitcoin.
- Liquid Network. La sidechain federata di Blockstream ha avuto l'OP_CAT abilitato sin dal suo lancio, fornendo all'ecosistema Bitcoin nel suo complesso un banco di prova nel mondo reale anni prima ancora che il BIP 347 esistesse.
- Bitcoin Cash e Bitcoin SV. Entrambe le reti hanno reintrodotto OP_CAT nel corso degli aggiornamenti del protocollo, e tale opcode ha elaborato transazioni su queste catene senza che siano stati documentati casi di exploit legati all'opcode stesso.
- Bitcoin frattale. Si tratta dell'implementazione attualmente più attiva. Fractal è una sidechain allineata a Bitcoin, realizzata utilizzando il software di Bitcoin Core e sottoposta a merge mining con Bitcoin, che ha lanciato la propria mainnet il 9 settembre 2024 con OP_CAT abilitato sin dal primo giorno.
Vale la pena dare un’occhiata più da vicino a Fractal, perché rappresenta la risposta più chiara alla domanda: “Come funzionerebbe effettivamente su Bitcoin?”. Dal lancio di Fractal, nuovi protocolli hanno sfruttato OP_CAT per creare smart contract basati sul software di Bitcoin, tra cui il CAT Protocol, che ha suscitato notevole interesse tra gli utenti nativi di Bitcoin, insieme ad altri standard emergenti che ampliano le funzionalità della rete utilizzando OP_CAT.
L'esempio più rappresentativo è CAT20, uno standard di token fungibile creato appositamente per sfruttare OP_CAT. Secondo La documentazione ufficiale di Fractal Bitcoin, CAT20 è interamente convalidato dai miner e funziona tramite smart contract, in particolare tramite clausole ricorsive, applicate interamente dal linguaggio di scripting proprio di Bitcoin a livello di base, il che lo distingue dagli standard di token che si affidano a una convalida esterna o da parte di terzi. In pratica, ciò significa che l’implementazione, il conio e il trasferimento di un token CAT20 avvengono attraverso una sequenza di operazioni OP_CAT che formano un’unica stringa di dati, la quale viene poi registrata direttamente sulla blockchain e verificata dagli stessi miner che proteggono la rete, anziché da un servizio di indicizzazione off-chain separato.
La storia dei Quantum Cats: come una campagna basata sui meme ha dato slancio a OP_CAT
La maggior parte delle proposte di opcode rimane confinata alle mailing list e alle discussioni su GitHub. OP_CAT non è stato così, soprattutto grazie a un progetto di Bitcoin Ordinals chiamato Taproot Wizards.
Nel gennaio 2024, Taproot Wizards ha lanciato una collezione in stile NFT composta da 3.333 pezzi chiamata Quantum Cats, ideata interamente con l’obiettivo di ottenere il sostegno pubblico per la riattivazione di OP_CAT. Quantum Cats voleva che OP_CAT creasse un bridge senza autorizzazione in grado di trasferire bitcoin e asset basati su bitcoin sulle catene di livello 2 di Bitcoin, dove potessero essere oggetto di operazioni di trading più complesse. Per poter partecipare al conio, i partecipanti dovevano informarsi sulla proposta tecnica effettiva e sostenerne pubblicamente il ritorno, trasformando una discussione piuttosto arida sul BIP in una campagna comunitaria con interessi concreti in gioco.
La collezione stessa fungeva anche da dimostrazione pratica della concatenazione. Ogni Quantum Cat fa riferimento a diversi file distinti anziché a un’unica immagine statica e, man mano che nel tempo vengono svelati nuovi file, i gatti cambiano, rispecchiando esattamente ciò che fa OP_CAT unendo insieme frammenti di dati separati.
La campagna ha funzionato così bene da tradursi in un finanziamento consistente. Taproot Wizards ha raccolto 7,5 milioni di dollari nel 2023, seguiti da un round da 30 milioni di dollari nel febbraio 2025, entrambi destinati espressamente allo sviluppo dell’ecosistema OP_CAT. Il cofondatore Udi Wertheimer ha descritto il progetto come incentrato su OP_CAT in quanto futuro di Bitcoin, con i finanziamenti destinati sia allo sviluppo interno che al sostegno di team esterni che lavorano sull’opcode. Una singola vendita di Quantum Cat da Sotheby’s, il “Genesis Cat”, si è conclusa a 254.000 dollari, sottolineando quanto peso culturale la campagna avesse acquisito attorno a un opcode di quattro byte.
È un utile promemoria del fatto che i dibattiti tecnici sul Bitcoin non rimangono sempre di natura tecnica. Meme, arte e denaro sono diventati più volte strumenti per portare le discussioni sul protocollo all’attenzione di un pubblico più ampio, e OP_CAT è uno degli esempi recenti più evidenti di questo fenomeno.
Conclusione
OP_CAT svolge una funzione molto semplice: unisce due dati presenti nello stack di Bitcoin in uno solo. Ciò che lo rende significativo è tutto ciò che quella singola funzione potrebbe rendere possibile, dai depositi di cold storage più sicuri alle firme post-quantistiche fino ai token nativi di Bitcoin, qualora la comunità di Bitcoin decidesse di reintrodurlo. A luglio 2026, tale accordo non è ancora stato raggiunto. Il BIP 347 è una specifica completa che si colloca dopo OP_CTV e OP_CHECKSIGFROMSTACK nella lista delle priorità per il prossimo soft fork di consenso di Bitcoin, anche se OP_CAT continua a funzionare silenziosamente e senza incidenti su Fractal Bitcoin, Liquid e altre reti legate a Bitcoin. Qualunque cosa accada in futuro, il dibattito su OP_CAT ha già dimostrato come un piccolo e semplice frammento di codice possa attirare contemporaneamente sviluppatori, artisti e investitori.
