OP_CAT Il s'agit d'un opcode Bitcoin qui fusionne deux éléments de données présents sur la pile en un seul, et il fait actuellement l'objet de l'un des débats les plus anciens dans le domaine du développement de Bitcoin. Il faisait partie du code original de Bitcoin, mais a été supprimé par Satoshi Nakamoto en 2010 pour des raisons de sécurité. Ces dernières années, il a fait l'objet d'une proposition de soft fork (BIP 347) susceptible d'ouvrir la voie à une nouvelle catégorie de comportements de type « contrat intelligent » sur le réseau Bitcoin. En juillet 2026, elle n'est pas active sur le réseau principal de Bitcoin, bien qu'elle soit déjà opérationnelle sur quelques réseaux adjacents à Bitcoin où elle fait discrètement l'objet de tests de résistance en public.
Ce qui rend OP_CAT digne d’intérêt, ce n’est pas seulement le code. C’est tout l’univers qui l’entoure : les développeurs de Bitcoin Core qui débattent de la sécurité de cette modification, un projet NFT né d’un mème qui a levé des dizaines de millions de dollars pour militer en faveur de son retour, et une sidechain en pleine expansion qui l’a déjà mise en œuvre. Ce guide explique en détail le fonctionnement d’OP_CAT, les raisons de sa désactivation, les possibilités qu’il pourrait offrir et la situation exacte à l’heure actuelle.
Utilisez la fonctionnalité multichaîne Application Bitcoin.com Wallet, une plateforme à laquelle des millions de personnes font confiance pour envoyer, recevoir, acheter, vendre, échanger, utiliser et gérer des bitcoins et des cryptomonnaies en toute sécurité et en toute simplicité.
Points clés à retenir
- OP_CAT (abréviation de « operation concatenate ») combine deux éléments de données présents dans la pile de Bitcoin en un seul élément. C'est là toute sa fonction.
- Cette fonctionnalité était présente dans la version initiale du code de Bitcoin, puis a été désactivée par Satoshi Nakamoto en 2010 en raison d'un risque d'attaque par déni de service.
- La proposition visant à la réintroduire, la BIP 347, a été rédigée par Ethan Heilman et Armin Sabouri, et s'est vu attribuer son numéro BIP en avril 2024.
- OP_CAT n'est pas en soi un « covenant », mais, associé à d'autres opcodes, il peut servir à mettre en place des restrictions de dépenses similaires à celles d'un « covenant », notamment des « vaults ».
- À la mi-2026, OP_CAT n'avait pas encore été activé sur le réseau principal de Bitcoin. Les principaux candidats actuels pour le prochain soft fork de consensus de Bitcoin sont OP_CTV (BIP 119) et OP_CHECKSIGFROMSTACK (BIP 348), et non OP_CAT seul.
- OP_CAT est déjà opérationnel sur Fractal Bitcoin, une sidechain alignée sur Bitcoin, où il sous-tend la norme de jeton CAT20, et il fonctionne depuis des années sur le réseau Liquid et Bitcoin Cash sans qu'aucune faille n'ait été signalée.
- Un projet NFT basé sur le Bitcoin, baptisé « Quantum Cats » et créé par Taproot Wizards, a transformé le soutien à OP_CAT en une campagne « mème » qui a permis de récolter plus de 37 millions de dollars destinés au développement lié à OP_CAT.
Fonctionnement d'OP_CAT
La meilleure façon de comprendre OP_CAT est d'imaginer le système de script de Bitcoin comme une petite pile de blocs de construction. Bitcoin Script, le langage de programmation qui sous-tend chaque transaction Bitcoin, est un langage basé sur une pile. Les données sont poussées sur la pile, les opcodes agissent sur ce qui se trouve au sommet, et le résultat détermine si une transaction est valide.
OP_CAT prend les deux éléments du haut de cette pile et les concatène, c'est-à-dire qu'il les assemble bout à bout pour former un seul élément combiné, qui est ensuite replacé au sommet de la pile. Si la pile contient les valeurs « 1 » et « 2 », l'exécution de l'opération OP_CAT supprime ces deux éléments et les remplace par « 12 ». Selon la spécification officielle figurant dans BIP 347, OP_CAT placerait x1 || x2 sur la pile, le symbole « double-pipe » désignant la concaténation.
Il existe toutefois une restriction importante. L'opcode OP_CAT échoue s'il y a moins de deux valeurs sur la pile, ou si leur fusion donnait lieu à une valeur combinée supérieure à 520 octets, ce qui correspond à la taille maximale autorisée pour un élément de script dans Bitcoin. Cette limite en octets a joué un rôle déterminant dans l'histoire de cet opcode, sur laquelle nous reviendrons dans un instant.
En soi, la concaténation de deux chaînes de données ne semble pas particulièrement puissante. Mais le langage de script de Bitcoin n’a jamais disposé d’un moyen polyvalent de combiner des valeurs présentes sur la pile, et cette lacune a limité ce que les développeurs peuvent intégrer directement dans les transactions Bitcoin. Comme Bitcoin Optech explique, Tapscript Bitcoin ne dispose pas d’un moyen polyvalent de combiner des objets sur la pile, ce qui limite la puissance expressive de Tapscript et empêche, entre autres, de construire et d’évaluer des arbres de Merkle et d’autres structures de données hachées directement dans Tapscript. OP_CAT est la solution proposée pour combler cette lacune spécifique.
Pourquoi l'OP_CAT a-t-il été désactivé en 2010 ?
OP_CAT faisait partie de la toute première version de Bitcoin. Satoshi Nakamoto l'a supprimé, ainsi que plusieurs autres opcodes tels que OP_MUL, OP_DIV et OP_OR, en 2010. La justification officielle invoquait un risque de déni de service : un script utilisant OP_CAT de manière répétée pourrait, en théorie, générer un volume de données croissant de manière exponentielle, suffisamment important pour ralentir ou faire planter les nœuds chargés de le valider.
À l'époque, il n'existait aucune limite stricte quant à la taille maximale d'un élément individuel dans la pile de Bitcoin. Cela signifiait qu'un script malveillant pouvait continuer à concaténer des valeurs jusqu'à produire une chaîne de données suffisamment volumineuse pour paralyser le réseau. La suppression d’OP_CAT, ainsi que celle des autres opcodes désactivés, constituait une mesure prudente qui privilégiait la stabilité du réseau au détriment de fonctionnalités dont ce réseau naissant n’avait pas encore besoin.
La donne a changé en novembre 2021, lorsque Bitcoin a activé la mise à jour Taproot. Taproot a introduit Tapscript, un nouveau contexte de script doté de ses propres règles, dont l’une limite à 520 octets la taille de tout élément de la pile. Cette limite en octets bloque directement la voie d’attaque initiale. Un script peut toujours appeler OP_CAT, mais il ne peut en aucun cas produire une valeur suffisamment grande pour créer le type de problème d’épuisement des ressources qui inquiétait Satoshi en 2010. C’est ce détail technique qui a rouvert la voie au retour d’OP_CAT, mais dont la portée est désormais limitée à Tapscript plutôt qu’à l’ensemble de Bitcoin Script.
OP_CAT est-il un « Covenant » ?
Non, pas en soi, et c’est l’un des points les plus souvent mal compris concernant OP_CAT. Un « covenant », dans le jargon Bitcoin, est une restriction sur la manière dont une sortie de transaction non dépensée (UTXO) pourra être dépensée à l’avenir. Le script Bitcoin standard ne peut vérifier que si une dépense est autorisée à l'instant présent, généralement en validant une signature. Un « covenant » va plus loin : il vérifie non seulement si une dépense est autorisée, mais aussi si la transaction qui en résulte répond à un ensemble spécifique de conditions.
OP_CAT ne dispose d'aucun mécanisme intégré permettant d'inspecter les données de transaction. Il offre simplement un moyen de combiner des éléments de données présents dans la pile, ce qui ne s'avère utile pour les clauses restrictives que lorsqu'il est associé à d'autres opcodes permettant de vérifier les signatures par rapport à ces données combinées. Le BIP 347 lui-même le stipule clairement que l'OP_CAT, bien qu'il ait été proposé pour être réactivé dans Tapscript, n'est pas un « covenant ». Il est plus juste de le décrire comme un élément constitutif qui, associé à des opcodes de vérification de signature, peut être utilisé pour simuler un comportement similaire à celui d'un « covenant ».
Cela est important car c’est précisément la flexibilité d’OP_CAT qui le rend à la fois intéressant et controversé. Bien qu’OP_CAT ne soit pas en soi une clause restrictive, il peut en simuler les effets en raison d’une particularité du fonctionnement des signatures de Schnorr. Associé à un opcode appelé CheckSigFromStack (CSFS), qui vérifie une signature par rapport à des données arbitraires plutôt qu’à la seule transaction elle-même, OP_CAT peut être utilisé pour mettre en place le même type de restrictions de dépenses que celles pour lesquelles les opcodes dédiés aux covenants ont été conçus.
À quoi pourrait servir OP_CAT ?
OP_CAT étant une primitive polyvalente plutôt qu’une fonctionnalité à portée restreinte, les développeurs ont proposé un large éventail d’applications pour celle-ci. Parmi les plus souvent évoquées, on peut citer :
- Chambres fortes. Un « vault » est un type de contrat qui nécessite plusieurs étapes, souvent réparties sur plusieurs transactions et blocs distincts, avant que les fonds puissent être transférés. Cela introduit un délai intégré qui laisse au propriétaire le temps de détecter et d’empêcher toute dépense non autorisée, ce qui améliore les configurations de stockage à froid et de garde partagée.
- Contrats sans ambiguïté. Ces mécanismes peuvent pénaliser un acteur d'un canal de paiement, tel que le Lightning Network, qui tenterait de diffuser un état de canal obsolète ou frauduleux, renforçant ainsi la sécurité des systèmes de paiement hors chaîne.
- Signatures d'arbres. OP_CAT permet de créer des scripts de signatures multiples compacts dont la taille n'augmente que de manière logarithmique avec le nombre de signataires, ce qui signifie qu'une transaction de moins d'un kilo-octet pourrait théoriquement prendre en charge des conditions d'utilisation couvrant des millions de clés publiques.
- Construction et vérification d'un arbre de Merkle. Étant donné que la construction et la vérification d’un arbre de Merkle nécessitent fondamentalement de concaténer et de hacher des valeurs, OP_CAT apporte à Bitcoin Script l’élément manquant pour effectuer ces opérations de manière native.
- Signatures post-quantiques. OP_CAT permet d'activer les signatures de Lamport, un schéma de signature considéré comme résistant aux attaques des ordinateurs quantiques, car les signatures de Lamport ne nécessitent rien de plus que la capacité à calculer un hachage et à concaténer des valeurs sur la pile.
- Actifs tokenisés et ponts inter-chaînes. En permettant l'utilisation de scripts plus expressifs, OP_CAT pourrait prendre en charge l'émission de jetons directement sur des chaînes compatibles avec Bitcoin, ainsi que la mise en place de passerelles entre Bitcoin et d'autres réseaux nécessitant un niveau de confiance réduit.
Il convient ici aussi d’être franc quant aux compromis à faire. C’est précisément cette flexibilité qui rend OP_CAT utile pour toutes les applications susmentionnées qui incite certains développeurs Bitcoin à faire preuve de prudence à son égard. Comme OP_CAT est une fonctionnalité polyvalente plutôt que spécialisée, elle ouvre ce que les développeurs appellent parfois un « vaste espace de conception », ce qui signifie qu’il est plus difficile de prévoir toutes les combinaisons possibles avec d’autres opcodes. Cette incertitude est au cœur du débat actuel, et non une question secondaire.
OP_CAT vs OP_CTV : comparaison entre les deux principales propositions de « covenant »
L'OP_CAT est généralement évoqué en parallèle de l'OP_CTV (OP_CheckTemplateVerify), proposé dans le BIP 119 par le développeur Jeremy Rubin. Ces deux propositions visent à doter Bitcoin d'une certaine capacité en matière de clauses contractuelles, mais elles adoptent des approches de conception presque opposées.
La différence concrète réside dans le champ d’application. OP_CTV permet à une sortie de transaction de s’engager envers une seule et unique transaction de dépense future, en précisant des détails tels que la version, le délai de verrouillage, les sorties et le nombre d’entrées. Si le modèle correspond, la dépense est validée. En cas de non-correspondance, elle est rejetée. Cette limitation est intentionnelle. Le CTV est non récursif, ce qui signifie qu’une transaction à laquelle il s’engage ne peut pas, à son tour, s’engager à respecter d’autres restrictions de manière à créer une chaîne permanente de contraintes. Ses partisans considèrent qu’il s’agit d’une forme de covenant plus sûre et mieux maîtrisée.
OP_CAT adopte une philosophie opposée. Plutôt que de résoudre un problème spécifique, il offre aux développeurs une primitive flexible et leur permet de construire par-dessus. Alors que CTV est un opcode au champ d’application soigneusement délimité, conçu pour permettre un ensemble spécifique de cas d’utilisation, OP_CAT est une primitive – la concaténation de chaînes sur la pile – qui figurait déjà dans le langage de script original de Bitcoin avant d’être désactivée en 2010 en raison de craintes de déni de service, craintes qui ne se justifient plus compte tenu des limites de taille des scripts post-Taproot. C’est cette même flexibilité qui permet à OP_CAT de prendre en charge les clauses récursives, où une restriction peut en engendrer une autre en aval, une propriété qu’OP_CTV évite délibérément.
OP_CAT est-il opérationnel sur Bitcoin aujourd'hui ?
Pas sur le réseau principal de Bitcoin. Le BIP 347 a atteint le statut « Complete » en tant que document de spécification, ce qui signifie que la proposition elle-même est finalisée et clairement définie. Cela n’a toutefois rien à voir avec son déploiement, qui nécessiterait que la communauté Bitcoin dans son ensemble et les opérateurs de nœuds l’activent effectivement par le biais d’un soft fork.
À la mi-2026, OP_CAT n'est pas le principal candidat pour le prochain changement de consensus de Bitcoin. Cette place revient actuellement à OP_CTV, aux côtés d’OP_CHECKSIGFROMSTACK (BIP 348), un opcode associé qui permet à un script de vérifier une signature par rapport à des données arbitraires plutôt qu’à la seule transaction de dépense elle-même. Selon un Guide de référence récent sur les BIP du Bitcoin, à la mi-2026, les principales propositions en lice pour le prochain soft fork consensuel sont les propositions de covenant BIP 119 (OP_CHECKTEMPLATEVERIFY) et BIP 348 (OP_CHECKSIGFROMSTACK), qui permettraient de nouvelles fonctionnalités de script pour les coffres-forts, les « channel factories » et des protocoles de couche 2 plus efficaces, bien qu’aucun calendrier d’activation n’ait été fixé et que le consensus de la communauté soit encore en cours de formation.
OP_CTV est plus avancé dans le processus d'activation qu'OP_CAT. Les développeurs ont publié paramètres de signalisation concrets pour un soft fork de type BIP9 : une date de début de signalisation fixée au 30 mars 2026, une période d'attente d'un an expirant le 30 mars 2027, une hauteur d'activation minimale prévue vers mai 2027, et un seuil de signalisation des mineurs de 90 % au cours de chaque période de difficulté de deux semaines. Le CTV s'inscrit ainsi dans le même type de mécanisme que celui qui a activé Taproot en 2021, même si l'atteinte du seuil de 90 % est loin d'être garantie compte tenu de la controverse que suscitent encore les propositions de covenant au sein de la communauté des développeurs.
Cela ne signifie pas pour autant que l'OP_CAT soit mort. Cela signifie simplement que le « prochain » débat sur le soft fork prévu en 2026 porte actuellement sur une autre paire d'opcodes, et que l'avenir de l'OP_CAT, s'il y en a un, dépendra probablement de l'issue de ce débat sur le CTV et le CSFS.
OP_CAT est déjà en service ailleurs
Même si OP_CAT n'est pas encore disponible sur le réseau principal de Bitcoin, cela ne signifie pas pour autant qu'il n'a pas été testé. En effet, il fonctionne discrètement en production depuis des années sur quelques réseaux liés à Bitcoin.
- Liquid Network. La sidechain fédérée de Blockstream intègre la fonctionnalité OP_CAT depuis son lancement, offrant ainsi à l'écosystème Bitcoin dans son ensemble un banc d'essai en conditions réelles plusieurs années avant même que le BIP 347 n'existe.
- Bitcoin Cash et Bitcoin SV. Les deux réseaux ont réintroduit l'OP_CAT lors de mises à jour de leur protocole, et celui-ci a permis de traiter des transactions sur ces chaînes sans qu'aucune faille de sécurité liée à cet opcode n'ait été signalée.
- Bitcoin fractal. Il s'agit du déploiement le plus actif à l'heure actuelle. Fractal est une sidechain compatible avec Bitcoin, développée à l'aide du logiciel Bitcoin Core et exploitée en merge mining avec Bitcoin. Son réseau principal a été lancé le 9 septembre 2024, avec la fonctionnalité OP_CAT activée dès le premier jour.
Fractal mérite qu'on s'y attarde, car c'est la réponse la plus claire à la question « À quoi cela ressemblerait-il concrètement sur Bitcoin ? ». Depuis le lancement de Fractal, de nouveaux protocoles ont exploité OP_CAT pour créer des contrats intelligents basés sur le logiciel Bitcoin, notamment le protocole CAT, qui a suscité un vif intérêt parmi les utilisateurs natifs de Bitcoin, ainsi que d’autres normes émergentes qui étendent les fonctionnalités du réseau à l’aide d’OP_CAT.
L'exemple phare est CAT20, une norme de jetons fongibles spécialement conçue pour tirer parti de l'OP_CAT. Selon La documentation officielle de Fractal Bitcoin, CAT20 est entièrement validé par les mineurs et fonctionne à l’aide de contrats intelligents, plus précisément de clauses récursives, dont l’application est entièrement assurée par le langage de script propre à Bitcoin au niveau de la couche de base, ce qui le distingue des normes de jetons qui reposent sur une validation externe ou par des tiers. Concrètement, cela signifie que le déploiement, la frappe et le transfert d’un jeton CAT20 s’effectuent via une séquence d’opérations OP_CAT qui constituent une chaîne de données unique, laquelle est ensuite inscrite directement sur la blockchain et vérifiée par les mêmes mineurs qui sécurisent le réseau, plutôt que par un service d’indexation hors chaîne distinct.
L'histoire de Quantum Cats : comment une campagne de mèmes a fait avancer le projet OP_CAT
La plupart des propositions d'opcodes restent confinées aux listes de diffusion et aux fils de discussion sur GitHub. Ce n'est pas le cas d'OP_CAT, en grande partie grâce à un projet Bitcoin Ordinals appelé Taproot Wizards.
En janvier 2024, Taproot Wizards a lancé une collection de 3 333 pièces de type NFT intitulée « Quantum Cats », entièrement conçue dans le but de susciter le soutien du public en faveur de la réactivation d’OP_CAT. Quantum Cats souhaitait qu’OP_CAT crée un pont sans autorisation permettant de transférer des bitcoins et des actifs basés sur le bitcoin vers des chaînes de couche 2 de Bitcoin, où ils pourraient faire l’objet de transactions plus complexes. Pour pouvoir prétendre à la frappe de ces NFT, les participants devaient se familiariser avec la proposition technique proprement dite et plaider publiquement en faveur de son retour, transformant ainsi une discussion BIP plutôt aride en une campagne communautaire aux enjeux concrets.
La collection elle-même servait également de démonstration concrète de la concaténation. Chaque « Quantum Cat » fait référence à plusieurs fichiers distincts plutôt qu’à une seule image statique, et à mesure que de nouveaux fichiers sont dévoilés au fil du temps, les chats changent, reflétant exactement le fonctionnement de l’OP_CAT, qui consiste à assembler des éléments de données séparés.
La campagne a porté ses fruits, ce qui s’est traduit par un financement important. Taproot Wizards a levé 7,5 millions de dollars en 2023, puis 30 millions de dollars lors d’un tour de table en février 2025, ces deux montants étant explicitement destinés au développement de l’écosystème OP_CAT. Le cofondateur Udi Wertheimer a décrit le projet comme étant axé sur OP_CAT, qu’il considère comme l’avenir du Bitcoin, les fonds étant destinés à la fois au développement en interne et au soutien d’équipes externes travaillant sur cet opcode. Une seule vente de « Quantum Cat » chez Sotheby’s, le « Genesis Cat », s’est conclue à 254 000 dollars, soulignant à quel point la campagne avait acquis un poids culturel autour d’un opcode de quatre octets.
Cela nous rappelle utilement que les débats techniques autour du Bitcoin ne restent pas toujours purement techniques. Les mèmes, l'art et l'argent ont maintes fois servi à élargir la portée des discussions sur le protocole, et OP_CAT est l'un des exemples récents les plus évidents de cette tendance.
Conclusion
OP_CAT remplit une fonction simple : il fusionne deux éléments de données présents dans la pile de Bitcoin en un seul. Ce qui rend cette fonction importante, c'est tout ce qu'elle pourrait permettre de réaliser — des coffres de stockage à froid plus sécurisés aux signatures post-quantiques, en passant par les jetons natifs de Bitcoin — si jamais la communauté Bitcoin décidait de la réintroduire. En juillet 2026, cet accord n'avait toujours pas été conclu. La spécification BIP 347, déjà finalisée, se trouve derrière OP_CTV et OP_CHECKSIGFROMSTACK dans la file d’attente du prochain soft fork de consensus de Bitcoin, alors même qu’OP_CAT continue de fonctionner discrètement et sans incident sur Fractal Bitcoin, Liquid et d’autres réseaux liés à Bitcoin. Quelle que soit la suite des événements, le débat autour d’OP_CAT a déjà montré comment un petit bout de code simple peut attirer à la fois des développeurs, des artistes et des investisseurs.
