Vad är Bitcoin OP_CAT? En förklaring av opkoden

OP_CAT är en Bitcoin-opkod som sammanfogar två datadelar på stacken till en, och den är för närvarande föremål för en av de längsta debatterna inom Bitcoin-utvecklingen. Den ingick i Bitcoins ursprungliga kod, men togs bort av Satoshi Nakamoto 2010 på grund av säkerhetshänsyn, och har under de senaste åren föreslagits som en soft fork (BIP 347) som skulle kunna öppna upp för en ny kategori av smart contract-liknande funktioner i Bitcoin. I juli 2026 är den inte aktiv på Bitcoins huvudnät, även om den redan körs på ett fåtal nätverk i anslutning till Bitcoin där den i tysthet utsätts för stresstester inför allmänheten.

Det som gör OP_CAT värt att förstå är inte bara koden. Det är alla aktörer som omger den: Bitcoin Core-utvecklare som debatterar om ändringen är säker, ett meme-drivet NFT-projekt som samlat in tiotals miljoner dollar för att driva på för dess återinförande, och en snabbt växande sidokedja som redan har tagit den i bruk. Den här guiden förklarar vad OP_CAT gör, varför den inaktiverades, vilka möjligheter den kan öppna upp för och exakt hur läget ser ut idag.

Använd Multichain Bitcoin.com Wallet-appen, som miljontals människor litar på för att på ett säkert och enkelt sätt skicka, ta emot, köpa, sälja, handla med, använda och hantera Bitcoin och kryptovalutor.

Viktiga slutsatser

• OP_CAT (förkortning för ”operation concatenate”) sammanfogar två dataelement i Bitcoins stack till ett enda element. Det är hela funktionen.
• Den var aktiv i Bitcoins allra första kod, men inaktiverades sedan av Satoshi Nakamoto år 2010 på grund av risken för överbelastningsattacker.
• Förslaget om att återinföra det, BIP 347, författades av Ethan Heilman och Armin Sabouri och tilldelades sitt BIP-nummer i april 2024.
• OP_CAT är i sig inte ett avtal, men i kombination med andra opkoder kan det användas för att skapa avtalsliknande utgiftsbegränsningar, däribland valv.
• I mitten av 2026 har OP_CAT ännu inte aktiverats i Bitcoins huvudnätverk. De nuvarande favoriterna för Bitcoins nästa konsensus-softfork är OP_CTV (BIP 119) och OP_CHECKSIGFROMSTACK (BIP 348), inte OP_CAT i sig.
• OP_CAT är redan i drift på Fractal Bitcoin, en sidokedja kopplad till Bitcoin, där den ligger till grund för tokenstandarden CAT20, och den har använts på Liquid Network och Bitcoin Cash i flera år utan att några säkerhetsbrister har upptäckts.
• Ett Bitcoin-NFT-projekt vid namn Quantum Cats, skapat av Taproot Wizards, har förvandlat stödet för OP_CAT till en memekampanj som har samlat in mer än 37 miljoner dollar till OP_CAT-relaterad utveckling.

Hur OP_CAT fungerar

Det tydligaste sättet att förstå OP_CAT är att föreställa sig Bitcoins skriptsystem som en liten stapel med byggklossar. Bitcoin Script, det programmeringsspråk som ligger till grund för varje Bitcoin-transaktion, är ett stapelbaserat språk. Data läggs in i stapeln, opkoder bearbetar det som ligger överst, och resultatet avgör om en transaktion är giltig.

OP_CAT tar de två översta elementen i stacken och sammanfogar dem, vilket innebär att de kopplas ihop ända till ända till ett enda kombinerat element, som sedan placeras tillbaka överst i stacken. Om stapeln innehåller värdena ”1” och ”2” tar OP_CAT bort båda och ersätter dem med ”12”. Enligt den officiella specifikationen i BIP 347, skulle OP_CAT lägga till x1 || x2 på stacken, där symbolen med två vertikala streck betecknar sammanfogning.

Det finns en viktig begränsning. OP_CAT misslyckas om det finns färre än två värden på stacken, eller om en sammanfogning av dem skulle resultera i ett sammanlagt värde som överstiger 520 byte, vilket är Bitcoins maximala storlek för skriptelement. Denna bytegräns har stor betydelse för denna opkods historia, vilket vi kommer att återkomma till strax.

I sig själv låter det inte särskilt avancerat att sammanfoga två datasträngar. Men Bitcoins skriptspråk har aldrig haft något allmänt tillämpbart sätt att kombinera värden på stacken, och den bristen har begränsat vad utvecklare kan bygga in direkt i Bitcoin-transaktioner. Eftersom Bitcoin Optech förklarar, Bitcoin Tapscript saknar ett allmänt tillämpligt sätt att kombinera objekt på stacken, vilket begränsar Tapscripts uttrycksförmåga och bland annat förhindrar möjligheten att konstruera och utvärdera Merkle-träd och andra hashbaserade datastrukturer direkt i Tapscript. OP_CAT är den föreslagna lösningen på just denna brist.

Varför inaktiverades OP_CAT år 2010?

OP_CAT ingick i Bitcoins allra första version. Satoshi Nakamoto tog bort den, tillsammans med flera andra opkoder såsom OP_MUL, OP_DIV och OP_OR, år 2010. Den officiella motiveringen handlade främst om risken för överbelastningsattacker: ett skript som upprepade gånger använde OP_CAT kunde i teorin generera en exponentiellt växande datamängd, tillräckligt stor för att sakta ner eller krascha noder som försökte validera den.

Vid den tiden fanns det ingen fast gräns för hur stor en enskild post i Bitcoins stack kunde vara. Det innebar att ett skadligt skript kunde fortsätta att sammanfoga värden tills det skapade en datasträng som var tillräckligt stor för att överbelasta nätverket. Att ta bort OP_CAT, tillsammans med de andra inaktiverade opkoderna, var ett försiktigt drag som prioriterade nätverksstabilitet framför funktionalitet som det unga nätverket ännu inte behövde.

Situationen förändrades i november 2021, när Bitcoin aktiverade Taproot-uppgraderingen. Taproot introducerade Tapscript, ett nytt skriptsammanhang med egna regler, varav en begränsar varje enskilt stackobjekt till 520 byte. Denna bytegräns stänger direkt av den ursprungliga attackvägen. Ett skript kan fortfarande anropa OP_CAT, men det kan aldrig generera ett värde som är tillräckligt stort för att skapa den typ av resursutarmningsproblem som oroade Satoshi år 2010. Det är denna tekniska detalj som åter öppnade dörren för att återinföra OP_CAT, men nu begränsat till Tapscript istället för hela Bitcoin Script.

Är OP_CAT ett avtal?

Nej, inte i sig, och detta är en av de vanligaste missuppfattningarna när det gäller OP_CAT. Ett ”covenant”, i Bitcoin-sammanhang, är en begränsning av hur en outnyttjad transaktionsutgång (UTXO) kan användas i framtiden. Vanligt Bitcoin-skript kan endast kontrollera om en utbetalning är godkänd just nu, vanligtvis genom att verifiera en signatur. Ett ”covenant” går längre och kontrollerar inte bara om en utbetalning är godkänd, utan även om den resulterande transaktionen uppfyller en specifik uppsättning villkor.

OP_CAT innehåller ingen inbyggd mekanism för att granska transaktionsdata. Det erbjuder istället ett sätt att kombinera datadelar på stacken, vilket endast blir användbart för covenants när det kombineras med andra opkoder som kontrollerar signaturer mot den kombinerade datan. I själva BIP 347 står det tydligt att OP_CAT, även om det har föreslagits för återaktivering i Tapscript, inte är ett ”covenant”. Det är mer korrekt att beskriva det som en byggsten som, i kombination med opkoder för signaturkontroll, kan användas för att efterlikna ett ”covenant”-liknande beteende.

Detta är viktigt eftersom OP_CAT:s flexibilitet är just det som gör den både intressant och kontroversiell. Även om OP_CAT kanske inte är ett avtal i sig, kan den efterlikna avtal på grund av en egenhet i hur Schnorr-signaturer fungerar. I kombination med en opkod som kallas CheckSigFromStack (CSFS), som kontrollerar en signatur mot godtyckliga data istället för enbart själva transaktionen, kan OP_CAT användas för att skapa samma typ av utgiftsbegränsningar som de särskilda opkoderna för avtal är utformade för att skapa.

Vad kan OP_CAT användas till?

Eftersom OP_CAT är en allmän primitiv snarare än en funktion med begränsat tillämpningsområde har utvecklare föreslagit en rad olika användningsområden för den. Bland de mest omtalade finns:

• Valv. Ett ”vault” är en typ av avtal som kräver flera steg, ofta fördelade över olika transaktioner och block, innan medel kan överföras. Detta medför en inbyggd fördröjning som ger ägaren tid att upptäcka och stoppa obehöriga utgifter, vilket förbättrar säkerheten vid kallförvaring och delad förvaring.
• Avtal som inte lämnar utrymme för tvetydigheter. Dessa kan medföra påföljder för en part i en betalningskanal, till exempel Lightning Network, som försöker sända ut ett föråldrat eller falskt kanaltillstånd, vilket stärker säkerheten i betalningssystem utanför blockkedjan.
• Trädens kännetecken. OP_CAT möjliggör kompakta multisignaturskript vars storlek endast ökar logaritmiskt med antalet undertecknare, vilket innebär att en transaktion på under 1 kilobyte teoretiskt sett skulle kunna stödja utbetalningsvillkor för miljontals publika nycklar.
• Uppbyggnad och verifiering av ett Merkle-träd. Eftersom skapandet och verifieringen av ett Merkle-träd i grunden kräver sammanfogning och hashning av värden, ger OP_CAT Bitcoin Script den saknade pusselbiten som behövs för att kunna göra detta direkt i själva koden.
• Postkvant-signaturer. OP_CAT kan aktivera Lamport-signaturer, ett signaturschema som anses vara motståndskraftigt mot attacker från kvantdatorer, eftersom Lamport-signaturer inte kräver något mer än förmågan att hasha och sammanfoga värden på stacken.
• Tokeniserade tillgångar och kedjeöverskridande bryggor. Genom att möjliggöra mer uttrycksfulla skript skulle OP_CAT kunna stödja utfärdande av tokens direkt på Bitcoin-kompatibla kedjor samt fler broar med minimerat förtroendebehov mellan Bitcoin och andra nätverk.

Det är värt att vara tydlig även när det gäller avvägningarna här. Samma flexibilitet som gör OP_CAT användbart för alla ovanstående tillämpningar är också det som får vissa Bitcoin-utvecklare att förhålla sig försiktiga till det. Eftersom OP_CAT är allmänt användbart snarare än specialutvecklat öppnar det upp vad utvecklare ibland kallar ett stort designutrymme, vilket innebär att det är svårare att förutsäga alla sätt på vilka det så småningom kan komma att kombineras med andra opkoder. Denna osäkerhet är kärnan i den pågående debatten, inte en sidofråga.

OP_CAT jämfört med OP_CTV: En jämförelse mellan de två ledande förslagen till avtal

OP_CAT diskuteras oftast tillsammans med OP_CTV (OP_CheckTemplateVerify), som föreslogs i BIP 119 av utvecklaren Jeremy Rubin. Båda syftar till att ge Bitcoin en form av avtalsfunktion, men de bygger på nästan motsatta designstrategier.

Den praktiska skillnaden handlar i grunden om omfattning. OP_CTV gör det möjligt för en transaktionsutgång att binda sig till en exakt framtida utgiftstransaktion, vilket omfattar detaljer som version, locktime, utgångar och antal ingångar. Om mallen stämmer överens går utgiften igenom. Stämmer den inte överens, går den inte igenom. Denna snäva inriktning är avsiktlig. CTV är icke-rekursivt, vilket innebär att en transaktion som den binder sig till inte i sin tur kan binda sig till ytterligare begränsningar på ett sätt som skapar en permanent kedja av villkor. Anhängare anser att detta är den säkrare och mer avgränsade formen av avtal.

OP_CAT utgår från en motsatt filosofi. Istället för att lösa ett specifikt problem ger den utvecklare en flexibel grundbyggsten som de kan bygga vidare på. Medan CTV är en noggrant avgränsad opkod utformad för att möjliggöra en specifik uppsättning användningsfall, är OP_CAT en primitiv – strängkonkatenering på stacken – som redan fanns i det ursprungliga Bitcoin-skriptspråket innan den inaktiverades 2010 på grund av farhågor om överbelastningsattacker, vilka inte längre är aktuella under de skriptstorleksbegränsningar som gäller efter Taproot. Det är just denna flexibilitet som gör att OP_CAT kan stödja rekursiva villkor, där en begränsning kan skapa en annan begränsning längre fram i kedjan – en egenskap som OP_CTV medvetet undviker.

Är OP_CAT i drift på Bitcoin idag?

Inte på Bitcoins huvudnätverk. BIP 347 har nått statusen ”Complete” som specifikationsdokument, vilket innebär att själva förslaget är färdigställt och väl definierat. Detta är något annat än att det har implementerats, vilket skulle kräva att det bredare Bitcoin-samhället och nodoperatörerna faktiskt aktiverar det genom en soft fork.

I mitten av 2026 är OP_CAT inte den främsta kandidaten för Bitcoins nästa konsensusförändring. Den positionen innehas för närvarande av OP_CTV tillsammans med OP_CHECKSIGFROMSTACK (BIP 348), en relaterad opkod som gör det möjligt för ett skript att verifiera en signatur mot godtyckliga data istället för enbart själva utgiftstransaktionen. Enligt en Aktuell referensguide för Bitcoin BIP, från och med mitten av 2026 är de främsta kandidaterna för nästa konsensus-softfork covenant-förslagen BIP 119 (OP_CHECKTEMPLATEVERIFY) och BIP 348 (OP_CHECKSIGFROMSTACK), vilka skulle möjliggöra nya skriptfunktioner för valv, kanalfabriker och mer effektiva lager-2-protokoll, även om ingen tidsplan för aktivering har fastställts och konsensus inom gemenskapen fortfarande håller på att bildas.

OP_CTV har kommit längre i aktiveringsprocessen än OP_CAT. Utvecklarna har publicerat konkreta signaleringsparametrar För en soft fork av BIP9-typ: ett startdatum för signalering den 30 mars 2026, en tidsfrist på ett år som löper ut den 30 mars 2027, en lägsta aktiveringshöjd omkring maj 2027 samt en tröskel på 90 % för gruvarbetarnas signalering under varje tvåveckors svårighetsperiod. Detta innebär att CTV genomgår samma typ av mekanism som aktiverade Taproot 2021, även om det långt ifrån är garanterat att tröskeln på 90 % kommer att nås, med tanke på hur omstridda covenant-förslagen fortfarande är inom utvecklargemenskapen.

Inget av detta innebär att OP_CAT är dödsdömt. Det innebär att diskussionen om den ”nästa” soft forken år 2026 för närvarande kretsar kring ett annat par opkoder, och OP_CAT:s framtid, om det finns någon, beror sannolikt på hur debatten om CTV och CSFS utvecklas först.

OP_CAT körs redan på andra håll

Även om OP_CAT fortfarande väntar på att införas i Bitcoins huvudnätverk, är det inte så att det inte har testats. Det har i tysthet använts i produktion på ett antal Bitcoin-relaterade nätverk i flera år.

• Liquid Network. Blockstreams federerade sidokedja har haft OP_CAT aktiverat ända sedan lanseringen, vilket har gett det bredare Bitcoin-ekosystemet en testmiljö i verkligheten flera år innan BIP 347 ens fanns.
• Bitcoin Cash och Bitcoin SV. Båda nätverken återinförde OP_CAT i samband med protokolluppgraderingar, och funktionen har hanterat transaktioner på dessa kedjor utan att någon dokumenterad säkerhetsbrist har kopplats till själva opkoden.
• Fraktal Bitcoin. Detta är den mest aktiva driftsmiljön just nu. Fractal är en Bitcoin-kompatibel sidokedja, byggd med hjälp av Bitcoin Cores egen programvara och som drivs genom merge-mining tillsammans med Bitcoin. Huvudnätverket lanserades den 9 september 2024 med OP_CAT aktiverat redan från första dagen.

Fractal är värt att titta närmare på, eftersom det är det tydligaste svaret på frågan ”hur skulle detta egentligen se ut på Bitcoin?”. Sedan Fractal lanserades har nya protokoll utnyttjat OP_CAT för att skapa smarta kontrakt baserade på Bitcoin-programvaran, däribland CAT-protokollet, som har väckt stort intresse bland Bitcoin-användare, tillsammans med andra nya standarder som utökar nätverkets funktionalitet med hjälp av OP_CAT.

Det främsta exemplet är CAT20, en standard för fungibla tokens som utvecklats särskilt för att dra nytta av OP_CAT. Enligt Fractal Bitcoins egen dokumentation, CAT20 valideras fullständigt av miners och fungerar med hjälp av smarta kontrakt, närmare bestämt rekursiva avtal, som helt och hållet verkställs av Bitcoins eget skriptspråk på baslagret, vilket skiljer det från tokenstandarder som förlitar sig på extern validering eller validering från tredje part. I praktiken innebär detta att distribution, utgivning och överföring av en CAT20-token sker genom en sekvens av OP_CAT-operationer som bygger upp en enda datasträng, vilken sedan skrivs in direkt i blockkedjan och kontrolleras av samma miners som säkrar nätverket, snarare än av en separat indexeringstjänst utanför kedjan.

Historien om Quantum Cats: Hur en memekampanj drev OP_CAT framåt

De flesta förslagen på opkoder stannar inom ramarna för e-postlistor och GitHub-trådar. Så var inte fallet med OP_CAT, främst tack vare ett Bitcoin Ordinals-projekt som heter Taproot Wizards.

I januari 2024 lanserade Taproot Wizards en samling i NFT-stil bestående av 3 333 exemplar, kallad Quantum Cats, som helt och hållet byggde på målet att skapa allmänhetens stöd för återaktiveringen av OP_CAT. Quantum Cats ville att OP_CAT skulle skapa en tillståndsfri brygga som kunde flytta bitcoin och bitcoinbaserade tillgångar till Bitcoin-lager 2-kedjor, där de kunde ingå i mer komplex handel. För att ens kvalificera sig för utgivningen var deltagarna tvungna att sätta sig in i det faktiska tekniska förslaget och offentligt förespråka dess återinförande, vilket förvandlade en ganska torr BIP-diskussion till en gemenskapskampanj med verkliga insatser på spel.

Samlingen i sig fungerade samtidigt som en demonstration av hur sammanfogning fungerar i praktiken. Varje Quantum Cat hänvisar till flera separata filer istället för en enda statisk bild, och i takt med att nya filer avslöjas över tid förändras katterna, vilket exakt återspeglar hur OP_CAT fungerar genom att sätta ihop separata datadelar.

Kampanjen var så framgångsrik att den ledde till betydande finansiering. Taproot Wizards samlade in 7,5 miljoner dollar år 2023, följt av en finansieringsrunda på 30 miljoner dollar i februari 2025, där båda beloppen uttryckligen var öronmärkta för utvecklingen av OP_CAT-ekosystemet. Medgrundaren Udi Wertheimer beskrev projektet som inriktat på OP_CAT som Bitcoins framtid, där finansieringen går till både intern utveckling och stöd till externa team som bygger vidare på opkoden. En enda Quantum Cat-auktion hos Sotheby’s, den så kallade ”Genesis Cat”, avslutades på 254 000 dollar, vilket understryker just hur stor kulturell tyngd kampanjen hade fått kring en opkod på fyra byte.

Det är en bra påminnelse om att de tekniska debatterna kring Bitcoin inte alltid förblir rent tekniska. Memes, konst och pengar har gång på gång använts som verktyg för att lyfta fram diskussionerna om protokollet till en bredare publik, och OP_CAT är ett av de tydligaste exemplen på detta mönster på senare tid.

Slutsats

OP_CAT gör en enkel sak: den sammanfogar två datadelar i Bitcoins stack till en. Det som gör den betydelsefull är allt som den här enda funktionen skulle kunna möjliggöra – från säkrare kallförvaringsvalv till postkvantiska signaturer och Bitcoin-inbyggda tokens – om Bitcoin-gemenskapen någonsin skulle enas om att återinföra den. I juli 2026 har ingen sådan överenskommelse nåtts. BIP 347 är en färdig specifikation som står bakom OP_CTV och OP_CHECKSIGFROMSTACK i kön för Bitcoins nästa konsensus-softfork, även om OP_CAT fortsätter att köras tyst och utan incidenter på Fractal Bitcoin, Liquid och andra Bitcoin-relaterade nätverk. Oavsett vad som händer härnäst har debatten kring OP_CAT redan visat hur en liten, enkel kodsnutt kan locka till sig utvecklare, konstnärer och investerare på en och samma gång.