OP_CAT ist ein Bitcoin-Opcode, der zwei Datenelemente auf dem Stack zu einem zusammenführt, und ist derzeit Gegenstand einer der am längsten andauernden Debatten in der Bitcoin-Entwicklung. Er war Teil des ursprünglichen Bitcoin-Codes, wurde jedoch 2010 von Satoshi Nakamoto aus Sicherheitsbedenken entfernt und war in den letzten Jahren Gegenstand eines Vorschlags für einen Soft Fork (BIP 347), der eine neue Kategorie von Smart-Contract-ähnlichen Funktionen auf Bitcoin ermöglichen könnte. Stand Juli 2026 ist er im Bitcoin-Mainnet nicht aktiv, läuft jedoch bereits in einer Handvoll Bitcoin-naher Netzwerke, wo er still und leise öffentlich einem Stresstest unterzogen wird.
Was OP_CAT so interessant macht, ist nicht nur der Code selbst. Es sind die Akteure, die damit zu tun haben: Bitcoin-Core-Entwickler, die darüber debattieren, ob die Änderung sicher ist, ein von Memes getriebenes NFT-Projekt, das Dutzende Millionen Dollar gesammelt hat, um sich für die Wiedereinführung einzusetzen, und eine schnell wachsende Sidechain, die die Funktion bereits nutzt. Dieser Leitfaden erklärt, was OP_CAT bewirkt, warum es deaktiviert wurde, welche Möglichkeiten es eröffnen könnte und wie genau der aktuelle Stand der Dinge ist.
Verwenden Sie die Multichain Bitcoin.com Wallet-App, auf das Millionen von Menschen vertrauen, um Bitcoin und Kryptowährungen sicher und einfach zu versenden, zu empfangen, zu kaufen, zu verkaufen, zu tauschen, zu nutzen und zu verwalten.
Die wichtigsten Erkenntnisse
- OP_CAT (kurz für „Operation Concatenate“) fasst zwei Datenelemente auf dem Bitcoin-Stack zu einem einzigen Element zusammen. Das ist die gesamte Funktion.
- Diese Funktion war im allerersten Code von Bitcoin aktiv, wurde dann aber 2010 von Satoshi Nakamoto aufgrund eines Denial-of-Service-Risikos deaktiviert.
- Der Vorschlag zur Wiedereinführung, BIP 347, wurde von Ethan Heilman und Armin Sabouri verfasst und erhielt im April 2024 seine BIP-Nummer.
- OP_CAT ist an sich kein Covenant, kann jedoch in Kombination mit anderen Opcodes dazu verwendet werden, Covenant-ähnliche Ausgabebeschränkungen zu erstellen, darunter auch „Vaults“.
- Bis Mitte 2026 wurde OP_CAT im Bitcoin-Hauptnetz noch nicht aktiviert. Die derzeitigen Favoriten für Bitcoins nächsten Konsens-Soft-Fork sind OP_CTV (BIP 119) und OP_CHECKSIGFROMSTACK (BIP 348), nicht OP_CAT allein.
- OP_CAT ist bereits auf Fractal Bitcoin, einer an Bitcoin angelehnten Sidechain, im Einsatz, wo es den CAT20-Token-Standard unterstützt, und läuft seit Jahren auf dem Liquid Network und Bitcoin Cash, ohne dass bisher eine Sicherheitslücke bekannt geworden wäre.
- Ein von Taproot Wizards ins Leben gerufenes Bitcoin-NFT-Projekt namens „Quantum Cats“ hat die Unterstützung für OP_CAT zu einer Meme-Kampagne gemacht, durch die mehr als 37 Millionen Dollar für die Entwicklung im Zusammenhang mit OP_CAT gesammelt wurden.
So funktioniert OP_CAT
Am besten lässt sich OP_CAT verstehen, wenn man sich das Skriptsystem von Bitcoin als einen kleinen Stapel von Bausteinen vorstellt. Bitcoin Script, die Programmiersprache, die hinter jeder Bitcoin-Transaktion steht, ist eine stapelbasierte Sprache. Daten werden auf den Stapel geschoben, Opcodes wirken auf das, was ganz oben liegt, und das Ergebnis entscheidet darüber, ob eine Transaktion gültig ist.
OP_CAT nimmt die beiden obersten Elemente des Stacks und verkettet sie, d. h., es fügt sie Ende an Ende zu einem einzigen kombinierten Element zusammen, das anschließend wieder an die Spitze des Stacks gesetzt wird. Wenn der Stapel die Werte „1“ und „2“ enthält, werden durch die Ausführung von OP_CAT beide entfernt und durch „12“ ersetzt. Gemäß der offiziellen Spezifikation in BIP 347, OP_CAT würde x1 || x2 auf den Stack schieben, wobei das Doppel-Pipe-Symbol die Verkettung bezeichnet.
Es gibt jedoch eine wichtige Einschränkung: OP_CAT schlägt fehl, wenn sich weniger als zwei Werte auf dem Stack befinden oder wenn durch deren Zusammenführung ein kombinierter Wert entstehen würde, der größer als 520 Byte ist – dies entspricht der maximalen Größe eines Skriptelements bei Bitcoin. Diese Byte-Obergrenze spielt eine wichtige Rolle in der Geschichte dieses Opcodes, auf die wir gleich noch eingehen werden.
Für sich genommen klingt das Zusammenfügen zweier Datenstränge nicht besonders beeindruckend. Doch die Skriptsprache von Bitcoin verfügte bislang über keine universelle Möglichkeit, Werte auf dem Stack zu kombinieren, und diese Lücke hat die Möglichkeiten der Entwickler eingeschränkt, bestimmte Funktionen direkt in Bitcoin-Transaktionen zu integrieren. Da Bitcoin Optech erklärt, In Bitcoin Tapscript fehlt eine universelle Möglichkeit, Objekte auf dem Stack zu kombinieren, was die Ausdruckskraft von Tapscript einschränkt und unter anderem die Erstellung und Auswertung von Merkle-Bäumen und anderen Hash-Datenstrukturen direkt in Tapscript verhindert. OP_CAT ist der vorgeschlagene Lösungsansatz für diese spezifische Lücke.
Warum wurde OP_CAT im Jahr 2010 deaktiviert?
OP_CAT war Teil der allerersten Version von Bitcoin. Satoshi Nakamoto entfernte es 2010 zusammen mit mehreren anderen Opcodes wie OP_MUL, OP_DIV und OP_OR. Die offizielle Begründung bezog sich auf ein Denial-of-Service-Risiko: Ein Skript, das OP_CAT wiederholt verwendet, könnte theoretisch eine exponentiell wachsende Datenmenge erzeugen, die groß genug ist, um Knoten, die versuchen, diese zu validieren, zu verlangsamen oder zum Absturz zu bringen.
Zu dieser Zeit gab es keine feste Obergrenze dafür, wie groß ein einzelner Eintrag im Bitcoin-Stack sein durfte. Das bedeutete, dass ein bösartiges Skript Werte so lange aneinanderreihen konnte, bis es eine Datenfolge erzeugte, die so umfangreich war, dass sie das Netzwerk lahmlegte. Die Entfernung von OP_CAT sowie der anderen deaktivierten Opcodes war eine konservative Maßnahme, bei der die Netzwerkstabilität Vorrang vor Funktionen hatte, die das noch junge Netzwerk noch nicht benötigte.
Die Situation änderte sich im November 2021, als Bitcoin das Taproot-Upgrade aktivierte. Mit Taproot wurde Tapscript eingeführt, ein neuer Skriptkontext mit eigenen Regeln, von denen eine jedes einzelne Stack-Element auf 520 Byte begrenzt. Diese Byte-Beschränkung macht den ursprünglichen Angriffsweg direkt unbrauchbar. Ein Skript kann zwar weiterhin OP_CAT aufrufen, es kann jedoch niemals einen Wert erzeugen, der groß genug ist, um das Problem der Ressourcenerschöpfung zu verursachen, das Satoshi im Jahr 2010 beunruhigte. Dies ist das technische Detail, das den Weg für die Rückkehr von OP_CAT wieder frei gemacht hat – allerdings nur im Rahmen von Tapscript und nicht für das gesamte Bitcoin-Skript.
Ist OP_CAT ein Covenant?
Nein, nicht an sich, und das ist einer der am häufigsten missverstandenen Punkte bei OP_CAT. Ein „Covenant“ ist in der Bitcoin-Terminologie eine Einschränkung, wie ein noch nicht ausgegebener Transaktionsausgang (UTXO) in Zukunft ausgegeben werden kann. Normales Bitcoin-Script kann nur prüfen, ob eine Ausgabe zum aktuellen Zeitpunkt autorisiert ist, in der Regel durch die Überprüfung einer Signatur. Ein „Covenant“ geht darüber hinaus und prüft nicht nur, ob eine Ausgabe autorisiert ist, sondern auch, ob die daraus resultierende Transaktion einer bestimmten Reihe von Bedingungen entspricht.
OP_CAT enthält keinen integrierten Mechanismus zur Überprüfung von Transaktionsdaten. Es bietet lediglich eine Möglichkeit, Datenelemente auf dem Stack zu kombinieren, was für Covenants jedoch erst dann von Nutzen ist, wenn es mit anderen Opcodes kombiniert wird, die Signaturen anhand dieser kombinierten Daten überprüfen. In BIP 347 selbst heißt es ganz klar dass OP_CAT, obwohl es in Tapscript zur Reaktivierung vorgeschlagen wurde, kein „Covenant“ ist. Es ist zutreffender, es als Baustein zu bezeichnen, der in Kombination mit Opcodes zur Signaturprüfung dazu verwendet werden kann, ein „Covenant“-ähnliches Verhalten zu emulieren.
Dies ist von Bedeutung, da gerade die Flexibilität von OP_CAT das ist, was es sowohl interessant als auch umstritten macht. Auch wenn OP_CAT an sich vielleicht kein „Covenant“ ist, kann es aufgrund einer Besonderheit in der Funktionsweise von Schnorr-Signaturen solche „Covenants“ nachahmen. In Kombination mit einem Opcode namens „CheckSigFromStack“ (CSFS), der eine Signatur nicht nur anhand der Transaktion selbst, sondern auch anhand beliebiger Daten überprüft, lässt sich OP_CAT nutzen, um dieselbe Art von Ausgabebeschränkungen zu schaffen, für die spezielle Covenant-Opcodes entwickelt wurden.
Wofür könnte OP_CAT verwendet werden?
Da es sich bei OP_CAT eher um eine universell einsetzbare Primitive als um eine Funktion mit eng begrenztem Anwendungsbereich handelt, haben Entwickler eine Vielzahl von Anwendungsmöglichkeiten dafür vorgeschlagen. Zu den am häufigsten diskutierten gehören:
- Gewölbe. Ein „Vault“ ist eine Art von Vertrag, bei dem mehrere Schritte erforderlich sind – oft über mehrere Transaktionen und Blöcke hinweg –, bevor Gelder bewegt werden können. Dadurch entsteht eine integrierte Verzögerung, die dem Eigentümer Zeit gibt, unbefugte Ausgaben zu bemerken und zu stoppen, was die Sicherheit von Cold-Storage- und Shared-Custody-Lösungen verbessert.
- Verträge ohne Zweideutigkeiten. Diese können eine Partei in einem Zahlungskanal, wie beispielsweise dem Lightning Network, bestrafen, die versucht, einen veralteten oder betrügerischen Kanalzustand zu übertragen, und stärken so die Sicherheit von Off-Chain-Zahlungssystemen.
- Baum-Signaturen. OP_CAT ermöglicht kompakte Multisignatur-Skripte, deren Größe nur logarithmisch mit der Anzahl der Unterzeichner wächst. Das bedeutet, dass eine Transaktion mit einer Größe von weniger als 1 Kilobyte theoretisch Ausgabebedingungen für Millionen von öffentlichen Schlüsseln unterstützen könnte.
- Erstellung und Überprüfung eines Merkle-Baums. Da das Erstellen und Überprüfen eines Merkle-Baums grundsätzlich das Verketten und Hashen von Werten erfordert, liefert OP_CAT Bitcoin Script das fehlende Puzzlestück, um dies nativ durchführen zu können.
- Post-Quanten-Signaturen. OP_CAT kann Lamport-Signaturen ermöglichen, ein Signaturschema, das als widerstandsfähig gegen Angriffe durch Quantencomputer gilt, da Lamport-Signaturen lediglich die Fähigkeit erfordern, Werte auf dem Stack zu hashen und zu verketten.
- Tokenisierte Vermögenswerte und kettenübergreifende Brücken. Durch die Ermöglichung ausdrucksstärkerer Skripte könnte OP_CAT die Ausgabe von Token direkt auf Bitcoin-kompatiblen Blockchains sowie vertrauensminimierte Brücken zwischen Bitcoin und anderen Netzwerken unterstützen.
Auch hier lohnt es sich, die Vor- und Nachteile offen anzusprechen. Genau jene Flexibilität, die OP_CAT für alle oben genannten Anwendungsfälle nützlich macht, ist es auch, die manche Bitcoin-Entwickler zur Vorsicht mahnt. Da OP_CAT eher universell einsetzbar als zweckgebunden ist, eröffnet es einen – wie Entwickler es manchmal nennen – großen Gestaltungsspielraum, was bedeutet, dass es schwieriger ist, alle möglichen Kombinationen mit anderen Opcodes vorherzusagen. Diese Unsicherheit steht im Mittelpunkt der aktuellen Debatte und ist kein Nebenthema.
OP_CAT vs. OP_CTV: Ein Vergleich der beiden führenden Covenant-Vorschläge
OP_CAT wird in der Regel zusammen mit OP_CTV (OP_CheckTemplateVerify) diskutiert, das vom Entwickler Jeremy Rubin in BIP 119 vorgeschlagen wurde. Beide zielen darauf ab, Bitcoin eine Art „Covenant“-Fähigkeit zu verleihen, verfolgen dabei jedoch nahezu gegensätzliche Designansätze.
Der praktische Unterschied liegt im Anwendungsbereich. Mit OP_CTV kann sich ein Transaktions-Output auf genau eine zukünftige Ausgabetransaktion festlegen, wobei Details wie Version, Locktime, Outputs und Anzahl der Inputs berücksichtigt werden. Stimmt die Vorlage überein, wird die Ausgabe ausgeführt. Stimmt sie nicht überein, wird die Ausgabe nicht freigegeben. Diese Eingrenzung ist beabsichtigt. CTV ist nicht rekursiv, was bedeutet, dass eine Transaktion, an die sie gebunden ist, sich nicht selbst an weitere Einschränkungen binden kann, sodass keine permanente Kette von Auflagen entsteht. Befürworter betrachten dies als die sicherere, begrenztere Form eines Covenants.
OP_CAT verfolgt den gegenteiligen Ansatz. Anstatt ein bestimmtes Problem zu lösen, stellt es Entwicklern eine flexible Grundfunktion zur Verfügung, auf der sie aufbauen können. Während CTV ein sorgfältig abgegrenzter Opcode ist, der für eine bestimmte Reihe von Anwendungsfällen konzipiert wurde, handelt es sich bei OP_CAT um eine Grundfunktion – die Zeichenfolgenverkettung auf dem Stack –, die bereits in der ursprünglichen Bitcoin-Skriptsprache enthalten war, bevor sie 2010 aufgrund von Bedenken hinsichtlich Denial-of-Service-Angriffen deaktiviert wurde – Bedenken, die unter den Skriptgrößenbeschränkungen nach der Taproot-Einführung nicht mehr zutreffen. Genau diese Flexibilität ermöglicht es OP_CAT, rekursive Covenants zu unterstützen, bei denen eine Einschränkung eine weitere Einschränkung nach sich ziehen kann – eine Eigenschaft, die OP_CTV bewusst vermeidet.
Ist OP_CAT heute bei Bitcoin in Betrieb?
Nicht im Bitcoin-Hauptnetz. BIP 347 hat als Spezifikationsdokument den Status „Complete“ erreicht, was bedeutet, dass der Vorschlag selbst fertiggestellt und klar definiert ist. Dies ist jedoch noch nicht gleichbedeutend mit der tatsächlichen Umsetzung, für die es erforderlich wäre, dass die breitere Bitcoin-Community und die Knotenbetreiber ihn durch einen Soft Fork aktivieren.
Stand Mitte 2026 ist OP_CAT nicht der führende Kandidat für die nächste Konsensänderung bei Bitcoin. Diese Position nimmt derzeit OP_CTV ein, zusammen mit OP_CHECKSIGFROMSTACK (BIP 348), einem verwandten Opcode, der es einem Skript ermöglicht, eine Signatur anhand beliebiger Daten zu überprüfen und nicht nur anhand der Ausgabetransaktion selbst. Laut einem Aktuelles Bitcoin-BIP-Handbuch, Stand Mitte 2026 sind die führenden Kandidaten für den nächsten Konsens-Soft-Fork die Covenant-Vorschläge BIP 119 (OP_CHECKTEMPLATEVERIFY) und BIP 348 (OP_CHECKSIGFROMSTACK), die neue Skriptfunktionen für Tresore, Channel-Fabriken und effizientere Layer-2-Protokolle ermöglichen würden, obwohl noch kein Zeitplan für die Aktivierung festgelegt wurde und sich der Konsens in der Community noch herausbildet.
OP_CTV ist im Aktivierungsprozess bereits weiter fortgeschritten als OP_CAT. Die Entwickler haben veröffentlicht konkrete Signalparameter Für einen Soft Fork nach dem BIP9-Modell: ein Startdatum für die Signalisierung am 30. März 2026, ein einjähriges Zeitfenster, das am 30. März 2027 endet, eine Mindestaktivierungshöhe etwa im Mai 2027 und eine Schwelle von 90 % der Miner-Signalisierung während jedes zweiwöchigen Schwierigkeitszeitraums. Damit unterliegt CTV demselben Mechanismus, der 2021 zur Aktivierung von Taproot führte, wobei das Erreichen der 90-Prozent-Schwelle jedoch keineswegs garantiert ist, da die Covenant-Vorschläge innerhalb der Entwickler-Community nach wie vor umstritten sind.
Das bedeutet keineswegs, dass OP_CAT vom Tisch ist. Es bedeutet vielmehr, dass sich die Diskussion um den „nächsten“ Soft Fork im Jahr 2026 derzeit auf ein anderes Opcode-Paar konzentriert und dass der weitere Weg von OP_CAT – sofern es einen gibt – wahrscheinlich davon abhängt, wie sich die Debatte um CTV und CSFS zunächst entwickelt.
OP_CAT läuft bereits an anderer Stelle
Auch wenn OP_CAT noch auf die Einführung im Bitcoin-Mainnet wartet, bleibt es nicht ungetestet. Seit Jahren läuft es bereits unbemerkt in der Produktion auf einer Handvoll Bitcoin-bezogener Netzwerke.
- Liquid Network. In der föderierten Sidechain von Blockstream ist OP_CAT seit ihrer Einführung aktiviert, wodurch dem gesamten Bitcoin-Ökosystem bereits Jahre vor der Veröffentlichung von BIP 347 eine Testumgebung unter realen Bedingungen zur Verfügung stand.
- Bitcoin Cash und Bitcoin SV. Beide Netzwerke haben OP_CAT im Rahmen von Protokoll-Upgrades wieder eingeführt, und es hat Transaktionen auf diesen Ketten verarbeitet, ohne dass ein dokumentierter Exploit im Zusammenhang mit dem Opcode selbst aufgetreten ist.
- Fractal Bitcoin. Dies ist die derzeit aktivste Implementierung. Fractal ist eine an Bitcoin angelehnte Sidechain, die auf der Basis der Bitcoin-Core-Software entwickelt wurde und im Merge-Mining mit Bitcoin betrieben wird. Das Mainnet von Fractal wurde am 9. September 2024 gestartet, wobei OP_CAT von Beginn an aktiviert war.
Fractal ist einen genaueren Blick wert, da es die klarste Antwort auf die Frage „Wie würde das bei Bitcoin konkret aussehen?“ darstellt. Seit der Einführung von Fractal haben neue Protokolle OP_CAT genutzt, um Smart Contracts auf Basis der Bitcoin-Software zu erstellen, darunter das CAT-Protokoll, das bei Bitcoin-Nutzern großes Interesse geweckt hat, sowie weitere aufkommende Standards, die die Funktionalität des Netzwerks mithilfe von OP_CAT erweitern.
Das Paradebeispiel ist CAT20, ein Standard für fungible Token, der speziell entwickelt wurde, um die Vorteile von OP_CAT zu nutzen. Laut Die Dokumentation von Fractal Bitcoin, CAT20 wird vollständig von Minern validiert und arbeitet mit Smart Contracts, insbesondere mit rekursiven Covenants, die vollständig durch Bitcoins eigene Skriptsprache auf der Basisebene durchgesetzt werden, wodurch es sich von Token-Standards unterscheidet, die auf einer externen oder durch Dritte durchgeführten Validierung beruhen. In der Praxis bedeutet dies, dass das Bereitstellen, Prägen und Übertragen eines CAT20-Tokens über eine Abfolge von OP_CAT-Operationen erfolgt, die eine einzelne Datenfolge bilden, die dann direkt in die Blockchain eingetragen und von denselben Minern überprüft wird, die das Netzwerk sichern – und nicht von einem separaten Off-Chain-Indexierungsdienst.
Die Geschichte von Quantum Cats: Wie eine Meme-Kampagne OP_CAT vorangebracht hat
Die meisten Opcode-Vorschläge bleiben auf Mailinglisten und GitHub-Threads beschränkt. Bei OP_CAT war dies nicht der Fall, was vor allem auf ein Bitcoin-Ordinals-Projekt namens „Taproot Wizards“ zurückzuführen ist.
Im Januar 2024 brachte Taproot Wizards eine aus 3.333 Stücken bestehende NFT-Kollektion namens „Quantum Cats“ auf den Markt, die ausschließlich darauf abzielte, öffentliche Unterstützung für die Reaktivierung von OP_CAT zu gewinnen. Quantum Cats strebte an, dass OP_CAT eine genehmigungsfreie Brücke schaffen würde, über die Bitcoin und auf Bitcoin basierende Vermögenswerte auf Bitcoin-Layer-2-Chains übertragen werden könnten, wo sie an komplexeren Handelsaktivitäten teilnehmen könnten. Um sich überhaupt für die Prägung zu qualifizieren, mussten sich die Teilnehmer mit dem eigentlichen technischen Vorschlag auseinandersetzen und sich öffentlich für dessen Wiedereinführung einsetzen – wodurch aus einer eher trockenen BIP-Diskussion eine Community-Kampagne mit echtem Einsatz wurde.
Die Sammlung selbst diente gleichzeitig als Demonstration der Verkettung in der Praxis. Jede „Quantum Cat“ verweist auf mehrere separate Dateien statt auf ein einziges statisches Bild, und da im Laufe der Zeit neue Dateien enthüllt werden, verändern sich die Katzen – genau wie bei OP_CAT, das separate Datenelemente miteinander verknüpft.
Die Kampagne war so erfolgreich, dass sie zu einer beträchtlichen Finanzierung führte. Taproot Wizards sammelte im Jahr 2023 7,5 Millionen US-Dollar ein, gefolgt von einer Finanzierungsrunde in Höhe von 30 Millionen US-Dollar im Februar 2025; beide Summen waren ausdrücklich für die Entwicklung des OP_CAT-Ökosystems vorgesehen. Mitbegründer Udi Wertheimer beschrieb das Projekt als auf OP_CAT als Zukunft von Bitcoin ausgerichtet, wobei die Mittel sowohl für die interne Entwicklung als auch zur Unterstützung externer Teams fließen, die auf dem Opcode aufbauen. Ein einzelner „Quantum Cat“-Verkauf bei Sotheby’s, der „Genesis Cat“, wurde für 254.000 US-Dollar abgeschlossen, was deutlich macht, wie viel kulturelles Gewicht die Kampagne rund um einen vier Byte großen Opcode gewonnen hatte.
Das ist eine nützliche Erinnerung daran, dass die technischen Debatten rund um Bitcoin nicht immer rein technischer Natur bleiben. Memes, Kunst und Geld haben sich immer wieder als Mittel erwiesen, um Diskussionen über das Protokoll einer breiteren Öffentlichkeit zugänglich zu machen, und OP_CAT ist eines der deutlichsten Beispiele der letzten Zeit für dieses Muster.
Fazit
OP_CAT erfüllt eine einfache Aufgabe: Es verbindet zwei Datenelemente auf dem Bitcoin-Stack zu einem einzigen. Was diese Funktion so bedeutsam macht, ist das gesamte Potenzial, das sie erschließen könnte – von sichereren Cold-Storage-Speichern über postquanten-sichere Signaturen bis hin zu Bitcoin-nativen Token –, sollte sich die Bitcoin-Community jemals darauf einigen, sie wieder einzuführen. Bis Juli 2026 ist diese Einigung noch nicht zustande gekommen. BIP 347 ist eine fertige Spezifikation, die hinter OP_CTV und OP_CHECKSIGFROMSTACK in der Warteschlange für Bitcoins nächsten Konsens-Soft-Fork steht, auch wenn OP_CAT weiterhin still und ohne Zwischenfälle auf Fractal Bitcoin, Liquid und anderen Bitcoin-bezogenen Netzwerken läuft. Was auch immer als Nächstes geschieht – die Debatte um OP_CAT hat bereits gezeigt, wie ein kleines, einfaches Stück Code Entwickler, Künstler und Investoren gleichermaßen anziehen kann.
