Igor Kulatov, ehemaliger Mitgründer und CTO der NAGA Group AG, erläutert die Engineering-Entscheidungen, die NAGA als Maßstab für den breiteren Markt etablierten.

Als Mitgründer und CTO der NAGA Group AG entwickelte Igor Kulatov Swipestox, die Social-Trading-Plattform, die das Unternehmen im Juli 2017 an die Frankfurter Wertpapierbörse brachte. Nach dem Börsengang leitete er den Ausbau des Kryptowährungsgeschäfts des Unternehmens — einschließlich einer eigenen Matching Engine, einer Multi-Chain-Verwahrarchitektur und der Integration von Handelsplätzen über mehrere Anlageklassen hinweg — der im selben Jahr in NAGAs Initial Coin Offering, dem NGC-Token-Verkauf, mündete. 2017 war weltweit das Spitzenjahr für ICOs, mit Milliardenbeträgen, die über Hunderte von Token-Verkäufen eingesammelt wurden, doch nur sehr wenige Emittenten operierten innerhalb einer börsennotierten, regulierten Brokerage-Struktur. Kulatov führt heute Aurora Borealis, ein autonomes Business-to-Business-Commerce-Unternehmen, das bereits in Produktion lief, während die breitere Branche die Kategorie noch definierte. Beide Unternehmungen zeigen ein Muster: Aufbauarbeit, bevor der Markt sie vollständig versteht. In diesem Interview spricht Kulatov darüber, wie er Marktrichtungen einschätzt, welche konkreten Engineering-Entscheidungen bei NAGA getroffen wurden und was davon in seine heutige Arbeit eingeflossen ist.

Q1. Ihre Laufbahn folgt einem klar erkennbaren Muster. Vor NAGA ebenso wie vor dem autonomen Commerce-Unternehmen hätten die meisten Ingenieure in Ihrem Umfeld mit völlig anderen Annahmen gearbeitet. Worauf achten Sie, wenn Sie einschätzen wollen, wo ein Markt in fünf oder sieben Jahren stehen wird?

Ich musste die Zukunft von Krypto nicht vorhersagen. Was ich hatte, war ein belastbares Bild davon, wie eine ausgereifte Börse aussieht — ich hatte bereits vor NAGA Börsensysteme gebaut und wusste, welche Standards auf der traditionellen Seite gelten. Die meisten Kryptoplattformen der Jahre 2016 und 2017 wurden von Teams entwickelt, die das Problem aus der entgegengesetzten Richtung angingen — von Krypto nach außen, nicht aus der Börsendisziplin nach innen. Dadurch fehlten ihnen Elemente, die eine ausgereifte Börse als selbstverständlich voraussetzt: eine Matching-Engine-Performance, die institutionellen Orderflow bewältigen kann, eine Verwahrgrenze, die ein Regulator auf dem Papier klar nachvollziehen kann, und eine Rechtsstruktur, die sowohl ein Aktienbuch als auch tatsächliche Kryptowährungswerte tragen kann.

Meine Arbeitsregel war einfach: Baue für den Standard, der kommt, nicht für den, der heute bequem ist. Im Kryptobereich war 2017 der bequeme Standard, alles schnell zu bauen und die schwierigen Probleme aufzuschieben. Der kommende Standard würde einer regulierten Börse sehr viel ähnlicher sehen. Also habe ich genau darauf hingebaut.

Q2. Nehmen wir eine dieser Zahlen. 2017 war Liquibook die Open-Source-Referenz für Matching Engines, mit ungefähr zwei bis zweieinhalb Millionen Inserts pro Sekunde. Sie bauten eine Engine, die in synthetischen Tests etwa acht Millionen Matches pro Sekunde erreichte. Was deutete darauf hin, dass die Obergrenze so hoch sein musste?

Diese Lücke ist weniger groß, als sie wirkt — Liquibook veröffentlicht den Insert-Durchsatz, während Matching pro Ereignis eine deutlich schwerere Operation ist. Die reine Zahl war nicht der Treiber des Designs. Ausschlaggebend war, dass wir für eine Art von Orderflow bauten, die die Kryptoseite damals noch nicht erlebt hatte. Institutionelle Händler setzen Maschinen ein, die rund um die Uhr laufen. Der Unterschied zwischen einer Obergrenze von einer halben Million Matches pro Sekunde und einer Obergrenze von acht Millionen ist der Unterschied zwischen einem Neubau der Engine im dritten Jahr und dem Betrieb derselben Engine im achten Jahr.

Deshalb haben wir sie durchgängig selbst verantwortet. Eine Matching Engine ist kompakt genug, dass einige Tausend Zeilen eigener Code eine Universalbibliothek übertreffen können, die für alle Anwender sicher bleiben muss. Binance baute seine Matching Engine im Juni 2020 neu — von Grund auf in einer neuen Sprache, mit ungefähr zwei Jahren Engineering-Arbeit und einer etwa zehnfachen Leistungssteigerung. Ein solcher Neubau ist nicht nur ein Entwicklungsaufwand. Er bedeutet zwei Jahre, in denen das System unter Lasten läuft, für die es nie konzipiert war — mit Warteschlangen bei Volatilitätsspitzen, verzögerten Orders und Orderflow, der zu dem Handelsplatz abwandert, der ihn bewältigen kann. Der Grund, warum wir das 2020 nicht tun mussten, war, dass wir bereits 2017 für diese Obergrenze gebaut hatten.

Q3. Auf der Verwahrseite zeigte sich ein ähnliches Muster. Sie entschieden sich 2017 für ein nicht-verwahrendes Modell, bevor Fireblocks als Produkt existierte. Was signalisierte, dass der damals übliche kommerzielle Standard — Verwahrung mit dahinterliegender Versicherung — der falsche Ansatz sein würde?

Mt. Gox war in der Branche noch sehr präsent, und Coincheck wurde Anfang 2018 um einen Gegenwert von etwa einer halben Milliarde Dollar gehackt. Die kommerzielle Antwort, auf die alle setzten, war eine Versicherung hinter verwahrter Speicherung: Schlüssel halten, Prämie zahlen und hoffen, dass nichts passiert. Dieser Ansatz hat einen grundlegenden Fehler. Versicherung repariert keinen Hack; sie monetarisiert ihn lediglich. Wenn die Kryptowährung eines Kunden gestohlen wird, hat der Kunde den Vermögenswert verloren, unabhängig davon, ob die Börse entschädigt wurde.

Also bauten wir die schwierigere Architektur. Auf jeder unterstützten Chain hielt die Plattform einen Signaturanteil und der Kunde den anderen; keine Partei konnte allein Mittel bewegen. Dieses Verwahrmodell wurde zudem optional angeboten — Kunden konnten ihre Kryptowährung in eigenen externen Wallets halten und direkt bei der Börse einzahlen oder von ihr abheben, wobei sie das gesamte Verwahrrisiko selbst trugen. Wäre unsere Datenbank kompromittiert worden, hätte ein Angreifer nur die Anteile der Plattform erhalten — keine Guthaben, keine Identitäten und keine Möglichkeit, Transaktionen zu signieren.

Was wir kombinierten, waren keine neuen kryptografischen Primitive; wir entschieden uns lediglich, sie 2017 in die Struktur eines regulierten Brokers zu integrieren, als die bequemere Option darin bestanden hätte, alle Schlüssel selbst zu behalten und eine Versicherungspolice zu kaufen.

Q4. eToro wählte bei Krypto den Derivateweg mit CFDs. Interactive Brokers entschied sich später für Futures. Sie setzten auf Spot — also den tatsächlichen Coin auf demselben Konto wie herkömmliche Wertpapiere. Was deutete darauf hin, dass Derivate nicht die Zukunft definieren würden?

Beide Alternativen waren kommerziell einfacher und regulatorisch leiser, und beide boten Kunden etwas, das wie Krypto-Exposure aussah, ohne ihnen den tatsächlichen Vermögenswert zu liefern. Ein CFD oder ein Futures-Kontrakt bildet Preisbewegungen ab. Er bringt keine Kryptowährung in den Besitz des Kunden. Wenn der Kunde den Coin anderswohin senden, ihn auf eine persönliche Wallet abheben oder außerhalb der Plattform nutzen möchte, kann ein Derivat das nicht ermöglichen. Man verkauft Exposure, nicht Eigentum.

Spot-Kryptowährung auf demselben Konto wie die regulierten Wertpapiere des Kunden gibt ihm den tatsächlichen Vermögenswert zusammen mit dem regulatorischen Rahmen der Gruppe. Das bedeutet nicht, dass die Kryptoseite selbst lizenziert war — 2017 gab es in keiner Jurisdiktion einen Rahmen dafür —, aber sie operierte innerhalb derselben Unternehmenseinheit wie ein regulierter Broker. Diese Kombination war selten, weil sie erforderte, das Verwahrproblem eigenständig zu lösen. Es war der einzige Ansatz, der Kryptowährung als echtes Finanzinstrument behandelte und nicht als synthetische Oberfläche, die auf einem solchen Instrument aufgesetzt ist.

Der europäische Regulierungsrahmen zog 2024 mit MiCA nach, und jeder Retail-Broker, der nach 2020 Spot-Krypto hinzufügte — Trade Republic in Deutschland, Robinhood in den Vereinigten Staaten und Revolut im Zuge seiner Einführung — gelangte zu demselben Integrationsmodell, das wir 2017 ausgeliefert hatten.

Q5. Einige dieser Entscheidungen sind inzwischen sieben oder acht Jahre alt. Was bestätigt, dass sie heute noch tragende Elemente sind und nicht nur historische Artefakte?

Sie sind tragende Elemente, und genau das ist der entscheidende Test. Eine gut konzipierte Architektur ist eine, zu der andere unabhängig konvergieren — nicht weil sie sie kopiert haben, sondern weil das zugrunde liegende Problem dieselbe Lösung erzwingt. Die von mir beschriebene Matching Engine läuft heute noch in Produktion. Vor dem Start durchlief sie mehr als zwei Jahre Betatests, und ein unabhängiges Market-Maker-Unternehmen führte externe Stresstests darauf durch. Wäre die Designwette falsch gewesen, hätten wir es inzwischen herausgefunden.

TCP/IP wurde in den 1970er-Jahren entwickelt und betreibt noch immer das Internet. SQL ist fünfzig Jahre alt und weiterhin dominant. Starke Architekturwetten wirken erst im Rückblick historisch. Was in das eingeflossen ist, was ich seit 2020 aufbaue, ist das Arbeitsprinzip hinter diesen Entscheidungen: Baue für den Standard, der kommt, nicht für den, der bequem ist. Die aktuelle Arbeit liegt im autonomen Business-to-Business-Commerce, und die regulatorische Diskussion in diesem Bereich entwickelt sich noch. Dieselbe Disziplin gilt weiterhin.

Q6. Wenn heute jemand an derselben Schnittstelle beginnen würde — regulierte Finanzwelt, echte Kryptowährung und maschinengesteuerter Orderflow —, welchen Rat würden Sie geben?

Drei Prinzipien, keines davon neu. Erstens: Machen Sie die Lizenzarchitektur zur primären Entscheidung — einen Compliance-Fehler im großen Maßstab kann man nicht wegkonstruieren, und die Zahl der Designentscheidungen, die sich aus der Lizenzstruktur ableiten, ist größer, als die meisten technischen Teams anfangs erkennen. Zweitens: Behandeln Sie Verwahrung als erstklassiges Architekturthema, nicht als Sicherheitszusatz — wenn Sie die Verwahrgrenze innerhalb Ihrer eigenen Systeme positionieren und sie einem Regulator präzise beschreiben können, vermeiden Sie eine Kategorie von Vorfällen, über die andere im nächsten Jahrzehnt vor Gericht streiten werden. Drittens: Diszipliniertes Engineering gewinnt den Durchsatzkampf. 2017 gab es viele Diskussionen über clevere Datenstrukturen und exotische Hardware, aber die Plattformen, die echte Leistungszahlen erreichten, waren diejenigen, die konsequent unspektakuläre Entscheidungen trafen. Das hat sich nicht geändert.