OP_CAT er en Bitcoin-opkode, der sammenføjer to datastykker på stakken til ét, og den er i øjeblikket genstand for en af de længstvarende debatter inden for Bitcoin-udviklingen. Den var en del af Bitcoins oprindelige kode, men blev fjernet af Satoshi Nakamoto i 2010 af sikkerhedsmæssige årsager, og har de seneste par år været foreslået som en soft fork (BIP 347), der kunne åbne op for en ny kategori af smart contract-lignende adfærd på Bitcoin. Pr. juli 2026 er den ikke aktiv på Bitcoins mainnet, selvom den allerede kører på en håndfuld netværk tæt knyttet til Bitcoin, hvor den i al stilhed gennemgår offentlige stresstests.
Det, der gør OP_CAT værd at forstå, er ikke kun selve koden. Det er de forskellige aktører omkring den: Bitcoin Core-udviklere, der diskuterer, om ændringen er sikker, et meme-drevet NFT-projekt, der har indsamlet titusindvis af dollars for at lobbye for dens genindførelse, og en hurtigt voksende sidekæde, der allerede har taget den i brug. Denne guide forklarer, hvad OP_CAT gør, hvorfor den blev deaktiveret, hvilke muligheder den kan åbne op for, og præcis hvor vi står i dag.
Brug multichain Bitcoin.com Wallet-appen, som millioner af mennesker stoler på til sikkert og nemt at sende, modtage, købe, sælge, handle med, bruge og administrere Bitcoin og kryptovaluta.
De vigtigste pointer
- OP_CAT (forkortelse for »operation concatenate«) sammenkæder to dataelementer på Bitcoins stak til ét enkelt element. Det er hele funktionen.
- Den var aktiv i Bitcoins allerførste kode, men blev derefter deaktiveret af Satoshi Nakamoto i 2010 på grund af risikoen for et denial-of-service-angreb.
- Forslaget om at genindføre det, BIP 347, blev udarbejdet af Ethan Heilman og Armin Sabouri og tildelt sit BIP-nummer i april 2024.
- OP_CAT er ikke i sig selv en pagt, men i kombination med andre opkoder kan den bruges til at oprette pagtlignende udgiftsbegrænsninger, herunder vaults.
- Pr. medio 2026 er OP_CAT endnu ikke blevet aktiveret på Bitcoins hovednetværk. De nuværende favoritter til Bitcoins næste konsensus-softfork er OP_CTV (BIP 119) og OP_CHECKSIGFROMSTACK (BIP 348), ikke OP_CAT alene.
- OP_CAT er allerede i brug på Fractal Bitcoin, en Bitcoin-baseret sidekæde, hvor den understøtter CAT20-tokenstandarden, og den har kørt på Liquid Network og Bitcoin Cash i årevis uden kendte sikkerhedsbrud.
- Et Bitcoin-NFT-projekt ved navn Quantum Cats, skabt af Taproot Wizards, har omdannet støtten til OP_CAT til en meme-kampagne, der har indsamlet mere end 37 millioner dollars til OP_CAT-relateret udvikling.
Sådan fungerer OP_CAT
Den mest overskuelige måde at forstå OP_CAT på er at forestille sig Bitcoins scriptsystem som en lille stak byggeklodser. Bitcoin Script, det programmeringssprog, der ligger til grund for alle Bitcoin-transaktioner, er et stakbaseret sprog. Data skubbes ind på stakken, opkoder virker på det, der ligger øverst, og resultatet afgør, om en transaktion er gyldig.
OP_CAT tager de to øverste elementer på stakken og sammenkæder dem, hvilket vil sige, at de sættes sammen ende mod ende til et enkelt samlet element, som derefter placeres tilbage øverst på stakken. Hvis stakken indeholder værdierne »1« og »2«, fjerner udførelsen af OP_CAT begge og erstatter dem med »12«. Ifølge den officielle specifikation i BIP 347, vil OP_CAT lægge x1 || x2 på stakken, hvor symbolet med to lodrette streger angiver sammenkædning.
Der er én vigtig begrænsning. OP_CAT mislykkes, hvis der er færre end to værdier på stakken, eller hvis en sammenføjning af dem ville resultere i en samlet værdi på over 520 byte, hvilket er Bitcoins maksimale størrelse for scriptelementer. Denne byte-begrænsning har stor betydning for denne opcodes historie, som vi kommer ind på om lidt.
I sig selv lyder det ikke særlig avanceret at sammenføje to datastrenge. Men Bitcoins scriptsprog har aldrig haft en universel metode til at kombinere værdier på stakken, og denne mangel har begrænset, hvad udviklere kan indbygge direkte i Bitcoin-transaktioner. Som Bitcoin Optech forklarer, Bitcoin Tapscript mangler en generel metode til at kombinere objekter på stakken, hvilket begrænser Tapscripts udtryksmuligheder og blandt andet forhindrer, at man kan opbygge og evaluere Merkle-træer og andre hash-baserede datastrukturer direkte i Tapscript. OP_CAT er den foreslåede løsning på netop dette problem.
Hvorfor blev OP_CAT deaktiveret i 2010?
OP_CAT var en del af Bitcoins allerførste udgivelse. Satoshi Nakamoto fjernede den sammen med flere andre opkoder, såsom OP_MUL, OP_DIV og OP_OR, i 2010. Den officielle begrundelse drejede sig om risikoen for et denial-of-service-angreb: Et script, der gentagne gange anvendte OP_CAT, kunne i teorien generere en eksponentielt voksende datamængde, der var stor nok til at bremse eller nedlægge de noder, der forsøgte at validere den.
På det tidspunkt var der ingen fast grænse for, hvor stor en enkelt post i Bitcoins stak måtte være. Det betød, at et ondsindet script kunne blive ved med at sammenkæde værdier, indtil det frembragte en datastreng, der var tung nok til at overbelaste netværket. Fjernelsen af OP_CAT sammen med de andre deaktiverede opkoder var et forsigtigt skridt, der prioriterede netværksstabilitet frem for funktionalitet, som det unge netværk endnu ikke havde brug for.
Situationen ændrede sig i november 2021, da Bitcoin aktiverede Taproot-opgraderingen. Taproot introducerede Tapscript, en ny scriptkontekst med egne regler, hvoraf den ene begrænser hvert enkelt element i stakken til 520 byte. Denne bytebegrænsning lukker direkte den oprindelige angrebsvej. Et script kan stadig kalde OP_CAT, men det kan aldrig generere en værdi, der er stor nok til at skabe den slags ressourceudtømningsproblem, som bekymrede Satoshi i 2010. Det er denne tekniske detalje, der genåbnede døren for at bringe OP_CAT tilbage, blot begrænset til Tapscript i stedet for hele Bitcoin Script.
Er OP_CAT en pagt?
Nej, ikke i sig selv, og dette er et af de punkter, der oftest misforstås ved OP_CAT. En »covenant« er, i Bitcoin-sammenhæng, en begrænsning af, hvordan en ubrugte transaktionsudgang (UTXO) kan bruges i fremtiden. Normalt Bitcoin-script kan kun kontrollere, om en udbetaling er godkendt lige nu, typisk ved at verificere en signatur. En covenant går et skridt videre og kontrollerer ikke blot, om en udbetaling er godkendt, men også om den resulterende transaktion opfylder et specifikt sæt betingelser.
OP_CAT indeholder ingen indbygget mekanisme til at kontrollere transaktionsdata. Det giver derimod mulighed for at kombinere datastykker på stakken, hvilket kun bliver nyttigt for covenants, når det kombineres med andre opkoder, der kontrollerer signaturer i forhold til de kombinerede data. I selve BIP 347 står der klart og tydeligt at OP_CAT, selvom det er blevet foreslået genaktiveret i Tapscript, ikke er en covenant. Det er mere korrekt at beskrive det som en byggesten, der – i kombination med opkoder til signaturkontrol – kan bruges til at efterligne en covenant-lignende adfærd.
Dette er vigtigt, fordi OP_CAT’s fleksibilitet netop er det, der gør den både interessant og kontroversiel. Selvom OP_CAT måske ikke i sig selv er en covenant, kan den efterligne covenants på grund af en særhed i, hvordan Schnorr-signaturer fungerer. Kombineret med en opkode kaldet CheckSigFromStack (CSFS), som kontrollerer en signatur i forhold til vilkårlige data i stedet for blot selve transaktionen, kan OP_CAT bruges til at oprette den samme type udgiftsbegrænsninger, som dedikerede covenant-opkoder er designet til at skabe.
Hvad kan OP_CAT bruges til?
Da OP_CAT er en universel primitiv snarere end en funktion med et snævert anvendelsesområde, har udviklere foreslået en lang række anvendelsesmuligheder for den. Blandt de mest omtalte er:
- Hvælvinger. En »vault« er en type aftale, der kræver flere trin – ofte fordelt på forskellige transaktioner og blokke – før midlerne kan overføres. Dette medfører en indbygget forsinkelse, der giver ejeren tid til at opdage og standse uautoriserede udgifter, hvilket forbedrer sikkerheden ved cold storage og ordninger med delt forvaring.
- Kontrakter uden tvetydigheder. Disse kan påføre en part i en betalingskanal, såsom Lightning Network, en sanktion, hvis vedkommende forsøger at udsende en forældet eller falsk kanalstatus, hvilket styrker sikkerheden i off-chain-betalingssystemer.
- Træsignaturer. OP_CAT muliggør kompakte multisignatur-scripts, hvis størrelse kun vokser logaritmisk med antallet af underskrivere, hvilket betyder, at en transaktion på under 1 kilobyte teoretisk set kan understøtte udbetalingsbetingelser på tværs af millioner af offentlige nøgler.
- Opbygning og verifikation af et Merkle-træ. Da opbygning og kontrol af et Merkle-træ i grunden kræver sammenkædning og hashing af værdier, giver OP_CAT Bitcoin Script den manglende brik, der er nødvendig for at kunne udføre dette indbygget.
- Post-kvante-signaturer. OP_CAT kan aktivere Lamport-signaturer, et signatursystem, der anses for at være modstandsdygtigt over for angreb fra kvantecomputere, da Lamport-signaturer ikke kræver andet end evnen til at hashe og sammenkæde værdier på stakken.
- Tokeniserede aktiver og kædeoverskridende broer. Ved at muliggøre mere fleksible scripts vil OP_CAT kunne understøtte udstedelse af tokens direkte på Bitcoin-kompatible blockchains samt broer mellem Bitcoin og andre netværk, der i højere grad minimerer behovet for tillid.
Det er også værd at være ærlig om afvejningerne her. Den samme fleksibilitet, der gør OP_CAT nyttig til alle ovenstående formål, er netop det, der får nogle Bitcoin-udviklere til at være forsigtige med den. Da OP_CAT er en generel løsning snarere end en specialudviklet funktion, åbner den op for det, som udviklere undertiden kalder et stort designrum, hvilket betyder, at det er sværere at forudsige alle de måder, den i sidste ende kan blive kombineret med andre opkoder på. Den usikkerhed er kernen i den igangværende debat, ikke et sideanliggende.
OP_CAT vs. OP_CTV: En sammenligning af de to førende forslag til aftaler
OP_CAT diskuteres normalt sammen med OP_CTV (OP_CheckTemplateVerify), som blev foreslået i BIP 119 af udvikleren Jeremy Rubin. Begge har til formål at give Bitcoin en form for aftalefunktion, men de bygger på næsten modsatte designprincipper.
Den praktiske forskel ligger i omfanget. OP_CTV gør det muligt for en transaktionsudgang at forpligte sig til én bestemt fremtidig udgiftstransaktion, herunder detaljer som version, locktime, udgange og antal indgange. Hvis skabelonen stemmer overens, gennemføres udgiften. Stemmer den ikke overens, går den ikke igennem. Denne snævre anvendelse er bevidst. CTV er ikke-rekursiv, hvilket betyder, at en transaktion, den forpligter sig til, ikke selv kan forpligte sig til yderligere begrænsninger på en måde, der skaber en permanent kæde af begrænsninger. Tilhængere anser dette for at være den sikrere og mere afgrænsede form for covenant.
OP_CAT bygger på den modsatte filosofi. I stedet for at løse et specifikt problem giver den udviklerne en fleksibel grundfunktion, som de kan bygge videre på. Hvor CTV er en opkode med et nøje afgrænset anvendelsesområde, der er designet til at muliggøre en specifik række anvendelsesscenarier, er OP_CAT en primitiv – strengkonkatenering på stakken – som allerede fandtes i det oprindelige Bitcoin-scriptsprog, før den blev deaktiveret i 2010 på grund af bekymringer om denial-of-service-angreb, som ikke længere er relevante under de scriptstørrelsesbegrænsninger, der gælder efter Taproot. Det er netop denne fleksibilitet, der gør det muligt for OP_CAT at understøtte rekursive covenants, hvor én begrænsning kan skabe en anden begrænsning længere nede i kæden – en egenskab, som OP_CTV bevidst undgår.
Er OP_CAT i brug på Bitcoin i dag?
Ikke på Bitcoins hovednetværk. BIP 347 har nået statusen »Complete« som specifikationsdokument, hvilket betyder, at selve forslaget er færdigt og klart defineret. Det er noget andet end selve implementeringen, som vil kræve, at det bredere Bitcoin-fællesskab og nodeoperatørerne rent faktisk aktiverer det via en soft fork.
Pr. medio 2026 er OP_CAT ikke den førende kandidat til Bitcoins næste konsensusændring. Den position indtages i øjeblikket af OP_CTV sammen med OP_CHECKSIGFROMSTACK (BIP 348), en relateret opkode, der gør det muligt for et script at verificere en signatur i forhold til vilkårlige data i stedet for kun selve udbetalingstransaktionen. Ifølge en En opdateret referencevejledning til Bitcoin BIP, pr. medio 2026 er de førende kandidater til den næste konsensus-softfork covenant-forslagene BIP 119 (OP_CHECKTEMPLATEVERIFY) og BIP 348 (OP_CHECKSIGFROMSTACK), som vil muliggøre nye scriptfunktioner til vaults, channel factories og mere effektive layer-2-protokoller, selvom der endnu ikke er fastsat en tidsplan for aktivering, og konsensus i fællesskabet stadig er under udarbejdelse.
OP_CTV er kommet længere i aktiveringsprocessen end OP_CAT. Udviklerne har offentliggjort konkrete signalparametre for en soft fork i BIP9-stil: en startdato for signalering den 30. marts 2026, et tidsvindue på et år, der udløber den 30. marts 2027, en minimumsaktiveringshøjde omkring maj 2027 og en tærskel på 90 % for minernes signalering i hver to-ugers sværhedsperiode. Dette betyder, at CTV gennemgår den samme mekanisme, som aktiverede Taproot i 2021, selvom det langt fra er garanteret, at 90 %-tærsklen nås, i betragtning af hvor omstridte covenant-forslagene fortsat er i udviklerfællesskabet.
Intet af dette betyder, at OP_CAT er død. Det betyder, at den »næste« diskussion om en soft fork i 2026 i øjeblikket drejer sig om et andet sæt opkoder, og OP_CATs fremtid, hvis der overhovedet er en, afhænger sandsynligvis af, hvordan debatten om CTV og CSFS udvikler sig først.
OP_CAT kører allerede andre steder
Selvom OP_CAT stadig venter på at blive implementeret i Bitcoins mainnet, er det ikke fordi, det ikke er blevet afprøvet. Det har i årevis kørt i produktion på en håndfuld Bitcoin-relaterede netværk.
- Liquid Network. Blockstreams fødererede sidechain har haft OP_CAT aktiveret siden lanceringen, hvilket har givet det bredere Bitcoin-økosystem en testplatform i praksis flere år før BIP 347 overhovedet eksisterede.
- Bitcoin Cash og Bitcoin SV. Begge netværk genindførte OP_CAT i forbindelse med protokolopgraderinger, og den har behandlet transaktioner på disse kæder uden, at der er dokumenteret nogen sikkerhedsbrud knyttet til selve opkoden.
- Fraktal Bitcoin. Dette er den mest aktive implementering i øjeblikket. Fractal er en Bitcoin-kompatibel sidekæde, der er bygget ved hjælp af Bitcoin Cores egen software og udvindes i fællesskab med Bitcoin. Mainnettet blev lanceret den 9. september 2024 med OP_CAT aktiveret fra første dag.
Fractal fortjener et nærmere kig, fordi det er det klareste svar på spørgsmålet: »Hvordan ville det her egentlig se ud på Bitcoin?« Siden Fractals lancering har nye protokoller udnyttet OP_CAT til at oprette smarte kontrakter baseret på Bitcoin-softwaren, herunder CAT-protokollen, som har vakt betydelig interesse blandt Bitcoin-brugere, samt andre nye standarder, der udvider netværkets funktionalitet ved hjælp af OP_CAT.
Det mest fremtrædende eksempel er CAT20, en standard for fungible tokens, der er udviklet specifikt med henblik på at udnytte OP_CAT. Ifølge Fractal Bitcoins egen dokumentation, CAT20 er fuldt valideret af minere og fungerer ved hjælp af smarte kontrakter, nærmere bestemt rekursive covenants, som udelukkende håndhæves af Bitcoins eget scriptsprog på basislaget, hvilket adskiller det fra tokenstandarder, der er afhængige af ekstern eller tredjepartsvalidering. I praksis betyder det, at implementering, udstedelse og overførsel af et CAT20-token sker gennem en række OP_CAT-operationer, der opbygger en enkelt datastreng, som derefter indskrives direkte i blockchainen og kontrolleres af de samme minere, der sikrer netværket, i stedet for af en separat indekseringstjeneste uden for blockchainen.
Historien om Quantum Cats: Hvordan en meme-kampagne satte skub i OP_CAT
De fleste forslag til opkoder forbliver begrænset til mailinglister og GitHub-tråde. Det gjaldt ikke OP_CAT, hovedsageligt på grund af et Bitcoin Ordinals-projekt ved navn Taproot Wizards.
I januar 2024 lancerede Taproot Wizards en samling på 3.333 stykker i NFT-stil ved navn Quantum Cats, der udelukkende var bygget op omkring målet om at skabe offentlig opbakning til genaktiveringen af OP_CAT. Quantum Cats ønskede, at OP_CAT skulle skabe en tilladelsesfri bro, der kunne flytte bitcoin og bitcoin-baserede aktiver over på Bitcoin-lag 2-kæder, hvor de kunne indgå i mere kompleks handel. For overhovedet at kvalificere sig til udstedelsen måtte deltagerne sætte sig ind i det egentlige tekniske forslag og offentligt slå til lyd for dets genindførelse, hvilket forvandlede en ret tør BIP-diskussion til en fællesskabskampagne med reelle interesser på spil.
Selve samlingen fungerede samtidig som en demonstration af, hvordan sammenkædning fungerer i praksis. Hver Quantum Cat henviser til flere separate filer i stedet for ét statisk billede, og i takt med at nye filer afsløres over tid, ændrer kattene sig, hvilket nøjagtigt afspejler, hvad OP_CAT gør, nemlig at sammensætte separate datastykker.
Kampagnen var så vellykket, at den resulterede i betydelig finansiering. Taproot Wizards rejste 7,5 millioner dollar i 2023, efterfulgt af en finansieringsrunde på 30 millioner dollar i februar 2025, hvor begge beløb udtrykkeligt var øremærket til udvikling af OP_CAT-økosystemet. Medstifter Udi Wertheimer beskrev projektet som fokuseret på OP_CAT som Bitcoins fremtid, hvor finansieringen går til både intern udvikling og støtte til eksterne teams, der bygger videre på opkoden. Et enkelt Quantum Cat-salg hos Sotheby's, den såkaldte »Genesis Cat«, blev afsluttet til 254.000 dollar, hvilket understreger, hvor stor kulturel betydning kampagnen havde fået omkring en opkode på fire byte.
Det er en nyttig påmindelse om, at de tekniske debatter om Bitcoin ikke altid forbliver rent tekniske. Memes, kunst og penge har gentagne gange været med til at bringe diskussionerne om protokollen ud i offentligheden, og OP_CAT er et af de tydeligste eksempler på dette mønster fra den seneste tid.
Konklusion
OP_CAT gør én enkel ting: den sammenkæder to datastykker på Bitcoins stak til ét. Det, der gør den betydningsfuld, er alt det, som denne ene funktion kunne åbne op for – lige fra mere sikre cold storage-opbevaringsløsninger til post-kvante-signaturer og Bitcoin-native tokens – hvis Bitcoin-fællesskabet nogensinde bliver enige om at genindføre den. Pr. juli 2026 er denne enighed endnu ikke opnået. BIP 347 er en færdigudviklet specifikation, der står bag OP_CTV og OP_CHECKSIGFROMSTACK i køen til Bitcoins næste konsensus-softfork, selvom OP_CAT fortsat kører stille og roligt og uden problemer på Fractal Bitcoin, Liquid og andre Bitcoin-relaterede netværk. Uanset hvad der sker herefter, har debatten omkring OP_CAT allerede vist, hvordan et lille, simpelt stykke kode kan tiltrække udviklere, kunstnere og investorer på én gang.
