- 1. Q1. Your career has a specific pattern. Before either NAGA or the autonomous commerce company, most engineers around you would have needed a completely different set of numbers on their whiteboards. What do you look at when you are trying to figure out where a market will be five or seven years out?
- 2. Q2. Take one of those numbers. In 2017, the open-source matching engine reference was Liquibook, at roughly two to two-and-a-half million inserts per second. You built one at around eight million matches per second on synthetic tests. What told you the ceiling had to be that high?
- 3. Q3. Similar shape on the custody side. You went non-custodial in 2017, before Fireblocks existed as a product. What signalled that the commercial default — custodial storage with insurance behind it — would be the wrong answer?
- 4. Q4. eToro went the derivatives route with crypto CFDs. Interactive Brokers later chose futures. You committed to spot — the actual coin on the same account as conventional securities. What told you the derivative route would not be the future?
- 5. Q5. Some of those choices are seven or eight years old now. What tells you they are still load-bearing today rather than history?
- 6. Q6. If someone was starting today at the same intersection — regulated finance, real crypto, machine-driven flow — what would you tell them?
Igor Kulatov, former Co-Founder and CTO of NAGA Group AG, on the engineering decisions that made NAGA the benchmark for the market to follow
As co-founder and CTO of NAGA Group AG, Igor Kulatov built Swipestox – the social trading platform that carried the company to its Frankfurt Stock Exchange listing in July 2017. After the IPO he led the crypto build-out: matching engine, multi-chain custody architecture, and cross-asset venue integration, culminating in NAGA’s initial coin offering (the NGC token sale) the same year. He now runs Aurora Borealis, an autonomous business-to-business commerce company operating in production while the industry was still working out what to call the category. Both are true examples of building while most of the market either does not yet understand why, or is only watching for the right time to make their next move. We spoke about how he reads that direction, what forced the specific choices at NAGA, and what has carried into what he is building now.
Q1. Your career has a specific pattern. Before either NAGA or the autonomous commerce company, most engineers around you would have needed a completely different set of numbers on their whiteboards. What do you look at when you are trying to figure out where a market will be five or seven years out?
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 of the crypto platforms in 2016 and 2017 were built by teams who came at the problem from the other direction — from crypto out, not from exchange discipline in. So they were missing the things a mature exchange takes for granted: matching-engine performance for institutional flow, a custody boundary that a regulator can read on paper, a legal structure that can carry both an equity book and real crypto. 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 write everything fast and defer the hard parts. The coming standard was going to look a lot more like a regulated exchange. So I built to that.
Q2. Take one of those numbers. In 2017, the open-source matching engine reference was Liquibook, at roughly two to two-and-a-half million inserts per second. You built one at around eight million matches per second on synthetic tests. What told you the ceiling had to be that high?
That gap reads bigger than it is — Liquibook publishes insertion throughput, and matching is a heavier operation per event. The raw number was not what pushed the design. What pushed it was that we were building for a class of flow the crypto side had not seen yet. Institutional traders bring machines that never sleep. 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 small enough that a few thousand lines of your own code will outperform a library that has to stay safe for everyone. Binance rebuilt their matching engine in June 2020 — rewrote it from scratch on a new language, roughly two years of engineering work, about a ten-times performance gain. That kind of rebuild is not just development cost. It is two years during which the system runs under load it was not designed for — which means queuing at volatility peaks, delayed orders, flow that moves to whoever can carry it. The reason we did not have to do that in 2020 was that we had already built for that ceiling in 2017.
Q3. Similar shape on the custody side. You went non-custodial in 2017, before Fireblocks existed as a product. What signalled that the commercial default — custodial storage with insurance behind it — would be the wrong answer?
Mt. Gox was still fresh, Coincheck hit at the start of 2018 for the equivalent of about half a billion dollars, and the commercial fix everyone was reaching for was insurance behind custodial storage. Hold the keys, pay a premium, hope no one comes to collect. That has a problem. Insurance does not repair a hack; it only monetises it. If a customer’s crypto is gone the customer has lost the asset, even if the exchange has been paid. So we built the harder architecture — on each supported chain the platform held one signing share and the customer held the other, and neither side could move funds alone; and this custody model was itself an opt-in – customers could keep their crypto in their own external wallets and deposit or withdraw to the exchange directly, bearing all storage risk themselves. If our database had leaked, an attacker would have got the platform’s shares and nothing else – no balances, no identities, no way to sign. What we combined were not new primitives; we just chose to put them inside a regulated brokerage’s structure in 2017, when the more comfortable option was to hold every key ourselves and buy the policy.
Q4. eToro went the derivatives route with crypto CFDs. Interactive Brokers later chose futures. You committed to spot — the actual coin on the same account as conventional securities. What told you the derivative route would not be the future?
Both routes were commercially easier and regulatorily quieter, and both offered customers something that looked like crypto exposure without giving them the asset. A CFD or a futures contract tracks price movement. It does not put a cryptocurrency in a customer’s hands. If the customer wants to send the coin somewhere, withdraw it to a personal wallet, use it outside the platform — the derivative cannot do that. You are selling exposure, not ownership. Spot crypto on the same account as the customer’s regulated securities gives them the asset and the group’s regulatory regime around it. That is not a claim the crypto side was itself licensed — no jurisdiction had a framework for that in 2017 — but it operated inside the same corporate entity as a regulated brokerage. The combination was rare because it forced you to solve the custody problem yourself. It was the only route that treated crypto as a real financial instrument, not a synthetic surface built on one. The European framework caught up in 2024, with MiCA; and every retail broker that added spot crypto after 2020 (Trade Republic in Germany, Robinhood in the US, Revolut coming online) arrived at the same integration we shipped in 2017
Q5. Some of those choices are seven or eight years old now. What tells you they are still load-bearing today rather than history?
They are load-bearing, and that is the test. A well-designed architecture is one that others converge on independently — not because they copied it, but because the underlying problem forces the same answer. The matching engine I described is still running in production today. Before it launched, it went through more than two years of beta testing, and an independent market-maker firm ran external stress tests through it. If the bet had been wrong we would have discovered it by now. If the bet had been wrong we would have discovered it by now. TCP/IP was designed in the 1970s and still runs the internet. SQL is fifty years old and still dominant. Good architectural bets look historical only from a distance. What transferred into what I have been running since 2020 is the working assumption behind those choices: 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 there is still forming. Same discipline applies.
Q6. If someone was starting today at the same intersection — regulated finance, real crypto, machine-driven flow — what would you tell them?
Three things, none of them novel. Make the licensing architecture the primary decision — you will not out-engineer a compliance error at scale, and the number of design choices that flow from licence structure is larger than most technical teams appreciate at the start. Treat custody as a first-class architectural concern, not a security add-on — if you can put the custody boundary inside your own systems and describe it precisely to a regulator, you save yourself a class of incidents that other people will spend the next decade being sued over. And boring engineering wins the throughput fight. In 2017 there was a lot of noise around clever data structures and exotic hardware, but the platforms that got to real numbers were the ones making unglamorous decisions consistently. That has not changed.
