Igor Kulatov, ex Co-Founder e CTO di NAGA Group AG, discute le decisioni ingegneristiche che hanno affermato NAGA come riferimento per il mercato più ampio.

In qualità di co-fondatore e CTO di NAGA Group AG, Igor Kulatov ha costruito Swipestox, la piattaforma di social trading che ha portato la società alla quotazione alla Borsa di Francoforte nel luglio 2017. Dopo l’IPO, ha guidato lo sviluppo dell’infrastruttura crypto dell’azienda — comprendente un matching engine proprietario, un’architettura di custodia multi-chain e l’integrazione di sedi di negoziazione cross-asset — culminato nello stesso anno nell’initial coin offering di NAGA, la vendita del token NGC. Il 2017 è stato l’anno di picco per le ICO a livello globale, con miliardi raccolti attraverso centinaia di vendite di token, ma pochissime società emittenti operavano all’interno di una struttura di brokeraggio regolamentata e quotata in borsa. Kulatov oggi guida Aurora Borealis, una società di commercio business-to-business autonomo già operativa in produzione mentre il settore più ampio stava ancora definendo la categoria. Entrambe le iniziative mostrano un modello di costruzione in anticipo rispetto alla comprensione del mercato. In questa intervista, Kulatov spiega come interpreta la direzione del mercato, quali fattori hanno guidato le specifiche scelte ingegneristiche di NAGA e che cosa ha trasferito nel suo lavoro attuale.

Q1. La sua carriera segue uno schema distinto. Prima di NAGA o della società di commercio autonomo, la maggior parte degli ingegneri intorno a lei avrebbe avuto bisogno di un insieme di ipotesi completamente diverso. Che cosa osserva quando cerca di determinare dove sarà un mercato tra cinque o sette anni?

Non avevo bisogno di prevedere il futuro delle crypto. Avevo un’immagine operativa di come appare una borsa matura: avevo costruito sistemi di exchange prima di NAGA e sapevo quale fosse lo standard nel mondo tradizionale. La maggior parte delle piattaforme crypto nel 2016 e nel 2017 era costruita da team che affrontavano il problema dalla direzione opposta: partendo dalle crypto verso l’esterno, non dalla disciplina degli exchange verso l’interno. Di conseguenza, mancavano elementi che una borsa matura dà per scontati: prestazioni del matching engine in grado di gestire flussi istituzionali, un perimetro di custodia che un regolatore possa valutare chiaramente su carta e una struttura legale capace di supportare sia un book azionario sia asset reali in criptovaluta.

La mia regola operativa era semplice: costruire per lo standard che sta arrivando, non per quello che oggi è più comodo. Nel settore crypto nel 2017, lo standard comodo era costruire tutto rapidamente e rinviare i problemi difficili. Lo standard in arrivo avrebbe assomigliato molto di più a un exchange regolamentato. Quindi ho costruito in quella direzione.

Q2. Prendiamo uno di quei numeri. Nel 2017, il riferimento open source per i matching engine era Liquibook, valutato a circa due-due milioni e mezzo di inserimenti al secondo. Lei ha costruito un motore che nei test sintetici raggiungeva circa otto milioni di abbinamenti al secondo. Che cosa indicava che il limite dovesse essere così alto?

Quel divario è meno significativo di quanto sembri: Liquibook pubblica il throughput di inserimento, mentre il matching è un’operazione più pesante per evento. Il numero grezzo non è stato ciò che ha guidato il design. A guidarlo è stato il fatto che stavamo costruendo per una classe di flussi d’ordine che il lato crypto non aveva ancora incontrato. I trader istituzionali impiegano macchine che operano 24 ore su 24. La differenza tra un limite di mezzo milione di abbinamenti al secondo e un limite di otto milioni è la differenza tra dover ricostruire il proprio motore al terzo anno e poter usare lo stesso all’ottavo.

Per questo lo abbiamo controllato end to end. Un matching engine è abbastanza compatto perché poche migliaia di righe di codice personalizzato superino le prestazioni di una libreria general-purpose progettata per restare sicura per tutti gli utenti. Binance ha ricostruito il proprio matching engine nel giugno 2020, riscrivendolo da zero in un nuovo linguaggio, con circa due anni di lavoro ingegneristico e un miglioramento delle prestazioni di circa dieci volte. Una ricostruzione di quel tipo non è solo una spesa di sviluppo. Implica due anni durante i quali il sistema opera sotto carichi per cui non era stato progettato, con code durante i picchi di volatilità, ordini ritardati e flussi d’ordine che migrano verso la sede capace di gestirli. Il motivo per cui nel 2020 non abbiamo dovuto farlo è che nel 2017 avevamo già costruito per quel limite.

Q3. Un modello simile è emerso sul lato della custodia. Avete adottato un modello non-custodial nel 2017, prima che Fireblocks esistesse come prodotto. Che cosa indicava che l’impostazione commerciale prevalente — custodia centralizzata sostenuta da assicurazione — sarebbe stata l’approccio sbagliato?

Mt. Gox era ancora fresco nella memoria del settore e Coincheck fu violata all’inizio del 2018 per l’equivalente di circa mezzo miliardo di dollari. Il rimedio commerciale perseguito da tutti era l’assicurazione dietro la custodia centralizzata: detenere le chiavi, pagare un premio e sperare che non si verifichi alcun incidente. Questo approccio ha un difetto fondamentale. L’assicurazione non ripara un hack; lo monetizza soltanto. Se la criptovaluta di un cliente viene rubata, il cliente ha perso l’asset, indipendentemente dal fatto che l’exchange sia stato rimborsato.

Così abbiamo costruito l’architettura più difficile. Su ogni chain supportata, la piattaforma deteneva una quota di firma e il cliente deteneva l’altra, e nessuna delle due parti poteva spostare fondi unilateralmente. Questo modello di custodia era offerto come opzione opt-in: i clienti potevano mantenere le proprie criptovalute nei loro wallet esterni e depositare o prelevare direttamente dall’exchange, assumendosi interamente il rischio di conservazione. Se il nostro database fosse stato compromesso, un attaccante avrebbe ottenuto solo le quote della piattaforma: nessun saldo, nessuna identità e nessuna capacità di firmare transazioni.

Ciò che abbiamo combinato non erano primitive crittografiche nuove; abbiamo semplicemente scelto di integrarle nel 2017 all’interno della struttura di un brokeraggio regolamentato, quando l’opzione più comoda sarebbe stata conservare noi stessi ogni chiave e acquistare una polizza assicurativa.

Q4. eToro ha seguito la strada dei derivati con i CFD crypto. Interactive Brokers ha poi scelto i futures. Lei ha puntato sullo spot: la moneta effettiva detenuta sullo stesso conto dei titoli convenzionali. Che cosa indicava che la strada dei derivati non avrebbe definito il futuro?

Entrambe le alternative erano commercialmente più semplici e attiravano meno scrutinio regolamentare, e offrivano ai clienti qualcosa che assomigliava all’esposizione crypto senza consegnare l’asset effettivo. Un CFD o un contratto futures replica il movimento del prezzo. Non mette una criptovaluta in possesso del cliente. Se il cliente desidera inviare la moneta altrove, prelevarla su un wallet personale o utilizzarla fuori dalla piattaforma, uno strumento derivato non può permetterlo. Si vende esposizione, non proprietà.

La criptovaluta spot detenuta sullo stesso conto dei titoli regolamentati del cliente fornisce l’asset effettivo insieme al quadro regolamentare del gruppo. Questo non significa sostenere che il lato crypto fosse di per sé autorizzato — nel 2017 nessuna giurisdizione disponeva di un quadro per questo — ma operava all’interno della stessa entità societaria di un brokeraggio regolamentato. La combinazione era rara perché richiedeva di risolvere autonomamente il problema della custodia. Era l’unico approccio che trattava la criptovaluta come un vero strumento finanziario, anziché come una costruzione sintetica stratificata sopra uno strumento.

Il quadro regolamentare europeo si è allineato nel 2024 con MiCA, e ogni broker retail che ha aggiunto crypto spot dopo il 2020 — Trade Republic in Germania, Robinhood negli Stati Uniti e Revolut quando è arrivata online — è giunto allo stesso modello di integrazione che noi avevamo lanciato nel 2017.

Q5. Alcune di quelle decisioni hanno ormai sette o otto anni. Che cosa conferma che siano ancora portanti oggi e non semplici artefatti storici?

Sono portanti, ed è questo il test decisivo. Un’architettura ben progettata è quella verso cui altri convergono in modo indipendente, non perché l’abbiano copiata, ma perché il problema sottostante richiede la stessa soluzione. Il matching engine che ho descritto è ancora oggi operativo in produzione. Prima del lancio, ha attraversato più di due anni di beta testing, e una società indipendente di market making ha condotto stress test esterni su di esso. Se la scommessa progettuale fosse stata sbagliata, lo avremmo già scoperto.

TCP/IP è stato progettato negli anni 1970 e ancora alimenta Internet. SQL ha cinquant’anni e rimane dominante. Le scommesse architetturali solide appaiono storiche solo a posteriori. Ciò che ho trasferito in quello che costruisco dal 2020 è il principio operativo alla base di quelle decisioni: costruire per lo standard che sta arrivando, non per quello che è comodo. Il lavoro attuale riguarda il commercio business-to-business autonomo, e la conversazione regolamentare in quello spazio è ancora in evoluzione. Si applica la stessa disciplina.

Q6. Se qualcuno iniziasse oggi nello stesso punto di intersezione — finanza regolamentata, criptovaluta reale e flusso d’ordini guidato da macchine — quale indicazione offrirebbe?

Tre principi, nessuno dei quali nuovo. Primo, rendere l’architettura delle licenze la decisione primaria: non si può compensare con l’ingegneria un errore di compliance su scala, e il numero di scelte di progettazione che derivano dalla struttura delle licenze è maggiore di quanto la maggior parte dei team tecnici comprenda inizialmente. Secondo, trattare la custodia come una questione architetturale di primo livello, non come un’aggiunta di sicurezza: se si può collocare il perimetro di custodia all’interno dei propri sistemi e descriverlo con precisione a un regolatore, si evita una categoria di incidenti che altri passeranno il prossimo decennio a gestire in tribunale. Terzo, l’ingegneria disciplinata prevale nella battaglia del throughput. Nel 2017 si discuteva molto di strutture dati ingegnose e hardware esotico, ma le piattaforme che hanno raggiunto numeri di prestazione reali sono state quelle che hanno preso decisioni poco appariscenti con coerenza. Questo non è cambiato.