OP_CAT er en Bitcoin-opkode som slår sammen to datadelene på stakken til én, og den er for tiden gjenstand for en av de lengstvarende debattene innen Bitcoin-utviklingen. Den var en del av Bitcoins opprinnelige kode, men ble fjernet av Satoshi Nakamoto i 2010 av sikkerhetshensyn, og har de siste årene vært foreslått som en soft fork (BIP 347) som kan åpne for en ny kategori av smartkontraktlignende funksjonalitet på Bitcoin. Per juli 2026 er den ikke aktiv på Bitcoins hovednettverk, selv om den allerede kjører på en håndfull nettverk knyttet til Bitcoin, der den i det stille blir stresstestet offentlig.
Det som gjør OP_CAT verdt å forstå, er ikke bare koden. Det er aktørene rundt den: Bitcoin Core-utviklere som diskuterer om endringen er trygg, et meme-drevet NFT-prosjekt som samlet inn titalls millioner dollar for å arbeide for at den skal gjeninnføres, og en raskt voksende sidekjede som allerede har tatt den i bruk. Denne guiden forklarer hva OP_CAT gjør, hvorfor den ble deaktivert, hva den kan muliggjøre, og nøyaktig hvor vi står i dag.
Bruk multichain Bitcoin.com Wallet-appen, som millioner av mennesker stoler på når det gjelder å sende, motta, kjøpe, selge, bytte, bruke og forvalte Bitcoin og kryptovaluta på en trygg og enkel måte.
Hovedpunkter
- OP_CAT (forkortelse for «operation concatenate») slår sammen to dataelementer på Bitcoins stabel til ett enkelt element. Det er hele funksjonen.
- Den var aktiv i Bitcoins aller første kildekode, men ble deretter deaktivert av Satoshi Nakamoto i 2010 på grunn av risikoen for tjenestenektangrep.
- Forslaget om å gjeninnføre det, BIP 347, ble utarbeidet av Ethan Heilman og Armin Sabouri, og fikk tildelt sitt BIP-nummer i april 2024.
- OP_CAT er ikke i seg selv en avtale, men i kombinasjon med andre opkoder kan den brukes til å opprette avtalelignende bruksbegrensninger, blant annet «vaults».
- Per midten av 2026 er OP_CAT ikke aktivert på Bitcoins hovednettverk. De nåværende favorittene for Bitcoins neste konsensus-softfork er OP_CTV (BIP 119) og OP_CHECKSIGFROMSTACK (BIP 348), ikke OP_CAT alene.
- OP_CAT er allerede i bruk på Fractal Bitcoin, en Bitcoin-tilknyttet sidekjede, der den ligger til grunn for CAT20-tokenstandarden, og den har vært i drift på Liquid Network og Bitcoin Cash i flere år uten at det er kjent at den har blitt utnyttet.
- Et Bitcoin-NFT-prosjekt ved navn Quantum Cats, utviklet av Taproot Wizards, har gjort støtten til OP_CAT til en meme-kampanje som har samlet inn mer enn 37 millioner dollar til OP_CAT-relatert utvikling.
Slik fungerer OP_CAT
Den enkleste måten å forstå OP_CAT på er å forestille seg Bitcoins skriptsystem som en liten stabel med byggeklosser. Bitcoin Script, programmeringsspråket som ligger til grunn for alle Bitcoin-transaksjoner, er et stabelbasert språk. Data legges inn i stabelen, operasjonskoder virker på det som ligger øverst, og resultatet avgjør om en transaksjon er gyldig.
OP_CAT tar de to øverste elementene i stakken og sammenføyer dem, det vil si at den setter dem sammen ende mot ende til ett samlet element, som deretter plasseres tilbake øverst i stakken. Hvis stakken inneholder verdiene «1» og «2», vil kjøring av OP_CAT fjerne begge og erstatte dem med «12». I henhold til den offisielle spesifikasjonen i BIP 347, vil OP_CAT legge x1 || x2 inn på stakken, der symbolet med to vertikale streker betegner sammenkobling.
Det er én viktig begrensning. OP_CAT mislykkes hvis det er færre enn to verdier på stakken, eller hvis en sammenslåing av dem ville gi en samlet verdi på over 520 byte – som er Bitcoins maksimale størrelse på et skriptelement. Denne bytegrensen har stor betydning for historien til denne opkoden, noe vi skal komme til om litt.
I seg selv høres det ikke særlig kraftfullt ut å sette sammen to datastrenger. Men Bitcoins skriptspråk har aldri hatt en allsidig måte å kombinere verdier på stakken på, og dette manglet har begrenset hva utviklere kan bygge direkte inn i Bitcoin-transaksjoner. Som Bitcoin Optech forklarer, Bitcoin Tapscript mangler en allsidig måte å kombinere objekter på stakken på, noe som begrenser Tapscripts uttrykksmuligheter og blant annet hindrer muligheten til å konstruere og evaluere Merkle-trær og andre hashede datastrukturer direkte i Tapscript. OP_CAT er den foreslåtte løsningen på akkurat dette problemet.
Hvorfor ble OP_CAT deaktivert i 2010?
OP_CAT var en del av Bitcoins aller første utgivelse. Satoshi Nakamoto fjernet den, sammen med flere andre opkoder som OP_MUL, OP_DIV og OP_OR, i 2010. Den offisielle begrunnelsen dreide seg om risikoen for tjenestenektangrep: et skript som brukte OP_CAT gjentatte ganger, kunne i teorien generere en eksponentielt voksende datamengde, stor nok til å bremse ned eller krasje noder som prøvde å validere den.
På den tiden fantes det ingen fast grense for hvor stor en enkelt post i Bitcoins stakk kunne være. Det innebar at et ondsinnet skript kunne fortsette å sammenkoble verdier til det produserte en datastreng som var tung nok til å overbelaste nettverket. Å fjerne OP_CAT, sammen med de andre deaktiverte opkodene, var et forsiktig grep som prioriterte nettverksstabilitet fremfor funksjonalitet som det unge nettverket ennå ikke hadde behov for.
Situasjonen endret seg i november 2021, da Bitcoin aktiverte Taproot-oppgraderingen. Taproot introduserte Tapscript, en ny skriptkontekst med egne regler, hvorav én setter en øvre grense på 520 byte for hvert enkelt element i stakken. Denne bytegrensen stenger direkte den opprinnelige angrepsveien. Et skript kan fortsatt kalle OP_CAT, men det kan aldri produsere en verdi som er stor nok til å skape den typen ressursutmattingsproblem som bekymret Satoshi i 2010. Dette er den tekniske detaljen som åpnet døren på nytt for å bringe OP_CAT tilbake, bare begrenset til Tapscript i stedet for hele Bitcoin Script.
Er OP_CAT en pakt?
Nei, ikke i seg selv, og dette er et av de mest misforståtte punktene når det gjelder OP_CAT. En «covenant», i Bitcoin-sammenheng, er en begrensning på hvordan en ubenyttet transaksjonsutgang (UTXO) kan brukes i fremtiden. Vanlig Bitcoin-skript kan bare sjekke om en utbetaling er autorisert akkurat nå, vanligvis ved å verifisere en signatur. En «covenant» går lenger og sjekker ikke bare om en utbetaling er autorisert, men også om den resulterende transaksjonen oppfyller et bestemt sett med betingelser.
OP_CAT har ingen innebygd mekanisme for å kontrollere transaksjonsdata. Det gir derimot en måte å kombinere datadeler på stakken, noe som kun blir nyttig for covenants når det brukes sammen med andre opkoder som sjekker signaturer opp mot disse kombinerte dataene. I selve BIP 347 står det klart og tydelig at OP_CAT, selv om det er foreslått gjenaktivert i Tapscript, ikke er en «covenant». Det er mer korrekt å beskrive det som en byggestein som, i kombinasjon med opkoder for signaturkontroll, kan brukes til å etterligne «covenant»-lignende atferd.
Dette er viktig fordi nettopp fleksibiliteten til OP_CAT er det som gjør den både interessant og kontroversiell. Selv om OP_CAT kanskje ikke er en «covenant» i seg selv, kan den etterligne slike avtaler på grunn av en særegenhet i måten Schnorr-signaturer fungerer på. Kombinert med en opkode kalt CheckSigFromStack (CSFS), som sjekker en signatur mot vilkårlige data i stedet for bare selve transaksjonen, kan OP_CAT brukes til å opprette den samme typen utgiftsbegrensninger som dedikerte avtaleopkoder er utformet for å skape.
Hva kan OP_CAT brukes til?
Siden OP_CAT er en allsidig primitiv snarere enn en funksjon med begrenset anvendelsesområde, har utviklere foreslått en lang rekke bruksområder for den. Blant de mest omtalte er:
- Hvelv. Et «vault» er en type avtale som krever flere trinn, ofte fordelt på separate transaksjoner og blokker, før midlene kan overføres. Dette medfører en innebygd forsinkelse som gir eieren tid til å oppdage og stoppe uautoriserte utgifter, noe som forbedrer løsninger for «cold storage» og delt forvaring.
- Kontrakter uten tvetydighet. Disse kan påføre en part i en betalingskanal, for eksempel Lightning Network, en straff dersom vedkommende forsøker å sende ut en utdatert eller falsk kanalstatus, noe som styrker sikkerheten i betalingssystemer utenfor blokkjeden.
- Tre signaturer. OP_CAT muliggjør kompakte multisignatur-skript der størrelsen bare øker logaritmisk med antall signatører, noe som betyr at en transaksjon på under 1 kilobyte teoretisk sett kan støtte utbetalingsbetingelser som omfatter millioner av offentlige nøkler.
- Oppbygging og verifisering av Merkle-trær. Siden oppbygging og verifisering av et Merkle-tre i bunn og grunn krever sammenkobling og hashing av verdier, gir OP_CAT Bitcoin Script den manglende brikken som trengs for å gjøre dette direkte i selve skriptet.
- Post-kvante-signaturer. OP_CAT kan aktivere Lamport-signaturer, et signatursystem som anses å være motstandsdyktig mot angrep fra kvantecomputere, ettersom Lamport-signaturer ikke krever annet enn evnen til å hashe og sammenkoble verdier på stakken.
- Tokeniserte eiendeler og broer mellom kjeder. Ved å muliggjøre mer fleksible skript kan OP_CAT støtte utstedelse av tokens direkte på Bitcoin-kompatible kjeder og broer mellom Bitcoin og andre nettverk som krever mindre tillit.
Det er verdt å være tydelig på avveiningene også her. Den samme fleksibiliteten som gjør OP_CAT nyttig for alle de ovennevnte formålene, er også grunnen til at noen Bitcoin-utviklere er forsiktige med den. Fordi OP_CAT er allsidig snarere enn spesialutviklet, åpner den for det utviklere noen ganger kaller et stort designrom, noe som betyr at det er vanskeligere å forutsi alle måter den til slutt kan kombineres med andre opkoder på. Denne usikkerheten er kjernen i den pågående debatten, ikke et sideproblem.
OP_CAT vs. OP_CTV: En sammenligning av de to ledende forslagene til avtaler
OP_CAT blir vanligvis omtalt sammen med OP_CTV (OP_CheckTemplateVerify), som ble foreslått i BIP 119 av utvikleren Jeremy Rubin. Begge har som mål å gi Bitcoin en form for avtalefunksjonalitet, men de har nesten motsatte designstrategier.
Den praktiske forskjellen handler om omfanget. OP_CTV lar en transaksjonsutgang forplikte seg til én bestemt fremtidig utgiftstransaksjon, og omfatter detaljer som versjon, locktime, utganger og antall innganger. Hvis malen stemmer overens, går utgiften gjennom. Stemmer den ikke, blir den ikke godkjent. Denne begrensningen er bevisst. CTV er ikke-rekursiv, noe som betyr at en transaksjon den forplikter seg til, ikke selv kan forplikte seg til ytterligere restriksjoner på en måte som skaper en permanent kjede av begrensninger. Tilhengere anser dette som den sikrere og mer avgrensede formen for covenant.
OP_CAT bygger på en motsatt filosofi. I stedet for å løse ett bestemt problem, gir den utviklere en fleksibel grunnleggende funksjon som de kan bygge videre på. Mens CTV er en operasjonskode med nøye avgrenset anvendelsesområde, designet for å muliggjøre et bestemt sett av bruksscenarier, er OP_CAT en primitiv – strengkonkatenering på stakken – som allerede fantes i det opprinnelige Bitcoin-skriptspråket før den ble deaktivert i 2010 på grunn av bekymringer for tjenestenektangrep, noe som ikke lenger er aktuelt under skriptstørrelsesbegrensningene etter Taproot. Det er nettopp denne fleksibiliteten som gjør at OP_CAT kan støtte rekursive covenants, der én begrensning kan skape en annen begrensning lenger ned i kjeden – en egenskap som OP_CTV bevisst unngår.
Er OP_CAT i bruk på Bitcoin i dag?
Ikke på Bitcoins hovednettverk. BIP 347 har nådd statusen «Complete» som spesifikasjonsdokument, noe som betyr at selve forslaget er ferdig og klart definert. Dette er noe annet enn å bli implementert, noe som vil kreve at det bredere Bitcoin-fellesskapet og nodeoperatørene faktisk aktiverer det gjennom en soft fork.
Per midten av 2026 er ikke OP_CAT den ledende kandidaten for Bitcoins neste konsensusendring. Den posisjonen tilhører for øyeblikket OP_CTV sammen med OP_CHECKSIGFROMSTACK (BIP 348), en beslektet opkode som lar et skript verifisere en signatur mot vilkårlige data i stedet for kun selve utgiftstransaksjonen. Ifølge en Nyere referansehåndbok for Bitcoin BIP, per midten av 2026 er de ledende kandidatene for den neste konsensus-softforken covenant-forslagene BIP 119 (OP_CHECKTEMPLATEVERIFY) og BIP 348 (OP_CHECKSIGFROMSTACK), som vil muliggjøre nye skriptfunksjoner for vaults, kanalfabrikker og mer effektive lag-2-protokoller, selv om det ikke er fastsatt noen tidsplan for aktivering og konsensus i fellesskapet fortsatt er under utvikling.
OP_CTV har kommet lenger i aktiveringsprosessen enn OP_CAT. Utviklerne har publisert konkrete signalparametere For en soft fork i BIP9-stil: en startdato for signalering 30. mars 2026, et tidsvindu på ett år som utløper 30. mars 2027, en minimumsaktiveringshøyde rundt mai 2027 og en terskel på 90 % for signalering fra minere i hver to-ukers vanskelighetsperiode. Dette innebærer at CTV følger samme type mekanisme som aktiverte Taproot i 2021, selv om det langt fra er garantert at 90 %-terskelen vil bli nådd, gitt hvor omstridte covenant-forslagene fortsatt er i utviklermiljøet.
Dette betyr ikke at OP_CAT er død. Det betyr at den «neste» diskusjonen om soft fork i 2026 foreløpig dreier seg om et annet par opkoder, og at OP_CATs videre vei – hvis det finnes en – sannsynligvis avhenger av hvordan debatten om CTV og CSFS utspiller seg først.
OP_CAT er allerede i drift andre steder
Selv om OP_CAT fortsatt venter på å bli tatt i bruk i Bitcoins hovednettverk, er det ikke slik at det ikke har blitt testet. Det har i all stillhet vært i drift i en håndfull Bitcoin-relaterte nettverk i flere år.
- Liquid Network. Blockstreams fødererte sidekjede har hatt OP_CAT aktivert helt siden lanseringen, noe som har gitt det bredere Bitcoin-økosystemet et testmiljø i praksis flere år før BIP 347 i det hele tatt eksisterte.
- Bitcoin Cash og Bitcoin SV. Begge nettverkene har gjeninnført OP_CAT i forbindelse med protokolloppgraderinger, og den har behandlet transaksjoner på disse kjeder uten at det er dokumentert noen sikkerhetsutnyttelse knyttet til selve opkoden.
- Fraktal Bitcoin. Dette er den mest aktive implementeringen for øyeblikket. Fractal er en Bitcoin-kompatibel sidekjede, utviklet ved hjelp av Bitcoin Cores egen programvare og som drives gjennom «merge-mining» sammen med Bitcoin. Hovednettet ble lansert 9. september 2024, med OP_CAT aktivert fra første dag.
Fractal er verdt å se nærmere på, fordi det er det klareste svaret på spørsmålet «hvordan ville dette egentlig se ut på Bitcoin?». Siden lanseringen av Fractal har nye protokoller utnyttet OP_CAT til å lage smarte kontrakter basert på Bitcoin-programvaren, blant annet CAT-protokollen, som har vakt stor interesse blant Bitcoin-brukere, sammen med andre nye standarder som utvider nettverkets funksjonalitet ved hjelp av OP_CAT.
Det fremste eksemplet er CAT20, en standard for fungible tokens som er utviklet spesielt for å utnytte OP_CAT. Ifølge Fractal Bitcoins egen dokumentasjon, CAT20 er fullstendig validert av minere og fungerer ved hjelp av smarte kontrakter, nærmere bestemt rekursive avtaler, som håndheves utelukkende av Bitcoins eget skriptspråk på grunnlaget, noe som skiller det fra tokenstandarder som er avhengige av ekstern validering eller validering fra tredjeparter. I praksis betyr dette at distribusjon, utstedelse og overføring av et CAT20-token skjer gjennom en sekvens av OP_CAT-operasjoner som bygger opp en enkelt datastreng, som deretter blir innskrevet direkte i blokkjeden og sjekket av de samme minerne som sikrer nettverket, i stedet for av en separat indekseringstjeneste utenfor kjeden.
Historien om Quantum Cats: Hvordan en meme-kampanje bidro til å fremme OP_CAT
De fleste forslag til opkoder forblir begrenset til e-postlister og GitHub-tråder. OP_CAT gjorde ikke det, hovedsakelig på grunn av et Bitcoin Ordinals-prosjekt kalt Taproot Wizards.
I januar 2024 lanserte Taproot Wizards en samling på 3 333 NFT-lignende verk kalt «Quantum Cats», som var helt og holdent bygget opp rundt målet om å skape offentlig støtte for reaktiveringen av OP_CAT. Quantum Cats ønsket at OP_CAT skulle skape en tillatelsesfri bro som kunne flytte bitcoin og bitcoin-baserte eiendeler over til Bitcoin-lag 2-kjeder, der de kunne delta i mer kompleks handel. For å i det hele tatt kvalifisere seg til utgivelsen måtte deltakerne sette seg inn i det faktiske tekniske forslaget og offentlig gå inn for gjeninnføringen av det, noe som forvandlet en ganske tørr BIP-diskusjon til en fellesskapskampanje med reelle interesser på spill.
Selve samlingen fungerte samtidig som en demonstrasjon av sammenkobling i praksis. Hver «Quantum Cat» refererer til flere separate filer i stedet for ett statisk bilde, og etter hvert som nye filer blir avslørt, endrer kattene seg – noe som gjenspeiler nøyaktig hva OP_CAT gjør ved å sette sammen separate datadeler.
Kampanjen var så vellykket at den resulterte i betydelig finansiering. Taproot Wizards samlet inn 7,5 millioner dollar i 2023, etterfulgt av en finansieringsrunde på 30 millioner dollar i februar 2025, og begge beløpene var uttrykkelig øremerket utviklingen av OP_CAT-økosystemet. Medstifter Udi Wertheimer beskrev prosjektet som fokusert på OP_CAT som fremtiden for Bitcoin, der finansieringen går både til intern utvikling og til å støtte eksterne team som bygger videre på opkoden. Et enkelt Quantum Cat-salg hos Sotheby's, «Genesis Cat», endte på 254 000 dollar, noe som understreker hvor stor kulturell betydning kampanjen hadde fått rundt en fire-byte opkode.
Det er en nyttig påminnelse om at de tekniske debattene rundt Bitcoin ikke alltid forblir tekniske. Memer, kunst og penger har gjentatte ganger blitt verktøy for å bringe diskusjonene om protokollen ut i et bredere perspektiv, og OP_CAT er et av de tydeligste eksemplene på dette mønsteret i nyere tid.
Konklusjon
OP_CAT gjør én enkel ting: den slår sammen to datadelene på Bitcoins stakk til én. Det som gjør den så viktig, er alt denne ene funksjonen kan åpne for – fra sikrere cold storage-hvelv til post-kvante-signaturer og Bitcoin-innfødte tokens – dersom Bitcoin-samfunnet noen gang blir enige om å gjeninnføre den. Per juli 2026 har en slik enighet ikke blitt oppnådd. BIP 347 er en ferdig spesifikasjon som står bak OP_CTV og OP_CHECKSIGFROMSTACK i køen for Bitcoins neste konsensus-softfork, selv om OP_CAT fortsetter å kjøre stille og uten uhell på Fractal Bitcoin, Liquid og andre Bitcoin-relaterte nettverk. Uansett hva som skjer videre, har debatten rundt OP_CAT allerede vist hvordan et lite, enkelt stykke kode kan tiltrekke seg utviklere, kunstnere og investorer på en gang.
