Igor Kulatov, ex cofundador y CTO de NAGA Group AG, analiza las decisiones de ingeniería que establecieron a NAGA como un referente para el mercado en general.

Como cofundador y CTO de NAGA Group AG, Igor Kulatov construyó Swipestox, la plataforma de trading social que impulsó a la compañía hacia su cotización en la Bolsa de Frankfurt en julio de 2017. Tras la IPO, lideró el desarrollo de criptomonedas de la firma —que incluyó un motor de emparejamiento personalizado, una arquitectura de custodia multichain y la integración de mercados entre distintos activos—, lo que culminó en la oferta inicial de monedas de NAGA, la venta del token NGC, ese mismo año. 2017 fue el año de mayor auge para las ICO a nivel global, con miles de millones recaudados en cientos de ventas de tokens, pero muy pocas compañías emisoras operaban dentro de una estructura de corretaje regulada y cotizada en bolsa. Kulatov ahora dirige Aurora Borealis, una compañía de comercio business-to-business autónomo que ha estado operando en producción mientras la industria en general todavía definía la categoría. Ambos proyectos ilustran un patrón de construcción por delante de la comprensión del mercado. En esta entrevista, Kulatov explica cómo interpreta la dirección del mercado, qué impulsó las decisiones específicas de ingeniería en NAGA y qué ha trasladado a su trabajo actual.

Q1. Tu carrera sigue un patrón distintivo. Antes de NAGA o de la compañía de comercio autónomo, la mayoría de los ingenieros a tu alrededor habría necesitado un conjunto de supuestos completamente distinto. ¿Qué observas cuando intentas determinar dónde estará un mercado en cinco o siete años?

No necesitaba predecir el futuro de las criptomonedas. Lo que tenía era una imagen operativa de cómo luce un exchange maduro: había construido sistemas de exchange antes de NAGA y sabía cuál era el estándar del lado tradicional. La mayoría de las plataformas cripto en 2016 y 2017 fueron construidas por equipos que abordaban el problema desde la dirección opuesta: desde cripto hacia afuera, no desde la disciplina de los exchanges hacia adentro. Como resultado, carecían de elementos que un exchange maduro da por sentados: rendimiento del motor de emparejamiento capaz de manejar flujo institucional, un límite de custodia que un regulador pueda evaluar claramente en papel y una estructura legal capaz de soportar tanto un libro de acciones como activos reales de criptomonedas.

Mi regla de trabajo era sencilla: construir para el estándar que viene, no para el que resulta conveniente ahora. En cripto en 2017, el estándar conveniente era construir todo rápido y postergar los problemas difíciles. El estándar que venía iba a parecerse mucho más a un exchange regulado. Así que construí para eso.

Q2. Consideremos uno de esos números. En 2017, la referencia de motor de emparejamiento open-source era Liquibook, con una capacidad de aproximadamente dos a dos millones y medio de inserciones por segundo. Tú construiste un motor que alcanzaba aproximadamente ocho millones de emparejamientos por segundo en pruebas sintéticas. ¿Qué indicaba que el techo debía ser tan alto?

Esa diferencia es menos significativa de lo que parece: Liquibook publica rendimiento de inserción, mientras que el emparejamiento es una operación más pesada por evento. El número bruto no fue lo que impulsó el diseño. Lo que lo impulsó fue que estábamos construyendo para una clase de flujo de órdenes que el lado cripto aún no había encontrado. Los traders institucionales despliegan máquinas que operan las 24 horas. La diferencia entre un techo de medio millón de emparejamientos por segundo y uno de ocho millones es la diferencia entre reconstruir tu motor en el tercer año y ejecutar el mismo en el octavo.

Así que lo controlamos de extremo a extremo. Un motor de emparejamiento es lo suficientemente compacto como para que unas pocas miles de líneas de código personalizado superen a una biblioteca de propósito general diseñada para mantenerse segura para todos los usuarios. Binance reconstruyó su motor de emparejamiento en junio de 2020: lo reescribió desde cero en un nuevo lenguaje, lo que representó aproximadamente dos años de trabajo de ingeniería y una mejora de rendimiento cercana a diez veces. Ese tipo de reconstrucción no es solo un gasto de desarrollo. Implica dos años durante los cuales el sistema opera bajo cargas para las que nunca fue diseñado, lo que resulta en colas durante picos de volatilidad, órdenes demoradas y flujo de órdenes que migra hacia el mercado que pueda manejarlo. La razón por la que no tuvimos que hacer eso en 2020 fue que ya habíamos construido para ese techo en 2017.

Q3. Surgió un patrón similar del lado de la custodia. Adoptaste un modelo no custodial en 2017, antes de que Fireblocks existiera como producto. ¿Qué señalaba que el estándar comercial predominante —almacenamiento custodial respaldado por seguro— sería el enfoque equivocado?

Mt. Gox seguía fresco en la memoria de la industria, y Coincheck fue hackeado a comienzos de 2018 por el equivalente a aproximadamente medio millardo de dólares. La solución comercial que todos perseguían era un seguro detrás del almacenamiento custodial: mantener las claves, pagar una prima y esperar que no ocurriera ningún incidente. Ese enfoque tiene una falla fundamental. El seguro no repara un hackeo; simplemente lo monetiza. Si la criptomoneda de un cliente es robada, el cliente perdió el activo, independientemente de si el exchange fue reembolsado.

Así que construimos la arquitectura más difícil. En cada chain soportada, la plataforma mantenía una participación de firma y el cliente mantenía la otra, y ninguna de las partes podía mover fondos unilateralmente. Este modelo de custodia se ofrecía a su vez como opt-in: los clientes podían conservar sus criptomonedas en sus propias wallets externas y depositar o retirar directamente hacia o desde el exchange, asumiendo ellos mismos todo el riesgo de almacenamiento. Si nuestra base de datos hubiera sido comprometida, un atacante habría obtenido únicamente las participaciones de la plataforma: sin saldos, sin identidades y sin capacidad de firmar transacciones.

Lo que combinamos no fueron primitivas criptográficas nuevas; simplemente decidimos integrarlas dentro de la estructura de un corretaje regulado en 2017, cuando la opción más cómoda era retener todas las claves nosotros mismos y comprar una póliza de seguro.

Q4. eToro siguió la ruta de los derivados con CFDs cripto. Interactive Brokers eligió futuros más tarde. Tú apostaste por spot: la moneda real mantenida en la misma cuenta que los valores convencionales. ¿Qué indicaba que la ruta de los derivados no definiría el futuro?

Ambas alternativas eran comercialmente más simples y atraían menos escrutinio regulatorio, y ambas ofrecían a los clientes algo que se parecía a exposición cripto sin entregar el activo real. Un CFD o un contrato de futuros sigue el movimiento del precio. No pone una criptomoneda en posesión del cliente. Si el cliente quiere enviar la moneda a otro lugar, retirarla a una wallet personal o usarla fuera de la plataforma, un instrumento derivado no puede facilitar eso. Estás vendiendo exposición, no propiedad.

La criptomoneda spot mantenida en la misma cuenta que los valores regulados del cliente le proporciona el activo real junto con el marco regulatorio del grupo. Esto no significa afirmar que el lado cripto estuviera licenciado en sí mismo —ninguna jurisdicción tenía un marco para eso en 2017—, pero operaba dentro de la misma entidad corporativa que un corretaje regulado. La combinación era poco común porque exigía resolver el problema de custodia de forma independiente. Era el único enfoque que trataba a la criptomoneda como un instrumento financiero genuino, no como una construcción sintética superpuesta sobre uno.

El marco regulatorio europeo se puso al día en 2024 con MiCA, y todos los brokers minoristas que añadieron cripto spot después de 2020 —Trade Republic en Alemania, Robinhood en Estados Unidos y Revolut cuando entró en línea— llegaron al mismo modelo de integración que nosotros lanzamos en 2017.

Q5. Algunas de esas decisiones ya tienen siete u ocho años. ¿Qué confirma que siguen siendo estructurales hoy y no simples artefactos históricos?

Siguen siendo estructurales, y esa es la prueba definitoria. Una arquitectura bien diseñada es aquella hacia la que otros convergen de forma independiente, no porque la hayan copiado, sino porque el problema subyacente exige la misma solución. El motor de emparejamiento que describí sigue operando en producción hoy. Antes del lanzamiento, pasó por más de dos años de pruebas beta, y una firma independiente de market-making realizó pruebas de estrés externas sobre él. Si la apuesta de diseño hubiera sido incorrecta, ya lo habríamos descubierto.

TCP/IP fue diseñado en la década de 1970 y todavía impulsa internet. SQL tiene cincuenta años y sigue siendo dominante. Las apuestas arquitectónicas sólidas solo parecen históricas en retrospectiva. Lo que se trasladó a lo que he estado construyendo desde 2020 es el principio operativo detrás de esas decisiones: construir para el estándar que viene, no para el que resulta conveniente. El trabajo actual está en el comercio business-to-business autónomo, y la conversación regulatoria en ese espacio aún se está desarrollando. Se aplica la misma disciplina.

Q6. Si alguien empezara hoy en la misma intersección —finanzas reguladas, criptomoneda real y flujo de órdenes impulsado por máquinas—, ¿qué orientación le ofrecerías?

Tres principios, ninguno de ellos novedoso. Primero, hacer de la arquitectura de licencias la decisión principal: no puedes compensar con ingeniería un error de cumplimiento a escala, y la cantidad de decisiones de diseño que se derivan de la estructura de licencias es mayor de lo que la mayoría de los equipos técnicos aprecia al principio. Segundo, tratar la custodia como una preocupación arquitectónica de primer orden, no como un complemento de seguridad: si puedes ubicar el límite de custodia dentro de tus propios sistemas y describirlo con precisión a un regulador, evitas una categoría de incidentes que otros pasarán la próxima década litigando. Tercero, la ingeniería disciplinada prevalece en la batalla por el rendimiento. En 2017 hubo mucha discusión en torno a estructuras de datos ingeniosas y hardware exótico, pero las plataformas que alcanzaron cifras de rendimiento genuinas fueron las que tomaron decisiones poco llamativas con consistencia. Eso no ha cambiado.