OP_CAT is een Bitcoin-opcode die twee gegevenselementen op de stack samenvoegt tot één geheel, en vormt momenteel het onderwerp van een van de langstlopende discussies binnen de Bitcoin-ontwikkeling. Het maakte deel uit van de oorspronkelijke code van Bitcoin, werd in 2010 door Satoshi Nakamoto verwijderd vanwege bezorgdheid over de veiligheid, en is de afgelopen jaren voorgesteld als een soft fork (BIP 347) die een nieuwe categorie van smart contract-achtig gedrag op Bitcoin mogelijk zou kunnen maken. Vanaf juli 2026 is het niet actief op het Bitcoin-mainnet, hoewel het al draait op een handvol aan Bitcoin gerelateerde netwerken, waar het stilletjes in het openbaar aan stresstests wordt onderworpen.
Wat OP_CAT de moeite waard maakt om te begrijpen, is niet alleen de code. Het zijn de verschillende spelers eromheen: Bitcoin Core-ontwikkelaars die debatteren of de wijziging veilig is, een door memes gedreven NFT-project dat tientallen miljoenen dollars heeft opgehaald om te lobbyen voor de terugkeer ervan, en een snelgroeiende sidechain die het al in de praktijk heeft gebracht. In deze gids wordt uitgelegd wat OP_CAT doet, waarom het werd uitgeschakeld, welke mogelijkheden het zou kunnen bieden en hoe de stand van zaken op dit moment precies is.
Gebruik de multichain Bitcoin.com Wallet-app, waar miljoenen mensen op vertrouwen om veilig en eenvoudig Bitcoin en cryptovaluta te versturen, te ontvangen, te kopen, te verkopen, te verhandelen, te gebruiken en te beheren.
Belangrijkste punten
- OP_CAT (afkorting van "operation concatenate") voegt twee gegevensitems op de stack van Bitcoin samen tot één item. Dat is de volledige functie.
- Deze functie was aanwezig in de allereerste code van Bitcoin, maar werd in 2010 door Satoshi Nakamoto uitgeschakeld vanwege het risico op een denial-of-service-aanval.
- Het voorstel om het weer in te voeren, BIP 347, is opgesteld door Ethan Heilman en Armin Sabouri en kreeg in april 2024 zijn BIP-nummer toegewezen.
- OP_CAT is op zichzelf geen convenant, maar in combinatie met andere opcodes kan het worden gebruikt om convenantachtige bestedingsbeperkingen in te stellen, waaronder vaults.
- Medio 2026 is OP_CAT nog niet geactiveerd op het hoofdnetwerk van Bitcoin. De huidige koplopers voor de volgende consensus-softfork van Bitcoin zijn OP_CTV (BIP 119) en OP_CHECKSIGFROMSTACK (BIP 348), en niet OP_CAT op zichzelf.
- OP_CAT is al in gebruik op Fractal Bitcoin, een op Bitcoin gebaseerde sidechain, waar het de CAT20-tokenstandaard ondersteunt, en het draait al jaren op het Liquid Network en Bitcoin Cash zonder dat er een bekende kwetsbaarheid is geconstateerd.
- Een Bitcoin-NFT-project met de naam Quantum Cats, opgezet door Taproot Wizards, heeft de ondersteuning voor OP_CAT omgezet in een memecampagne die meer dan 37 miljoen dollar heeft opgehaald voor ontwikkelingsdoeleinden in verband met OP_CAT.
Hoe OP_CAT werkt
De duidelijkste manier om OP_CAT te begrijpen, is door het scriptsysteem van Bitcoin voor te stellen als een kleine stapel bouwstenen. Bitcoin Script, de programmeertaal achter elke Bitcoin-transactie, is een op een stapel gebaseerde taal. Gegevens worden op de stapel geplaatst, opcodes werken in op wat er bovenop ligt, en het resultaat bepaalt of een transactie geldig is.
OP_CAT neemt de bovenste twee elementen van die stapel en voegt ze samen, wat betekent dat ze aan elkaar worden gekoppeld tot één gecombineerd element, dat vervolgens weer bovenop de stapel wordt geplaatst. Als de stapel de waarden „1“ en „2“ bevat, worden bij het uitvoeren van OP_CAT beide verwijderd en vervangen door „12“. Volgens de officiële specificatie in BIP 347, zou OP_CAT x1 || x2 op de stack plaatsen, waarbij het dubbele-pijpje staat voor aaneenschakeling.
Er is één belangrijke beperking. OP_CAT mislukt als er minder dan twee waarden op de stack staan, of als het samenvoegen ervan zou leiden tot een gecombineerde waarde die groter is dan 520 bytes – de maximale grootte van een scriptelement in Bitcoin. Die bytelimiet speelt een grote rol in de geschiedenis van deze opcode, waar we straks op terugkomen.
Op zich klinkt het samenvoegen van twee reeksen gegevens niet bepaald indrukwekkend. Maar de scripttaal van Bitcoin heeft nooit een universele manier gehad om waarden op de stack te combineren, en die leemte heeft beperkt wat ontwikkelaars rechtstreeks in Bitcoin-transacties kunnen inbouwen. Zoals Bitcoin Optech legt uit, Bitcoin Tapscript beschikt niet over een algemene methode om objecten op de stack te combineren, wat de uitdrukkingsmogelijkheden van Tapscript beperkt en onder andere verhindert dat Merkle-bomen en andere gehashtte gegevensstructuren rechtstreeks in Tapscript kunnen worden opgebouwd en geëvalueerd. OP_CAT is de voorgestelde oplossing voor die specifieke tekortkoming.
Waarom werd OP_CAT in 2010 uitgeschakeld?
OP_CAT maakte deel uit van de allereerste release van Bitcoin. Satoshi Nakamoto heeft deze functie in 2010 verwijderd, samen met verschillende andere opcodes, zoals OP_MUL, OP_DIV en OP_OR. De officiële reden hiervoor was het risico op een denial-of-service-aanval: een script dat herhaaldelijk gebruikmaakt van OP_CAT zou in theorie een exponentieel groeiende hoeveelheid gegevens kunnen genereren, die groot genoeg zou zijn om nodes die deze gegevens proberen te valideren te vertragen of te laten crashen.
Destijds gold er geen harde limiet voor de maximale grootte van een afzonderlijk item in de stack van Bitcoin. Dat betekende dat een kwaadaardig script waarden kon blijven samenvoegen totdat er een reeks gegevens ontstond die zwaar genoeg was om het netwerk te vertragen. Het verwijderen van OP_CAT, samen met de andere uitgeschakelde opcodes, was een voorzichtige maatregel waarbij de stabiliteit van het netwerk voorrang kreeg boven functionaliteit die het jonge netwerk nog niet nodig had.
Het landschap veranderde in november 2021, toen Bitcoin de Taproot-upgrade activeerde. Taproot introduceerde Tapscript, een nieuwe scriptcontext met eigen regels, waarvan er één elk afzonderlijk stack-item beperkt tot 520 bytes. Die bytelimiet sluit het oorspronkelijke aanvalspad direct af. Een script kan nog steeds OP_CAT aanroepen, maar het kan nooit een waarde genereren die groot genoeg is om het soort resource-uitputtingsprobleem te veroorzaken waar Satoshi zich in 2010 zorgen over maakte. Dit is het technische detail dat de deur weer heeft geopend om OP_CAT terug te brengen, maar dan beperkt tot Tapscript in plaats van tot het gehele Bitcoin Script.
Is OP_CAT een convenant?
Nee, niet op zichzelf, en dit is een van de punten over OP_CAT die het vaakst verkeerd worden begrepen. Een ‘covenant’ is, in Bitcoin-termen, een beperking op de manier waarop een onbestede transactie-output (UTXO) in de toekomst kan worden uitgegeven. Normaal Bitcoin-script kan alleen controleren of een besteding op dit moment is geautoriseerd, meestal door een handtekening te verifiëren. Een ‘covenant’ gaat verder: het controleert niet alleen of een besteding is geautoriseerd, maar ook of de resulterende transactie voldoet aan een specifieke reeks voorwaarden.
OP_CAT bevat geen ingebouwd mechanisme om transactiegegevens te controleren. Het biedt wel een manier om gegevensfragmenten op de stack te combineren, wat pas nuttig is voor covenants wanneer het wordt gecombineerd met andere opcodes die handtekeningen toetsen aan die gecombineerde gegevens. In BIP 347 zelf staat duidelijk vermeld dat OP_CAT, hoewel voorgesteld voor heractivering in Tapscript, geen ‘covenant’ is. Het is juister om het te omschrijven als een bouwsteen die, in combinatie met opcodes voor het controleren van handtekeningen, kan worden gebruikt om ‘covenant’-achtig gedrag na te bootsen.
Dit is van belang omdat juist de flexibiliteit van OP_CAT het zowel interessant als controversieel maakt. Hoewel OP_CAT op zichzelf misschien geen covenant is, kan het wel covenants nabootsen vanwege een eigenaardigheid in de werking van Schnorr-handtekeningen. In combinatie met een opcode genaamd CheckSigFromStack (CSFS), die een handtekening controleert aan de hand van willekeurige gegevens in plaats van alleen de transactie zelf, kan OP_CAT worden gebruikt om dezelfde soort bestedingsbeperkingen in te stellen als waarvoor speciale covenant-opcodes zijn ontworpen.
Waarvoor zou OP_CAT kunnen worden gebruikt?
Omdat OP_CAT een universele primitieve is en geen functie met een beperkt toepassingsgebied, hebben ontwikkelaars er een breed scala aan toepassingen voor voorgesteld. De meest besproken toepassingen zijn onder meer:
- Gewelven. Een ‘vault’ is een soort overeenkomst waarbij meerdere stappen nodig zijn – vaak verspreid over afzonderlijke transacties en blokken – voordat geld kan worden overgemaakt. Dit zorgt voor een ingebouwde vertraging die de eigenaar de tijd geeft om ongeoorloofde uitgaven op te merken en te stoppen, waardoor de beveiliging van cold storage en gedeelde bewaring wordt verbeterd.
- Contracten waarin geen dubbelzinnigheid is toegestaan. Deze kunnen een partij in een betalingskanaal, zoals het Lightning Network, bestraffen die probeert een verouderde of frauduleuze kanaalstatus te verspreiden, waardoor de beveiliging van off-chain betalingssystemen wordt versterkt.
- Boomhandtekeningen. OP_CAT maakt compacte multisignature-scripts mogelijk waarvan de omvang slechts logaritmisch toeneemt met het aantal ondertekenaars, wat betekent dat een transactie van minder dan 1 kilobyte in theorie bestedingsvoorwaarden voor miljoenen openbare sleutels zou kunnen ondersteunen.
- Opbouw en verificatie van een Merkle-boom. Aangezien het opbouwen en controleren van een Merkle-boom in wezen neerkomt op het aaneenschakelen en hashen van waarden, biedt OP_CAT Bitcoin Script het ontbrekende onderdeel dat nodig is om dit op eigen kracht te kunnen doen.
- Post-kwantumkenmerken. OP_CAT kan Lamport-handtekeningen mogelijk maken, een handtekeningschema dat als bestand tegen aanvallen van kwantumcomputers wordt beschouwd, aangezien Lamport-handtekeningen niets meer vereisen dan de mogelijkheid om waarden op de stack te hashen en aan elkaar te koppelen.
- Getokeniseerde activa en cross-chain-bruggen. Door meer veelzijdige scripts mogelijk te maken, zou OP_CAT de uitgifte van tokens rechtstreeks op met Bitcoin gealigneerde ketens kunnen ondersteunen, evenals bruggen tussen Bitcoin en andere netwerken waarbij het vertrouwen tot een minimum wordt beperkt.
Ook hier is het de moeite waard om duidelijk te zijn over de afwegingen. Dezelfde flexibiliteit die OP_CAT nuttig maakt voor al het bovenstaande, is ook de reden waarom sommige Bitcoin-ontwikkelaars er terughoudend tegenover staan. Omdat OP_CAT een algemene functie heeft in plaats van specifiek voor een bepaald doel is ontworpen, opent het wat ontwikkelaars soms een ‘grote ontwerpruimte’ noemen, wat betekent dat het moeilijker is om alle mogelijke manieren te voorspellen waarop het uiteindelijk met andere opcodes zou kunnen worden gecombineerd. Die onzekerheid vormt de kern van het lopende debat, en is geen bijzaak.
OP_CAT versus OP_CTV: een vergelijking van de twee belangrijkste voorstellen voor een convenant
OP_CAT wordt meestal in één adem genoemd met OP_CTV (OP_CheckTemplateVerify), dat in BIP 119 is voorgesteld door ontwikkelaar Jeremy Rubin. Beide zijn bedoeld om Bitcoin een vorm van ‘covenant’-functionaliteit te geven, maar ze hanteren vrijwel tegengestelde ontwerpbenaderingen.
Het praktische verschil komt neer op de reikwijdte. Met OP_CTV kan een transactie-output zich vastleggen op één specifieke toekomstige bestedingstransactie, waarbij details zoals de versie, locktime, outputs en het aantal inputs worden vastgelegd. Als het sjabloon overeenkomt, wordt de besteding goedgekeurd. Als het sjabloon niet overeenkomt, gaat de transactie niet door. Die beperkte reikwijdte is opzettelijk. CTV is niet-recursief, wat betekent dat een transactie waaraan het zich bindt, zich zelf niet kan binden aan verdere beperkingen op een manier die een permanente keten van beperkingen creëert. Voorstanders beschouwen dit als de veiligere, meer afgebakende vorm van een convenant.
OP_CAT hanteert een tegenovergestelde filosofie. In plaats van één specifiek probleem op te lossen, biedt het ontwikkelaars een flexibele basisbouwsteen waarmee ze verder kunnen bouwen. Waar CTV een zorgvuldig afgebakende opcode is die is ontworpen om een specifieke reeks gebruiksscenario’s mogelijk te maken, is OP_CAT een basiselement – het samenvoegen van strings op de stack – dat al in de oorspronkelijke Bitcoin-scripttaal aanwezig was voordat het in 2010 werd uitgeschakeld vanwege zorgen over denial-of-service-aanvallen, die onder de scriptgroottelimieten van na Taproot niet langer van toepassing zijn. Juist die flexibiliteit stelt OP_CAT in staat om recursieve convenanten te ondersteunen, waarbij de ene beperking later een andere beperking kan creëren – een eigenschap die OP_CTV bewust vermijdt.
Is OP_CAT vandaag live op Bitcoin?
Niet op het hoofdnetwerk van Bitcoin. BIP 347 heeft als specificatiedocument de status „Complete“ bereikt, wat betekent dat het voorstel zelf voltooid en duidelijk omschreven is. Dat staat los van de daadwerkelijke implementatie, waarvoor de bredere Bitcoin-gemeenschap en knooppuntbeheerders het voorstel daadwerkelijk via een soft fork zouden moeten activeren.
Vanaf medio 2026 is OP_CAT niet langer de belangrijkste kandidaat voor de volgende consensuswijziging van Bitcoin. Die positie wordt momenteel ingenomen door OP_CTV, samen met OP_CHECKSIGFROMSTACK (BIP 348), een verwante opcode waarmee een script een handtekening kan verifiëren aan de hand van willekeurige gegevens in plaats van alleen de uitgavetransactie zelf. Volgens een recente referentiegids voor Bitcoin BIP’s, vanaf medio 2026 zijn de belangrijkste kandidaten voor de volgende consensus-softfork de covenant-voorstellen BIP 119 (OP_CHECKTEMPLATEVERIFY) en BIP 348 (OP_CHECKSIGFROMSTACK). Deze zouden nieuwe scriptmogelijkheden bieden voor vaults, channel factories en efficiëntere layer-2-protocollen, hoewel er nog geen tijdschema voor de activering is vastgesteld en de consensus binnen de gemeenschap nog in ontwikkeling is.
OP_CTV is in het activeringsproces al verder gevorderd dan OP_CAT. Ontwikkelaars hebben gepubliceerd concrete signaleringsparameters voor een soft fork in BIP9-stijl: een startdatum voor de signaalperiode op 30 maart 2026, een time-outperiode van één jaar die afloopt op 30 maart 2027, een minimale activeringshoogte rond mei 2027 en een drempel van 90% aan signalen van miners gedurende elke moeilijkheidsperiode van twee weken. Hiermee volgt CTV hetzelfde mechanisme dat Taproot in 2021 activeerde, hoewel het bereiken van de drempel van 90% verre van gegarandeerd is, gezien de aanhoudende controverse over de covenant-voorstellen binnen de ontwikkelaarsgemeenschap.
Dit betekent geenszins dat OP_CAT ten dode is opgeschreven. Het betekent dat de discussie over de „volgende“ soft fork in 2026 momenteel draait om een ander paar opcodes, en dat de toekomst van OP_CAT, als die er al is, waarschijnlijk afhangt van hoe het debat over CTV en CSFS zich eerst zal ontwikkelen.
OP_CAT draait elders al
Hoewel OP_CAT nog op het mainnet van Bitcoin wacht, blijft het niet ongetest. Het draait al jaren stilletjes in productie op een handvol Bitcoin-gerelateerde netwerken.
- Liquid Network. De federatieve sidechain van Blockstream heeft OP_CAT al sinds de lancering ingeschakeld, waardoor het bredere Bitcoin-ecosysteem al jaren voordat BIP 347 zelfs maar bestond, over een testomgeving in de praktijk beschikte.
- Bitcoin Cash en Bitcoin SV. Beide netwerken hebben OP_CAT tijdens protocolupgrades opnieuw geïntroduceerd, en het heeft transacties op deze ketens verwerkt zonder dat er een gedocumenteerde kwetsbaarheid is vastgesteld die verband houdt met de opcode zelf.
- Fractal Bitcoin. Dit is de meest actieve implementatie op dit moment. Fractal is een op Bitcoin gebaseerde sidechain, gebouwd met de eigen software van Bitcoin Core en die via merge-mining met Bitcoin wordt gemined. Het mainnet werd op 9 september 2024 gelanceerd, waarbij OP_CAT vanaf dag één was ingeschakeld.
Fractal is het waard om nader te bekijken, omdat het het duidelijkste antwoord biedt op de vraag „hoe zou dit er in de praktijk op Bitcoin uitzien?”. Sinds de lancering van Fractal hebben nieuwe protocollen gebruikgemaakt van OP_CAT om slimme contracten te creëren op basis van Bitcoin-software, waaronder het CAT-protocol, dat veel belangstelling heeft gewekt onder gebruikers die van oudsher met Bitcoin werken, naast andere opkomende standaarden die de functionaliteit van het netwerk uitbreiden met behulp van OP_CAT.
Het belangrijkste voorbeeld is CAT20, een standaard voor fungibele tokens die speciaal is ontwikkeld om gebruik te maken van OP_CAT. Volgens De eigen documentatie van Fractal Bitcoin, CAT20 wordt volledig gevalideerd door miners en werkt op basis van slimme contracten, met name recursieve convenanten, die volledig worden afgedwongen door de eigen scripttaal van Bitcoin op de basislaag, waardoor het zich onderscheidt van tokenstandaarden die afhankelijk zijn van externe validatie of validatie door derden. In de praktijk betekent dit dat het implementeren, slaan en overdragen van een CAT20-token plaatsvindt via een reeks OP_CAT-bewerkingen die samen één gegevensreeks vormen, die vervolgens rechtstreeks in de blockchain wordt vastgelegd en gecontroleerd door dezelfde miners die het netwerk beveiligen, in plaats van door een afzonderlijke off-chain indexeringsdienst.
Het verhaal van de Quantum Cats: hoe een memecampagne OP_CAT een impuls gaf
De meeste voorstellen voor opcodes blijven beperkt tot mailinglijsten en GitHub-discussies. Dat gold niet voor OP_CAT, grotendeels dankzij een Bitcoin Ordinals-project met de naam Taproot Wizards.
In januari 2024 lanceerde Taproot Wizards een collectie van 3.333 NFT’s, genaamd Quantum Cats, die volledig was opgezet met als doel publieke steun te genereren voor de heractivering van OP_CAT. Quantum Cats wilde dat OP_CAT een ‘permissionless’ brug zou creëren waarmee bitcoin en op bitcoin gebaseerde activa naar Bitcoin layer 2-ketens konden worden verplaatst, waar ze zouden kunnen deelnemen aan complexere handelsactiviteiten. Om überhaupt in aanmerking te komen voor de uitgifte, moesten deelnemers zich verdiepen in het daadwerkelijke technische voorstel en zich publiekelijk inzetten voor de terugkeer ervan, waardoor een vrij droge BIP-discussie werd omgezet in een gemeenschapscampagne met echte belangen op het spel.
De collectie zelf diende tegelijkertijd als een demonstratie van concatenatie in de praktijk. Elke Quantum Cat verwijst naar meerdere afzonderlijke bestanden in plaats van naar één statische afbeelding, en naarmate er in de loop van de tijd nieuwe bestanden worden onthuld, veranderen de katten. Dit weerspiegelt precies wat OP_CAT doet door afzonderlijke stukjes data samen te voegen.
De campagne was zo succesvol dat dit resulteerde in aanzienlijke financiering. Taproot Wizards haalde in 2023 7,5 miljoen dollar op, gevolgd door een financieringsronde van 30 miljoen dollar in februari 2025; beide bedragen waren expliciet bestemd voor de ontwikkeling van het OP_CAT-ecosysteem. Medeoprichter Udi Wertheimer beschreef het project als gericht op OP_CAT als de toekomst van Bitcoin, waarbij de financiering zowel naar interne ontwikkeling gaat als naar het ondersteunen van externe teams die voortbouwen op de opcode. Een enkele Quantum Cat-veiling bij Sotheby's, de „Genesis Cat“, werd afgesloten op 254.000 dollar, wat onderstreept hoeveel cultureel gewicht de campagne had gekregen rond een opcode van vier bytes.
Het is een nuttige herinnering dat de technische discussies rond Bitcoin niet altijd puur technisch blijven. Memes, kunst en geld zijn herhaaldelijk ingezet als middelen om het debat over het protocol onder de aandacht van een breder publiek te brengen, en OP_CAT is een van de duidelijkste recente voorbeelden van dat patroon.
Conclusie
OP_CAT doet één simpel ding: het voegt twee stukjes data op de stack van Bitcoin samen tot één geheel. Wat het zo belangrijk maakt, is alles wat die ene functie zou kunnen mogelijk maken – van veiligere cold storage-opslagplaatsen tot post-kwantumhandtekeningen en Bitcoin-native tokens – als de Bitcoin-gemeenschap er ooit mee instemt om het weer in te voeren. In juli 2026 is die overeenstemming nog niet bereikt. BIP 347 is een voltooide specificatie die in de wachtrij voor de volgende consensus-softfork van Bitcoin achter OP_CTV en OP_CHECKSIGFROMSTACK staat, terwijl OP_CAT stilletjes en zonder incidenten blijft draaien op Fractal Bitcoin, Liquid en andere Bitcoin-gerelateerde netwerken. Wat er ook gebeurt, het debat rond OP_CAT heeft al aangetoond hoe een klein, eenvoudig stukje code in één klap ontwikkelaars, kunstenaars en investeerders kan aantrekken.
