Igor Kulatov, former Co-Founder and CTO of NAGA Group AG, discusses the engineering decisions that established NAGA as a benchmark for the broader market.

As co-founder and CTO of NAGA Group AG, Igor Kulatov built Swipestox, the social trading platform that propelled the company to its Frankfurt Stock Exchange listing in July 2017. Following the IPO, he led the firm's cryptocurrency build-out — encompassing a custom matching engine, a multi-chain custody architecture, and cross-asset venue integration — which culminated in NAGA's initial coin offering, the NGC token sale, the same year. 2017 was the peak year for ICOs globally, with billions raised across hundreds of token sales, but very few issuing companies operated within a publicly listed, regulated brokerage structure. Kulatov now leads Aurora Borealis, an autonomous business-to-business commerce company that has been operating in production while the wider industry was still defining the category. Both ventures illustrate a pattern of building ahead of market understanding. In this interview, Kulatov discusses how he reads market direction, what drove the specific engineering choices at NAGA, and what has carried forward into his current work.

Q1. Your career follows a distinct pattern. Before either NAGA or the autonomous commerce company, most engineers around you would have needed an entirely different set of assumptions. What do you look at when trying to determine where a market will be in five or seven years?

I did not need to predict crypto's future. What I had was a working picture of what a mature exchange looks like — I had built exchange systems before NAGA, and I knew what the standard was on the traditional side. Most crypto platforms in 2016 and 2017 were built by teams approaching the problem from the opposite direction — from crypto outward, not from exchange discipline inward. As a result, they lacked elements that a mature exchange takes for granted: matching-engine performance capable of handling institutional flow, a custody boundary that a regulator can clearly evaluate on paper, and a legal structure capable of supporting both an equity book and actual cryptocurrency assets.

My working rule was straightforward: build for the standard that is coming, not the one that is convenient now. In crypto in 2017, the convenient standard was to build everything quickly and defer the hard problems. The coming standard was going to look far more like a regulated exchange. So I built to that.

Q2. Consider one of those numbers. In 2017, the open-source matching engine reference was Liquibook, rated at roughly two to two-and-a-half million inserts per second. You built an engine achieving approximately eight million matches per second on synthetic tests. What indicated the ceiling needed to be that high?

That gap is less significant than it appears — Liquibook publishes insertion throughput, while matching is a heavier operation per event. The raw number was not what drove the design. What drove it was that we were building for a class of order flow the crypto side had not yet encountered. Institutional traders deploy machines that operate around the clock. The difference between a ceiling of half a million matches per second and a ceiling of eight million is the difference between rebuilding your engine in year three and running the same one in year eight.

So we owned it end to end. A matching engine is compact enough that a few thousand lines of custom code will outperform a general-purpose library designed to remain safe for all users. Binance rebuilt their matching engine in June 2020 — rewriting it from scratch in a new language, representing roughly two years of engineering work and approximately a tenfold performance improvement. That kind of rebuild is not merely a development expense. It entails two years during which the system operates under loads it was never designed for — resulting in queueing during volatility spikes, delayed orders, and order flow migrating to whichever venue can handle it. The reason we did not need to do that in 2020 was that we had already built for that ceiling in 2017.

Q3. A similar pattern emerged on the custody side. You adopted a non-custodial model in 2017, before Fireblocks existed as a product. What signalled that the prevailing commercial default — custodial storage backed by insurance — would be the wrong approach?

Mt. Gox was still fresh in the industry's memory, and Coincheck was hacked at the start of 2018 for the equivalent of approximately half a billion dollars. The commercial remedy everyone pursued was insurance behind custodial storage: hold the keys, pay a premium, and hope no incident occurs. That approach has a fundamental flaw. Insurance does not repair a hack; it merely monetises it. If a customer's cryptocurrency is stolen, the customer has lost the asset, regardless of whether the exchange has been reimbursed.

So we built the harder architecture. On each supported chain, the platform held one signing share and the customer held the other, and neither party could move funds unilaterally. This custody model was itself offered as an opt-in — customers could retain their cryptocurrency in their own external wallets and deposit or withdraw to the exchange directly, bearing all storage risk themselves. If our database had been compromised, an attacker would have obtained only the platform's shares — no balances, no identities, and no ability to sign transactions.

What we combined were not new cryptographic primitives; we simply chose to integrate them within a regulated brokerage's structure in 2017, when the more comfortable option was to retain every key ourselves and purchase an insurance policy.

Q4. eToro pursued the derivatives route with crypto CFDs. Interactive Brokers later chose futures. You committed to spot — the actual coin held on the same account as conventional securities. What indicated that the derivatives route would not define the future?

Both alternatives were commercially simpler and attracted less regulatory scrutiny, and both offered customers something that resembled crypto exposure without delivering the actual asset. A CFD or a futures contract tracks price movement. It does not place a cryptocurrency in a customer's possession. If the customer wishes to send the coin elsewhere, withdraw it to a personal wallet, or use it outside the platform, a derivative instrument cannot facilitate that. You are selling exposure, not ownership.

Spot cryptocurrency held on the same account as the customer's regulated securities provides them with the actual asset alongside the group's regulatory framework. This is not to claim that the crypto side was itself licensed — no jurisdiction had a framework for that in 2017 — but it operated within the same corporate entity as a regulated brokerage. The combination was uncommon because it required solving the custody problem independently. It was the only approach that treated cryptocurrency as a genuine financial instrument rather than a synthetic construct layered on top of one.

The European regulatory framework caught up in 2024 with MiCA, and every retail broker that added spot crypto after 2020 — Trade Republic in Germany, Robinhood in the United States, and Revolut as it came online — arrived at the same integration model that we shipped in 2017.

Q5. Some of those decisions are now seven or eight years old. What confirms they remain load-bearing today rather than historical artefacts?

They are load-bearing, and that is the defining test. A well-designed architecture is one that others converge on independently — not because they copied it, but because the underlying problem demands the same solution. The matching engine I described is still operating in production today. Before launch, it underwent more than two years of beta testing, and an independent market-maker firm conducted external stress tests on it. If the design bet had been wrong, we would have discovered it by now.

TCP/IP was designed in the 1970s and still powers the internet. SQL is fifty years old and remains dominant. Strong architectural bets appear historical only in retrospect. What carried over into what I have been building since 2020 is the working principle behind those decisions: build for the standard that is coming, not the one that is convenient. The current work is in autonomous business-to-business commerce, and the regulatory conversation in that space is still developing. The same discipline applies.

Q6. If someone were starting today at the same intersection — regulated finance, real cryptocurrency, and machine-driven order flow — what guidance would you offer?

Three principles, none of them novel. First, make the licensing architecture the primary decision — you cannot out-engineer a compliance error at scale, and the number of design choices that derive from licence structure is greater than most technical teams initially appreciate. Second, treat custody as a first-class architectural concern, not a security add-on — if you can position the custody boundary within your own systems and describe it precisely to a regulator, you avoid a category of incidents that others will spend the next decade litigating. Third, disciplined engineering prevails in the throughput battle. In 2017 there was considerable discussion around clever data structures and exotic hardware, but the platforms that reached genuine performance numbers were the ones making unglamorous decisions with consistency. That has not changed.