La mayoría de los artículos «cómo construir un exchange de cripto» los escriben personas que nunca han operado uno. Enumeran funciones, dan un precio y se detienen. Esta guía es distinta: se organiza alrededor de las decisiones que de verdad determinan si un exchange se lanza a tiempo, sobrevive a su primer incidente y supera la due diligence de los socios bancarios y de cumplimiento normativo. Los ejemplos salen de nuestro trabajo en BitXChange, un exchange cripto a cripto con un catálogo amplio de pares y back offices separados para administradores, propietarios y socios.
Decida qué tipo de exchange va a construir
«Exchange de cripto» cubre al menos cuatro productos distintos, con perfiles de riesgo diferentes:
| Modelo | Qué es | Lo más difícil |
|---|---|---|
| Spot centralizado (CEX) | Usted custodia los fondos de los usuarios y opera un libro de órdenes | Custodia, matching, cumplimiento normativo |
| Solo cripto a cripto | CEX sin on-ramps ni off-ramps de fiat | Liquidez, operaciones de listado |
| Bróker / swap instantáneo | Cotizaciones de un proveedor de liquidez, sin libro de órdenes | Precio, cobertura, deslizamiento |
| Frontend de DEX | UI sobre protocolos on-chain, sin custodia | UX de wallets, MEV, fiabilidad de RPC |
La elección condiciona todo lo que viene después. Un CEX solo cripto, como BitXChange, evita las integraciones bancarias y los procesadores de tarjetas, y eso quita meses del plan de cumplimiento normativo, pero sigue necesitando custodia, un motor de matching y una operación de listados. Un modelo de bróker permite lanzar en semanas con un único proveedor de liquidez, pero limita el margen. Un frontend de DEX tiene la carga de cumplimiento normativo más ligera y el menor control sobre la experiencia de trading.
Si no ha tomado esta decisión de forma explícita, tómela antes que nada. Todo lo que sigue asume un exchange centralizado, que es lo que la mayoría de los fundadores tiene en mente cuando nos pide una estimación.
Los componentes principales
Un CEX de producción tiene siete subsistemas. Puede comprar unos, construir otros y aplazar otros, pero todos existen desde el primer día, los haya planificado o no.
1. Cuentas, KYC y permisos
Registro de usuarios, autenticación de dos factores, gestión de sesiones, seguimiento de dispositivos y claves de API. El KYC suele delegarse en un proveedor (Sumsub, Onfido, Veriff y otros) mediante un flujo de webhooks: el usuario completa la verificación en el widget del proveedor, el proveedor llama a su backend y el backend cambia el nivel de la cuenta y los límites asociados. Modele los niveles y los límites como datos desde el inicio; los va a cambiar más a menudo de lo que espera.
2. Libro mayor
El libro mayor es el corazón del exchange y la parte que la mayoría de los equipos subestima. Cada cambio de saldo — depósito, operación, comisión, retiro, ajuste — tiene que ser una transacción de partida doble que referencia su origen. El libro mayor debe ser de solo adición, idempotente y conciliable con los saldos on-chain y con el estado del motor de matching.
Dos reglas que no rompemos:
- Los saldos se derivan de los asientos del libro mayor; nunca se actualizan en el sitio sin el asiento correspondiente.
- Todo evento externo (un depósito confirmado, una orden ejecutada) lleva una clave de idempotencia, para que un webhook reintentado o un mensaje reproducido no pueda acreditar al usuario dos veces.
3. Motor de matching
El motor de matching toma órdenes y produce operaciones. Para un lanzamiento con un conjunto seleccionado de pares, un libro de órdenes en memoria, de un solo proceso y por mercado, con un registro de eventos persistente, es lo bastante rápido y mucho más fácil de razonar que un diseño distribuido. Prioridad precio-tiempo, órdenes límite y de mercado, cancelaciones y un número de secuencia en cada evento bastan para empezar. Las ejecuciones parciales, las órdenes post-only, las órdenes stop y la prevención de autooperaciones llegan después, cuando hay volumen real.
Diseñe el motor como una función pura sobre un flujo de eventos: ante las mismas entradas, produce el mismo libro y las mismas operaciones. Eso lo hace testeable, reproducible tras una caída y auditable cuando un usuario disputa una ejecución.
4. Datos de mercado
Snapshots y deltas del libro de órdenes, ticks de operaciones, velas y tickers, distribuidos al navegador por WebSockets. El patrón que nos funcionó: el motor publica eventos en un bus de mensajes, un servicio de datos de mercado mantiene el estado de cada mercado y lo reparte a los clientes, y el frontend guarda un almacén local y normalizado, de modo que cada widget — libro, gráfico, operaciones recientes, órdenes abiertas — se renderiza desde una única fuente de verdad. El lado de frontend lo describimos con detalle en el caso de estudio de TradeBot.
5. Wallets y custodia
Los depósitos exigen generación de direcciones por usuario y por activo, seguimiento de confirmaciones con reglas de finalidad propias de cada cadena, y manejo de reorgs. Los retiros exigen firma desde la hot wallet con límites, almacenamiento en frío para la mayor parte de los fondos, controles de velocidad y una cola de aprobación manual por encima de un umbral.
Las opciones van desde montar la infraestructura de nodos por su cuenta hasta usar un proveedor de custodia (Fireblocks, BitGo, Copper). Para un primer lanzamiento, un proveedor de custodia es casi siempre la decisión acertada: acorta el plan en meses y ofrece a los socios de cumplimiento normativo algo que ya reconocen. Construya la propia solo cuando las comisiones o el control justifiquen la carga de operarla.
6. Back offices
Los operadores necesitan herramientas desde el primer día: listados y configuración de pares, esquemas de comisiones, gestión de usuarios y límites, aprobaciones de retiros, controles de incidentes (detener un mercado, congelar una cuenta) y reportes. En BitXChange construimos tres back offices separados, con conjuntos de permisos distintos — administradores, propietarios y socios — porque quien gestiona los listados no es quien debe ver los datos personales de los usuarios ni aprobar retiros. El acceso por roles y un registro de auditoría en cada acción no se negocian.
7. Frontend de trading
Los usuarios le juzgan por la interfaz de trading, y además es un problema de ingeniería difícil: actualizaciones de mercado continuas, información densa, entrada de órdenes con el teclado y tolerancia cero a los datos desactualizados. Esta capa la construimos en Next.js y TypeScript, con un almacén en tiempo real que alimenta widgets independientes. El renderizado en servidor mantiene rápidas e indexables las páginas de marketing y de cuenta; la pantalla de trading es una aplicación de cliente.
Cumplimiento normativo: lo que de verdad hace falta
El cumplimiento normativo es donde se atascan los proyectos de exchange, casi siempre porque los fundadores lo ignoran o intentan resolverlo todo antes del lanzamiento. El mínimo práctico para un exchange centralizado:
- Licencia o registro en la jurisdicción en la que opera. Los requisitos varían mucho (MiCA en la UE, registro de VASP en Lituania y Polonia, VARA en Dubái, licencias estatales de transmisor de dinero en EE. UU.). Decida la jurisdicción antes que la arquitectura, porque de ella salen la residencia de los datos y los requisitos de reporte.
- Programa de KYC/AML: niveles de verificación de identidad, comprobación de sanciones y de PEP, monitoreo de transacciones con puntuación de riesgo, reporte de actividad sospechosa y conservación de registros. Casi todo esto lo entregan proveedores; su sistema tiene que guardar la evidencia y actuar en función de los resultados.
- Travel Rule para las transferencias por encima de los umbrales, implementada mediante un proveedor o un protocolo (Notabene, Sumsub Travel Rule, TRP).
- Registro de auditoría de cada cambio de saldo y de cada acción administrativa, con una retención que se mide en años.
- Términos, privacidad y avisos de riesgo redactados por un abogado que conozca los activos digitales.
Somos ingenieros, no abogados. Lo que hacemos es traducir el programa de cumplimiento normativo a controles técnicos: modelos de datos para niveles y límites, flujos de webhooks para el KYC, puntos de monitoreo para el cribado de transacciones, registros inmutables y reportes exportables. Incluya en el presupuesto a un asesor de cumplimiento normativo desde el principio; sale más barato que rehacerlo a posteriori.
Seguridad: lo que no se negocia
A los exchanges los atacan de forma continua desde el día en que aparecen en un explorador de bloques. La base:
- Separación de wallets hot/cold, con límites estrictos en la hot wallet y multifirma o MPC para el almacenamiento en frío.
- Controles de retiro: listas blancas de direcciones, confirmación por 2FA, bloqueos temporales tras cambios de seguridad, límites de velocidad y revisión manual por encima de los umbrales.
- Infraestructura de mínimo privilegio, secretos en una bóveda, sin credenciales compartidas, y claves de firma que nunca tocan los servidores de la aplicación.
- Limitación de tasa y anti-automatización en los endpoints de autenticación y de trading.
- Análisis de dependencias, revisión de código obligatoria y un runbook de incidentes ensayado.
- Una prueba de penetración externa antes del lanzamiento y después de los cambios importantes.
Nada de esto es exótico. Lo que importa es que esté diseñado de entrada, no añadido después del primer incidente.
Equipo, plazo y presupuesto
Para un MVP de CEX cripto a cripto — trading spot en un conjunto seleccionado de pares, custodia a través de un proveedor, KYC mediante un proveedor, back office de administración e interfaz de trading web — un plan realista es:
- Equipo: un líder técnico, dos ingenieros de backend, uno o dos ingenieros de frontend, un ingeniero de QA, un diseñador a tiempo parcial y un responsable de proyecto a tiempo parcial. De cinco a siete personas.
- Plazo: de cuatro a seis meses hasta un lanzamiento público controlado, con trading interno en testnets al tercer mes.
- Presupuesto: un primer hito en el rango de 40–80k USD para un alcance enfocado, con proveedores de custodia y de KYC; 150–300k USD para una plataforma con varios back offices, productos con margen o custodia propia. Los costos continuos incluyen las comisiones de los proveedores, la infraestructura, las revisiones de seguridad y una rotación de soporte.
Un producto de bróker o de swap instantáneo puede lanzarse en seis a diez semanas y con una fracción del presupuesto; un frontend de DEX se sitúa en un rango parecido. Los proyectos de CEX cuestan más por el libro mayor, la custodia y las operaciones, no por la UI.
Lecciones de BitXChange
Tres cosas que diríamos a quien empiece un exchange hoy:
Separe los listados de las releases. Los operadores tienen que poder añadir un par, fijar sus comisiones y sus límites, y abrirlo al trading sin un despliegue de ingeniería. La configuración de pares la construimos como datos, con una activación por etapas (oculto, solo lectura, en vivo), y eso quitó la mayor fuente de fricción entre el negocio y el equipo de ingeniería.
Construya los back offices pronto. Tienta lanzar primero la UI de trading y llevar las operaciones con consultas a la base de datos. Todo exchange que lo hace se arrepiente la primera vez que alguien aprueba el retiro que no era, a las 3 de la madrugada. Los back offices por roles, con registros de auditoría, forman parte del MVP.
Trate los datos de mercado como un producto. Los usuarios perdonan una página de ajustes lenta; no perdonan un libro de órdenes desactualizado. Un camino propio para los datos de mercado — del motor al bus, de ahí al servicio que los reparte y de ahí al almacén normalizado del cliente — es lo que mantiene la interfaz fiable cuando hay carga.