OP_CAT é um opcode do Bitcoin que une dois dados na pilha em um único, e atualmente é objeto de um dos debates mais antigos no desenvolvimento do Bitcoin. Ele fazia parte do código original do Bitcoin, foi removido por Satoshi Nakamoto em 2010 devido a preocupações com a segurança e passou os últimos anos como uma proposta de soft fork (BIP 347) que poderia possibilitar uma nova categoria de comportamento semelhante ao de contratos inteligentes no Bitcoin. Em julho de 2026, ele não estava ativo na rede principal do Bitcoin, embora já estivesse em operação em algumas redes adjacentes ao Bitcoin, onde está sendo discretamente submetido a testes de estresse em público.
O que faz com que valha a pena entender o OP_CAT não é apenas o código. É o conjunto de atores envolvidos: desenvolvedores do Bitcoin Core debatendo se a mudança é segura, um projeto de NFT impulsionado por memes que arrecadou dezenas de milhões de dólares para fazer lobby pelo seu retorno e uma sidechain em rápido crescimento que já o colocou em prática. Este guia explica o que o OP_CAT faz, por que foi desativado, o que ele poderia possibilitar e exatamente qual é a situação atual.
Use o multichain Aplicativo Bitcoin.com Wallet, que conta com a confiança de milhões de pessoas para enviar, receber, comprar, vender, trocar, usar e gerenciar Bitcoin e criptomoedas com segurança e facilidade.
Pontos principais
- OP_CAT (abreviação de “operação de concatenação”) combina dois itens de dados na pilha do Bitcoin em um único item. Essa é toda a função.
- Essa funcionalidade estava presente no código inicial do Bitcoin, mas foi desativada por Satoshi Nakamoto em 2010 devido a um risco de ataque de negação de serviço.
- A proposta para reintroduzi-la, a BIP 347, foi elaborada por Ethan Heilman e Armin Sabouri e recebeu seu número de BIP em abril de 2024.
- O OP_CAT não é, por si só, um covenant, mas, quando combinado com outros opcodes, pode ser usado para criar restrições de gastos semelhantes às de um covenant, incluindo vaults.
- Até meados de 2026, o OP_CAT ainda não havia sido ativado na rede principal do Bitcoin. Os principais candidatos atuais para a próxima soft fork de consenso do Bitcoin são o OP_CTV (BIP 119) e o OP_CHECKSIGFROMSTACK (BIP 348), e não o OP_CAT isoladamente.
- O OP_CAT já está em operação na Fractal Bitcoin, uma sidechain alinhada ao Bitcoin, onde sustenta o padrão de token CAT20, e vem sendo executado na Liquid Network e no Bitcoin Cash há anos sem que se tenha conhecimento de nenhuma vulnerabilidade explorada.
- Um projeto de NFT de Bitcoin chamado Quantum Cats, criado pela Taproot Wizards, transformou o apoio ao OP_CAT em uma campanha de meme que arrecadou mais de US$ 37 milhões para o desenvolvimento relacionado ao OP_CAT.
Como funciona o OP_CAT
A maneira mais clara de entender o OP_CAT é imaginar o sistema de scripts do Bitcoin como uma pequena pilha de blocos de construção. O Bitcoin Script, a linguagem de programação por trás de todas as transações de Bitcoin, é uma linguagem baseada em pilha. Os dados são inseridos na pilha, os códigos de operação atuam sobre o que estiver no topo, e o resultado determina se uma transação é válida.
OP_CAT pega os dois itens do topo da pilha e os concatena, ou seja, os une de ponta a ponta em um único item combinado, que é então colocado de volta no topo da pilha. Se a pilha contiver os valores “1” e “2”, a execução de OP_CAT remove ambos e os substitui por “12”. De acordo com a especificação oficial em BIP 347, OP_CAT colocaria x1 || x2 na pilha, onde o símbolo de dois tubos denota concatenação.
Há uma restrição importante. O OP_CAT falha se houver menos de dois valores na pilha ou se a junção deles resultasse em um valor combinado maior que 520 bytes, que é o tamanho máximo permitido para um elemento de script no Bitcoin. Esse limite de bytes é muito importante para a história desse opcode, assunto que abordaremos em breve.
Por si só, juntar duas sequências de dados não parece ser algo muito poderoso. Mas a linguagem de script do Bitcoin nunca teve uma maneira genérica de combinar valores na pilha, e essa lacuna limitou o que os desenvolvedores podem incorporar diretamente nas transações do Bitcoin. Como A Bitcoin Optech explica, O Tapscript do Bitcoin carece de uma maneira genérica de combinar objetos na pilha, o que restringe a expressividade do Tapscript e impede, entre outras coisas, a capacidade de construir e avaliar árvores de Merkle e outras estruturas de dados com hash diretamente no Tapscript. O OP_CAT é a solução proposta para essa lacuna específica.
Por que o OP_CAT foi desativado em 2010?
O OP_CAT fazia parte da primeira versão do Bitcoin. Satoshi Nakamoto o removeu, juntamente com vários outros códigos de operação, como OP_MUL, OP_DIV e OP_OR, em 2010. A justificativa oficial centrou-se no risco de negação de serviço: um script que utilizasse o OP_CAT repetidamente poderia, em teoria, gerar um volume de dados que crescesse exponencialmente, grande o suficiente para desacelerar ou travar os nós que tentassem validá-lo.
Na época, não havia um limite rígido para o tamanho de um único item na pilha do Bitcoin. Isso significava que um script malicioso poderia continuar concatenando valores até produzir uma sequência de dados pesada o suficiente para sobrecarregar a rede. A remoção do OP_CAT, juntamente com os outros opcodes desativados, foi uma medida conservadora que priorizou a estabilidade da rede em detrimento de funcionalidades das quais a rede, ainda em fase inicial, não precisava.
O cenário mudou em novembro de 2021, quando o Bitcoin ativou a atualização Taproot. O Taproot introduziu o Tapscript, um novo contexto de script com regras próprias, sendo que uma delas limita qualquer item individual da pilha a 520 bytes. Esse limite de bytes bloqueia diretamente a via de ataque original. Um script ainda pode chamar o OP_CAT, mas nunca poderá produzir um valor grande o suficiente para criar o tipo de problema de esgotamento de recursos que preocupava Satoshi em 2010. Esse é o detalhe técnico que reabriu as portas para o retorno do OP_CAT, agora restrito apenas ao Tapscript, em vez de abranger todo o Bitcoin Script.
O OP_CAT é um Pacto?
Não, não por si só, e esse é um dos pontos mais comumente mal interpretados sobre o OP_CAT. Um “covenant”, em termos do Bitcoin, é uma restrição sobre como uma saída de transação não gasta (UTXO) pode ser gasta no futuro. O Bitcoin Script normal só consegue verificar se um gasto está autorizado no momento, geralmente por meio da verificação de uma assinatura. Um covenant vai além, verificando não apenas se um gasto está autorizado, mas também se a transação resultante atende a um conjunto específico de condições.
O OP_CAT não inclui nenhum mecanismo integrado para inspecionar dados de transação. O que ele oferece é uma maneira de combinar fragmentos de dados na pilha, o que só se torna útil para cláusulas de contrato quando combinado com outros códigos de operação que verificam assinaturas em relação a esses dados combinados. O próprio BIP 347 afirma claramente que o OP_CAT, embora tenha sido proposto para reativação no Tapscript, não é um covenant. É mais correto descrevê-lo como um bloco de construção que, combinado com opcodes de verificação de assinatura, pode ser usado para emular um comportamento semelhante ao de um covenant.
Isso é importante porque a flexibilidade do OP_CAT é exatamente o que o torna interessante e controverso. Embora o OP_CAT possa não ser um covenant por si só, ele pode emular covenants devido a uma peculiaridade no funcionamento das assinaturas Schnorr. Combinado com um opcode chamado CheckSigFromStack (CSFS), que verifica uma assinatura em relação a dados arbitrários, em vez de apenas à própria transação, o OP_CAT pode ser usado para criar o mesmo tipo de restrições de gastos que os opcodes dedicados a acordos foram projetados para criar.
Para que o OP_CAT poderia ser usado?
Como o OP_CAT é uma primitiva de uso geral, e não um recurso de escopo restrito, os desenvolvedores propuseram uma ampla gama de aplicações para ele. Entre as mais discutidas estão:
- Cofres. Um “vault” é um tipo de contrato que exige várias etapas, muitas vezes envolvendo transações e blocos distintos, antes que os fundos possam ser movimentados. Isso adiciona um atraso embutido que dá ao proprietário tempo para perceber e impedir gastos não autorizados, aprimorando as configurações de armazenamento a frio e de custódia compartilhada.
- Contratos de exclusão de dúvidas. Isso pode penalizar uma parte em um canal de pagamento, como a Lightning Network, que tente transmitir um estado do canal desatualizado ou fraudulento, reforçando a segurança dos sistemas de pagamento fora da cadeia.
- Assinaturas de árvores. O OP_CAT permite a criação de scripts de assinatura múltipla compactos, cujo tamanho cresce apenas logaritmicamente com o número de signatários, o que significa que uma transação com menos de 1 kilobyte poderia, teoricamente, suportar condições de gasto envolvendo milhões de chaves públicas.
- Construção e verificação da árvore de Merkle. Como a construção e a verificação de uma árvore de Merkle exigem, fundamentalmente, a concatenação e o hash de valores, o OP_CAT fornece ao Bitcoin Script a peça que faltava para realizar isso de forma nativa.
- Assinaturas pós-quânticas. O OP_CAT pode habilitar as assinaturas de Lamport, um esquema de assinatura considerado resistente a ataques de computadores quânticos, uma vez que as assinaturas de Lamport exigem nada mais do que a capacidade de gerar hash e concatenar valores na pilha.
- Ativos tokenizados e pontes entre cadeias. Ao permitir scripts mais expressivos, o OP_CAT poderia viabilizar a emissão de tokens diretamente em cadeias alinhadas ao Bitcoin e pontes com menor necessidade de confiança entre o Bitcoin e outras redes.
Vale a pena ser direto sobre as vantagens e desvantagens também neste caso. A mesma flexibilidade que torna o OP_CAT útil para todos os casos acima é o que faz com que alguns desenvolvedores do Bitcoin sejam cautelosos em relação a ele. Como o OP_CAT é de uso geral, e não foi criado para uma finalidade específica, ele abre o que os desenvolvedores às vezes chamam de um amplo espaço de design, o que significa que é mais difícil prever todas as maneiras pelas quais ele poderá eventualmente ser combinado com outros opcodes. Essa incerteza é o cerne do debate em andamento, e não uma questão secundária.
OP_CAT x OP_CTV: Como se comparam as duas principais propostas de covenant
O OP_CAT costuma ser discutido juntamente com o OP_CTV (OP_CheckTemplateVerify), proposto no BIP 119 pelo desenvolvedor Jeremy Rubin. Ambos têm como objetivo dotar o Bitcoin de algum tipo de capacidade de contrato, mas adotam abordagens de projeto quase opostas.
A diferença prática se resume ao escopo. O OP_CTV permite que uma saída de transação se comprometa com uma única transação de gasto futura específica, abrangendo detalhes como a versão, o locktime, as saídas e o número de entradas. Se corresponder ao modelo, o gasto é aprovado. Se não corresponder, ela não é aprovada. Essa restrição é intencional. O CTV não é recursivo, o que significa que uma transação à qual ele se vincula não pode, por sua vez, se vincular a restrições adicionais de forma a criar uma cadeia permanente de restrições. Os defensores consideram essa a forma mais segura e contida de acordo.
O OP_CAT adota uma filosofia oposta. Em vez de resolver um problema específico, ele oferece aos desenvolvedores uma primitiva flexível e permite que eles construam sobre ela. Enquanto o CTV é um código de operação com escopo cuidadosamente definido, projetado para possibilitar um conjunto específico de casos de uso, o OP_CAT é uma primitiva — a concatenação de strings na pilha — que já fazia parte da linguagem de script original do Bitcoin antes de ser desativada em 2010 devido a preocupações com ataques de negação de serviço, que não se aplicam mais sob os limites de tamanho de script pós-Taproot. É essa mesma flexibilidade que permite ao OP_CAT suportar cláusulas recursivas, nas quais uma restrição pode gerar outra restrição posteriormente — uma propriedade que o OP_CTV evita deliberadamente.
O OP_CAT já está em operação na Bitcoin hoje?
Não na rede principal do Bitcoin. O BIP 347 atingiu o status “Concluído” como documento de especificação, o que significa que a proposta em si está finalizada e bem definida. Isso é algo distinto da sua implantação, que exigiria que a comunidade mais ampla do Bitcoin e os operadores de nós realmente a ativassem por meio de um soft fork.
Em meados de 2026, o OP_CAT não é o principal candidato para a próxima mudança no consenso do Bitcoin. Essa posição pertence atualmente ao OP_CTV, juntamente com o OP_CHECKSIGFROMSTACK (BIP 348), um código de operação relacionado que permite que um script verifique uma assinatura em relação a dados arbitrários, em vez de apenas à própria transação de gasto. De acordo com um Guia de referência recente sobre o BIP do Bitcoin, em meados de 2026, os principais candidatos para o próximo soft fork de consenso são as propostas de covenant BIP 119 (OP_CHECKTEMPLATEVERIFY) e BIP 348 (OP_CHECKSIGFROMSTACK), que possibilitariam novos recursos de script para cofres, fábricas de canais e protocolos de camada 2 mais eficientes, embora nenhum cronograma de ativação tenha sido definido e o consenso da comunidade ainda esteja se formando.
O OP_CTV avançou mais no processo de ativação do que o OP_CAT. Os desenvolvedores publicaram parâmetros concretos de sinalização para um soft fork no estilo BIP9: uma data de início da sinalização em 30 de março de 2026, um prazo de espera de um ano que se encerra em 30 de março de 2027, uma altura mínima de ativação por volta de maio de 2027 e um limite de sinalização de 90% dos mineradores em cada período de dificuldade de duas semanas. Isso submete o CTV ao mesmo tipo de mecanismo que ativou o Taproot em 2021, embora atingir o limite de 90% esteja longe de ser garantido, dada a controvérsia que as propostas de covenant ainda geram na comunidade de desenvolvedores.
Nada disso significa que o OP_CAT esteja morto. Significa que a “próxima” discussão sobre o soft fork em 2026 está, no momento, centrada em um par diferente de opcodes, e que o caminho a seguir para o OP_CAT, se é que há um, provavelmente dependerá de como se desenrolará primeiro o debate sobre CTV e CSFS.
O OP_CAT já está em execução em outros lugares
Embora o OP_CAT ainda esteja aguardando sua implementação na rede principal do Bitcoin, ele não está parado sem ser testado. Há anos, ele vem sendo executado discretamente em ambiente de produção em algumas redes relacionadas ao Bitcoin.
- Liquid Network. A sidechain federada da Blockstream tem o OP_CAT habilitado desde o seu lançamento, proporcionando ao ecossistema mais amplo do Bitcoin um ambiente de testes no mundo real anos antes mesmo de o BIP 347 existir.
- Bitcoin Cash e Bitcoin SV. Ambas as redes reintroduziram o OP_CAT durante atualizações de protocolo, e ele tem processado transações nessas cadeias sem que tenha sido documentada nenhuma vulnerabilidade relacionada ao próprio código de operação.
- Bitcoin Fractal. Esta é a implantação mais ativa no momento. A Fractal é uma sidechain alinhada ao Bitcoin, desenvolvida com o próprio software do Bitcoin Core e submetida a mineração combinada com o Bitcoin, que lançou sua mainnet em 9 de setembro de 2024 com o OP_CAT habilitado desde o primeiro dia.
Vale a pena dar uma olhada mais de perto no Fractal, pois ele é a resposta mais clara para a pergunta “como isso funcionaria, na prática, no Bitcoin?”. Desde o lançamento do Fractal, novos protocolos têm aproveitado o OP_CAT para criar contratos inteligentes baseados no software do Bitcoin, incluindo o Protocolo CAT, que tem atraído grande interesse entre os usuários nativos do Bitcoin, além de outros padrões emergentes que ampliam a funcionalidade da rede por meio do OP_CAT.
O exemplo mais emblemático é o CAT20, um padrão de token fungível criado especificamente para aproveitar as vantagens do OP_CAT. De acordo com A própria documentação da Fractal Bitcoin, o CAT20 é totalmente validado pelos mineradores e opera por meio de contratos inteligentes, especificamente cláusulas recursivas, executadas inteiramente pela própria linguagem de script do Bitcoin na camada base, o que o distingue dos padrões de tokens que dependem de validação externa ou de terceiros. Na prática, isso significa que a implantação, a cunhagem e a transferência de um token CAT20 ocorrem por meio de uma sequência de operações OP_CAT que formam uma única sequência de dados, a qual é então inscrita diretamente na blockchain e verificada pelos mesmos mineradores que protegem a rede, em vez de por um serviço de indexação externo à blockchain.
A história dos Quantum Cats: como uma campanha de memes impulsionou o OP_CAT
A maioria das propostas de opcodes fica restrita às listas de discussão e aos tópicos do GitHub. O OP_CAT não foi assim, em grande parte graças a um projeto de Bitcoin Ordinals chamado Taproot Wizards.
Em janeiro de 2024, a Taproot Wizards lançou uma coleção no estilo NFT com 3.333 peças chamada Quantum Cats, criada inteiramente com o objetivo de gerar apoio público para a reativação do OP_CAT. A Quantum Cats desejava que o OP_CAT criasse uma ponte sem permissão capaz de transferir bitcoins e ativos baseados em bitcoin para cadeias de camada 2 do Bitcoin, onde pudessem participar de negociações mais complexas. Para se qualificarem para a cunhagem, os participantes precisavam se informar sobre a proposta técnica propriamente dita e defender publicamente seu retorno, transformando uma discussão bastante árida sobre o BIP em uma campanha comunitária com interesses reais em jogo.
A própria coleção serviu também como uma demonstração prática da concatenação. Cada Quantum Cat remete a vários arquivos distintos, em vez de uma única imagem estática, e, à medida que novos arquivos são revelados ao longo do tempo, os gatos mudam, refletindo exatamente o que o OP_CAT faz ao reunir partes distintas de dados.
A campanha teve um desempenho tão bom que resultou em um financiamento significativo. A Taproot Wizards levantou US$ 7,5 milhões em 2023, seguido por uma rodada de US$ 30 milhões em fevereiro de 2025, ambos os recursos destinados explicitamente ao desenvolvimento do ecossistema OP_CAT. O cofundador Udi Wertheimer descreveu o projeto como focado no OP_CAT como o futuro do Bitcoin, com o financiamento destinado tanto ao desenvolvimento interno quanto ao apoio a equipes externas que trabalham com o opcode. Uma única venda do Quantum Cat na Sotheby’s, o “Genesis Cat”, foi arrematada por US$ 254.000, ressaltando o peso cultural que a campanha havia adquirido em torno de um opcode de quatro bytes.
É um lembrete útil de que os debates técnicos sobre o Bitcoin nem sempre se limitam ao âmbito técnico. Memes, arte e dinheiro têm se tornado, repetidamente, ferramentas para ampliar o alcance das discussões sobre o protocolo, e o OP_CAT é um dos exemplos mais claros desse padrão nos últimos tempos.
Conclusão
O OP_CAT faz uma coisa simples: une dois dados na pilha do Bitcoin em um único. O que o torna significativo é tudo o que essa única função poderia possibilitar — desde cofres de armazenamento a frio mais seguros até assinaturas pós-quânticas e tokens nativos do Bitcoin —, caso a comunidade do Bitcoin venha a concordar em trazê-lo de volta. Até julho de 2026, esse acordo ainda não havia ocorrido. A BIP 347 é uma especificação finalizada que está atrás do OP_CTV e do OP_CHECKSIGFROMSTACK na fila para o próximo soft fork de consenso do Bitcoin, mesmo enquanto o OP_CAT continua funcionando discretamente e sem incidentes no Fractal Bitcoin, no Liquid e em outras redes relacionadas ao Bitcoin. Aconteça o que acontecer a seguir, o debate em torno do OP_CAT já mostrou como um trecho pequeno e simples de código pode atrair desenvolvedores, artistas e investidores ao mesmo tempo.
