Saltar para o conteúdo principal

O Renascimento dos Covenants do Bitcoin: Como OP_CTV, LNHANCE, OP_CAT e BitVM2 Podem Finalmente Trazer Contratos Inteligentes para a L1 do Bitcoin

· 15 min de leitura
Dora Noda
Dora Noda
Software Engineer

Durante quinze anos, a linguagem de script do Bitcoin tem sido deliberada e agressivamente entediante. Sem loops. Sem recursão. Sem estado. Uma pilha pequena, um punhado de opcodes e uma cultura que trata cada expansão proposta como uma potencial guerra civil. Esse conservadorismo é a razão pela qual o Bitcoin nunca foi explorado com sucesso na camada de consenso — e a razão pela qual os desenvolvedores que queriam construir algo além de "enviar moedas de A para B" acabaram desistindo e mudando para o Ethereum.

Esse cálculo está mudando em 2026. O OP_CHECKTEMPLATEVERIFY tem parâmetros de ativação concretos na mesa pela primeira vez desde que o BIP-119 foi redigido. O OP_CAT tem um número oficial de BIP. O LNHANCE está sendo discutido ativamente como uma alternativa focada na Lightning. E o BitVM2 — que não requer nenhum soft fork — já está em produção, alimentando a ponte (bridge) da mainnet da Citrea que foi lançada em janeiro. Após anos de "os covenants estão chegando", o Bitcoin está finalmente na fase em que múltiplas propostas credíveis estão rodando em paralelo, cada uma resolvendo uma fatia diferente do problema.

O que são Covenants de Fato (E por que têm sido tão polêmicos)​

Um covenant, em termos de Bitcoin, é uma restrição sobre como um UTXO pode ser gasto no futuro. O script normal do Bitcoin só pode responder à pergunta "este gasto está autorizado agora?". Um covenant estende isso para "este gasto está autorizado e a próxima transação corresponde a estas condições?".

Essa pequena extensão desbloqueia uma quantidade surpreendente de funcionalidades. Cofres (Vaults) que impõem um atraso de tempo obrigatório antes que os fundos possam sair de um destino específico. Compromissos de controle de congestionamento que permitem que uma transação on-chain financie milhares de pagamentos off-chain. Pools de pagamento. Canais não interativos. Pontes de ZK-rollup que não dependem de federações multisig. A lista de coisas que se tornam possíveis é longa o suficiente para que os desenvolvedores discutam sobre covenants pela maior parte de uma década.

Por que a briga? Duas preocupações reais, uma cultural. Tecnicamente, covenants recursivos — covenants que se impõem a cada gasto subsequente, para sempre — poderiam, teoricamente, ser usados para criar moedas permanentemente restritas, prejudicando a fungibilidade do Bitcoin. Culturalmente, o ethos de desenvolvimento do Bitcoin trata cada novo opcode como uma superfície de ataque potencial, e habilitar covenants após o Taproot é, para alguns desenvolvedores, uma expansão inaceitável do orçamento de complexidade do protocolo. A cobertura da Bitcoin Magazine sobre o debate do BIP-119 capturou essa dinâmica de forma direta: "Habilitar covenants no Bitcoin é uma grande mudança com quase nenhuma pesquisa existente sobre o tema, e tentar forçar sua passagem pela porta dos fundos tão cedo após a ativação do Taproot deve ser resistido."

Três anos de pesquisa adicional depois, essa crítica de "quase nenhuma" é mais difícil de sustentar.

OP_CTV (BIP-119): A Proposta de Cofre Minimalista​

O OP_CHECKTEMPLATEVERIFY é a proposta de covenant mais próxima da ativação real. De autoria de Jeremy Rubin, o BIP-119 adiciona um único opcode que compromete um UTXO a ser gasto em um modelo de transação específico e predeterminado — a versão, locktime, contagem de entradas, sequências, contagem de saídas, saídas e a posição da entrada de gasto. Corresponda ao modelo e você poderá gastar. Não corresponda e não poderá.

É isso. O OP_CTV é não recursivo por design: você pode se comprometer com uma transação futura, mas essa transação futura não pode, por si só, se comprometer com transações posteriores de uma forma que crie uma restrição perpétua. Essa limitação deliberada é o motivo pelo qual os defensores do CTV o consideram o covenant "seguro" — ele permite cofres, controle de congestionamento e certas melhorias na Lightning, mas não pode ser usado para construir moedas permanentemente contaminadas.

As notícias concretas para 2026: os parâmetros de implantação do CTV agora especificam um horário de início em 30 de março de 2026, um tempo limite em 30 de março de 2027, uma altura mínima de ativação em maio de 2027, um limite de sinalização de mineradores de 90% e um período de sinalização de 2016 blocos. Isso não é consenso — é uma proposta de parâmetros de ativação. Mas é a primeira vez desde 2022 que um cronograma concreto está na mesa, e representa o campo do CTV trazendo a questão à tona: ative-o ou rejeite-o formalmente.

A killer app prática para o CTV é o cofre (vault). Hoje, se um usuário deseja fazer a autocustódia de US$ 1 milhão em Bitcoin com proteção contra comprometimento de chave única, suas opções são complicadas: multisig com distribuição geográfica de chaves (operacionalmente doloroso), transações com trava de tempo (frágeis) ou serviços de custódia (anula o propósito). Um cofre CTV permite que um usuário se comprometa a que qualquer gasto de seu armazenamento frio deva primeiro passar por um endereço intermediário com trava de tempo, durante o qual o usuário pode detectar atividades não autorizadas e acionar uma recuperação (clawback). Este é o tipo de primitiva que altera materialmente o perfil de risco de grandes participações em Bitcoin.

OP_CAT (BIP-347): O Caminho Maximalista do Covenant Recursivo​

O OP_CAT é quase a proposta oposta filosoficamente. Enquanto o CTV é um opcode cuidadosamente delimitado e projetado para permitir um conjunto específico de casos de uso, o OP_CAT é uma primitiva — concatenação de strings na pilha — que já estava na linguagem de script original do Bitcoin antes de ser desativada em 2010 por preocupações de DoS que não se aplicam mais aos limites de tamanho de script pós-Taproot.

Reativar o OP_CAT não parece muito à primeira vista: apenas permite que os scripts concatenem duas strings de bytes. Mas a concatenação, combinada com as assinaturas Schnorr introduzidas pelo Taproot, é suficiente para construir introspecção — a capacidade de um script examinar a transação que o está gastando. E a introspecção é suficiente para construir covenants recursivos, máquinas de estado e, por extensão, quase qualquer contrato inteligente que você poderia escrever em uma rede estilo EVM.

A StarkWare publicou um covenant de ponte de prova de conceito no Bitcoin habilitado para OP_CAT que demonstra exatamente isso: ponte com minimização de confiança do Bitcoin para L2s, aplicada inteiramente pelo script do Bitcoin, sem exigir uma multisig federada ou uma cadeia de ponte separada. A equipe do sCrypt publicou uma série de várias partes mostrando como o OP_CAT permite contratos UTXO com estado, negociação de ordinais estilo NFT e cofres recursivos.

O trade-off é exatamente o que os defensores do CTV temem. A expressividade do OP_CAT inclui a capacidade de criar moedas permanentemente restritas. Na prática, isso já existe em formas mais fracas (multisig com chaves perdidas, travas de tempo com maturidade impossivelmente distante), e os defensores do OP_CAT argumentam que a preocupação com a fungibilidade é teórica e não operacional. Mas a divisão filosófica é real: o OP_CTV diz "vamos habilitar covenants para estes casos de uso específicos"; o OP_CAT diz "vamos habilitar a primitiva e deixar os desenvolvedores descobrirem os casos de uso".

O OP_CAT ter recebido o BIP-347 em 2024 foi importante menos por sua substância técnica — o CAT é um opcode de quatro bytes — do que por sinalizar que o caminho maximalista do covenant tinha credibilidade de desenvolvedor suficiente para passar pelo processo de BIP.

LNHANCE: O Compromisso Focado na Lightning​

LNHANCE é a proposta com o argumento de venda mais claro sobre "que problema isso resolve". Em vez de defender covenants com base em fundamentos abstratos, o LNHANCE agrupa o OP_CTV com o OP_CHECKSIGFROMSTACK (CSFS) e o OP_INTERNALKEY, visando especificamente melhorias na Lightning Network.

A Lightning Network em abril de 2026 cresceu para mais de 65.000 nós públicos e tornou-se o trilho de pagamentos dominante do Bitcoin, mas carrega uma dívida real de protocolo. A verificação do estado do canal ainda requer serviços de watchtower ou carteiras online. Channel factories e canais multipartidários são difíceis de construir. Aberturas de canais não interativas — onde uma parte pode abrir um canal para outra sem que o destinatário esteja online — não são possíveis na Lightning atual.

O LNHANCE permite o LN-Symmetry (um mecanismo de estado de canal mais limpo), timeout trees (fechamentos eficientes de canais em lote), scripts PTLC simplificados (contratos de tempo bloqueado por ponto substituindo os atuais contratos de tempo bloqueado por hash), canais não interativos unidirecionais, vaults aprimorados e pools de moedas trustless. Cada um deles é uma melhoria concreta para a Lightning, em vez de uma primitiva especulativa de contrato inteligente.

Esse enquadramento pragmático é a vantagem política do LNHANCE. A Lightning Network alcançou adoção real, desde processadores de pagamentos regionais até o protocolo L402 que o Lightning Labs está posicionando como a camada de pagamentos nativa para transações de agentes de IA. Melhorias que mantêm a Lightning competitiva são mais fáceis de justificar do que melhorias que permitem principalmente casos de uso de BTC em outras redes.

BitVM2: A Alternativa Livre de Soft Fork que Já Está Ativa​

O desenvolvimento pragmaticamente mais importante dos últimos dezoito meses não é, de forma alguma, uma proposta de covenant — é o BitVM2, e o fato de que ele requer zero mudanças no consenso do Bitcoin.

O BitVM2, de autoria de Robin Linus, extrai a essência do que os covenants permitem (computação off-chain verificável ancorada no Bitcoin) sem exigir que o próprio Bitcoin execute a computação. O protocolo funciona em um modelo de desafio-resposta: um provador faz uma afirmação sobre alguma computação off-chain, deposita uma garantia e, se um verificador acreditar que a afirmação está errada, ele pode iniciar uma disputa de busca binária que isola a etapa específica onde o provador trapaceou. Essa única etapa é então executada on-chain no script do Bitcoin, e a garantia do mentiroso é submetida ao slash.

A elegância econômica: provadores honestos nunca são desafiados, portanto as disputas são raras e o custo on-chain é amortizado para quase zero. A elegância computacional: o protocolo revisado do BitVM2 resolve qualquer disputa em apenas três transações on-chain, abaixo das dezenas exigidas no esquema original do BitVM. A elegância permissionless: qualquer pessoa pode desafiar, então a segurança do sistema não depende de um conjunto fixo de verificadores que permaneçam honestos.

O BitVM2 já está ativo. Citrea — o primeiro ZK-rollup do Bitcoin — lançou sua mainnet em 27 de janeiro de 2026, com uma ponte baseada em BitVM2 (codinome "Clementine") como o modelo de confiança de produção. A GOAT Network lançou sua testnet V3 do BitVM2 no primeiro trimestre de 2026, visando uma stack completa de zkRollup nativa do Bitcoin. O padrão está se tornando claro: equipes que não querem apostar seu cronograma de lançamento em um soft fork controverso do Bitcoin estão escolhendo o BitVM2 em vez disso.

A limitação é econômica, não criptográfica. As disputas são pagas em blockspace do Bitcoin e, em um cenário de pior caso onde as taxas aumentam durante uma janela de disputa, os desafiadores podem ser excluídos pelo preço. Esse risco de "economia de disputa" é o problema em aberto que os operadores do BitVM2 estão gerenciando com excesso de colateralização, serviços de watchtower e escolha cuidadosa de quais computações proteger. É uma restrição real, mas um tipo de risco muito diferente de "esperar que o consenso do Bitcoin concorde com um opcode".

A Questão da Ativação: Por Que o Consenso Técnico Não é o Bastante​

A verdade desconfortável sobre o debate de covenants no Bitcoin é que as discordâncias técnicas — recursivas vs. não recursivas, opcode minimalista vs. primitiva geral — são amplamente resolvíveis. A questão mais difícil é como ativar qualquer uma delas.

A história dos soft forks do Bitcoin é curta e politicamente carregada. O SegWit exigiu uma ameaça de UASF (User-Activated Soft Fork) para quebrar um impasse de mineradores em 2017. O Taproot usou o Speedy Trial — uma janela BIP8 de três meses com um limite de sinalização de mineradores de 90% — e foi ativado sem problemas em novembro de 2021. Desde então, toda discussão sobre metodologia de ativação tem sido sombreada pelo que aconteceu anteriormente.

A proposta de parâmetros do CTV 2026 usa uma janela de sinalização no estilo Speedy Trial, que tem precedentes. Mas os oponentes dos covenants deixaram claro que não consideram o Speedy Trial apropriado para mudanças contenciosas — ele foi projetado especificamente para propostas que já haviam alcançado um consenso esmagador, e sua janela de três meses não dá ao ecossistema mais amplo tempo para apresentar objeções. Espere que a luta pela metodologia de ativação seja, se houver, mais intensa do que a luta técnica.

As condições políticas podem, na verdade, favorecer a ativação. A atividade on-chain do Bitcoin diminuiu significativamente desde seu pico de inscrições em 2024, a demanda por block space está fraca e os mineradores de Bitcoin — que precisam aprovar qualquer soft fork por meio de sinalização — estão procurando novas narrativas que impulsionem a demanda por espaço de bloco. Vaults, melhorias na Lightning e L2s protegidas pelo Bitcoin geram demanda por transações on-chain. O alinhamento de autointeresse econômico está mais claro do que em anos.

O que isso significa para os construtores de infraestrutura de Bitcoin​

Para as equipes que constroem no Bitcoin, o renascimento dos covenants cria uma escolha estratégica real. As equipes que precisam de funcionalidade semelhante a smart contracts agora têm três caminhos credíveis:

Caminho 1 — Esperar por CTV / CAT / LNHANCE. Menor complexidade, exige um soft fork para ativação, cronograma incerto. Ideal para equipes cujo caso de uso é fundamentalmente impossível sem mudanças no nível de consenso (ex: vaults não federados em escala).

Caminho 2 — Construir no BitVM2. Disponível hoje, maior complexidade de implementação, dependente de segurança econômica. Ideal para equipes que constroem Bitcoin L2s, bridges ou rollups que precisam lançar em 2026 sem esperar por consenso.

Caminho 3 — Abordagem híbrida. Lançar no BitVM2, projetar o protocolo para que a ativação de covenants forneça um caminho de atualização mais limpo. Esta é a postura que a GOAT Network e várias outras equipes de Bitcoin L2 estão adotando.

Para os provedores de infraestrutura, a implicação compartilhada é a mesma: o Bitcoin script está se tornando mais expressivo, não importa qual desses caminhos vença. Carteiras, provedores de RPC, indexadores e infraestrutura de nós precisam estar prontos para lidar com tipos de transação mais ricos — UTXOs portadores de covenants, transações de desafio do BitVM2, novas estruturas de canais Lightning — em produção.

A BlockEden.xyz fornece infraestrutura RPC de nível empresarial para o Bitcoin e redes adjacentes ao Bitcoin, incluindo L2s emergentes construídas no BitVM2 e primitivos habilitados para covenants. Explore nosso marketplace de APIs para construir em bases projetadas para o próximo capítulo do Bitcoin.

A forma da próxima década do Bitcoin​

O mais interessante sobre 2026 não é que uma dessas propostas será definitivamente ativada — qualquer uma delas ainda pode estagnar por mais um ou três anos. É que a cultura de desenvolvimento do Bitcoin superou decisivamente o debate binário "covenants sim vs. covenants não" que definiu 2022-2024.

A conversa agora gira em torno de qual combinação de primitivos de covenants, protocolos de verificação off-chain e arquiteturas de Camada 2 oferece a programabilidade mais útil com o mínimo de mudança no consenso. CTV para vaults e controle de congestionamento. CAT para expressividade e bridges. LNHANCE para Lightning. BitVM2 para qualquer coisa que possa tolerar o modelo de resolução de disputas. Estas não são visões concorrentes — são ferramentas complementares em um kit de ferramentas de scripting do Bitcoin expandido.

O Bitcoin passou quinze anos sendo deliberadamente entediante. Essa paciência estratégica construiu a camada de liquidação (settlement) mais segura da história. A questão para a próxima década é se essa mesma disciplina de segurança pode sobreviver ao ser estendida para cobrir uma camada programável genuinamente expressiva. Se os debates de ativação de 2026 terminarem com o envio de pelo menos uma dessas propostas, a resposta será sim — e o papel do Bitcoin no ecossistema cripto mais amplo mudará de "ouro digital que não faz nada" para "a camada de liquidação em que tudo o mais confia".

Fontes:

Share on Twitter