- 1. Q1. When you look back at NAGA now, were you actually trying to predict where crypto was going, or were you thinking more about which compromises would stop making sense as the market matured?
- 2. Q2. You mentioned institutional flow. The matching engine is probably the clearest place where that decision became measurable. At the time, 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 it needed that much headroom?
- 3. Q3. That is one version of the trade-off: more work up front rather than rebuilding under load later. Custody seems to have involved a different one. You went non-custodial 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. And the decision to offer spot crypto seems connected to that. 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 was the limitation you saw in the derivative route?
- 5. Q5. Looking at those choices now, a lot of them were harder than the available alternative. What tells you they were solving the right problem rather than simply over-engineering it?
- 6. Q6. Listening to you describe them, the common thread sounds less crypto-specific than architectural: you were often unwilling to accept the obvious trade-off. What carried from that into Aurora?
- 7. Q7. One last question. If someone were 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 matching engines, custody and the engineering trade-offs that only become clear with time
Nearly a decade later, some engineering decisions are easier to judge by what survived than by how novel they looked at the time. Igor Kulatov was Co-Founder and CTO of NAGA Group AG during that period, where he led work across trading infrastructure, custody and crypto integration. He now runs Aurora Borealis, a deep-tech company building autonomous B2B commerce infrastructure in what is now commonly described as agentic commerce. Looking back, one pattern is hard to miss: many of the hardest choices were really trade-offs between what was easier to ship and what the system would eventually need to withstand. We spoke about which of those choices aged well, which compromises turned out not to be necessary, and what carried into the work he is doing now.
Q1. When you look back at NAGA now, were you actually trying to predict where crypto was going, or were you thinking more about which compromises would stop making sense as the market matured?
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 mature infrastructure looked like 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 option was to write everything fast and defer the hard parts. The standard I expected to emerge was going to look a lot more like a regulated exchange. So I built to that.
Q2. You mentioned institutional flow. The matching engine is probably the clearest place where that decision became measurable. At the time, 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 it needed that much headroom?
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 half a million matches per second and 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 level of headroom in 2017.
Q3. That is one version of the trade-off: more work up front rather than rebuilding under load later. Custody seems to have involved a different one. You went non-custodial 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, they have 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. The custody model itself was 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. And the decision to offer spot crypto seems connected to that. 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 was the limitation you saw in the derivative route?
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. Looking at those choices now, a lot of them were harder than the available alternative. What tells you they were solving the right problem rather than simply over-engineering it?
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. 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.
Q6. Listening to you describe them, the common thread sounds less crypto-specific than architectural: you were often unwilling to accept the obvious trade-off. What carried from that into Aurora?
What carried into the work I have been doing 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.
Q7. One last question. If someone were 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.
