De la tormenta de liquidaciones a la caída de la nube: el momento de crisis para la infraestructura cripto

Título original: Crypto Infrastructure is Far From Perfect

Autor original: YQ, KOL cripto

Traducción original: AididiaoJP, Foresight News

Amazon Web Services sufrió nuevamente una interrupción importante, afectando gravemente la infraestructura cripto. Los problemas de AWS en la región Este de EE.UU. (centro de datos de Virginia del Norte) provocaron la caída de Coinbase y de decenas de otras plataformas cripto principales, incluyendo Robinhood, Infura, Base y Solana.

AWS reconoció un “aumento en la tasa de errores” que afectó a Amazon DynamoDB y EC2, servicios centrales de bases de datos y cómputo de los que dependen miles de empresas. Esta interrupción proporciona una validación inmediata y vívida del argumento central de este artículo: la dependencia de la infraestructura cripto en proveedores de servicios en la nube centralizados crea vulnerabilidades sistémicas que se manifiestan repetidamente bajo presión.

El momento es revelador. Apenas diez días después de que un evento de liquidaciones en cadena por 1.9 billones de dólares expusiera fallas de infraestructura a nivel de plataformas de trading, la interrupción de AWS de hoy demuestra que el problema va más allá de una sola plataforma y se extiende a la capa fundamental de infraestructura en la nube. Cuando AWS falla, el impacto en cascada afecta simultáneamente a exchanges centralizados, plataformas “descentralizadas” con dependencias centralizadas y a innumerables otros servicios.

No se trata de un incidente aislado, sino de un patrón. El siguiente análisis documenta interrupciones similares de AWS ocurridas en abril de 2025, diciembre de 2021 y marzo de 2017, cada una de las cuales provocó la caída de servicios cripto clave. La cuestión no es si ocurrirá la próxima falla de infraestructura, sino cuándo y qué la desencadenará.

Evento de liquidaciones en cadena del 10-11 de octubre de 2025: Estudio de caso

El evento de liquidaciones en cadena del 10-11 de octubre de 2025 proporciona un estudio de caso revelador sobre el patrón de fallas de infraestructura. A las 20:00 UTC, un anuncio geopolítico importante desencadenó una venta masiva en todo el mercado. En una hora, se liquidaron 6 mil millones de dólares. Para la apertura del mercado asiático, 19.3 billones de dólares en posiciones apalancadas de 1.6 millones de cuentas de traders habían desaparecido.

Figura 1: Cronología del evento de liquidaciones en cadena de octubre de 2025

Esta línea de tiempo interactiva muestra el dramático progreso de las liquidaciones por hora. Solo en la primera hora se evaporaron 6 mil millones de dólares, seguido de una aceleración aún mayor en la segunda hora. La visualización muestra:

· 20:00-21:00: Impacto inicial - 6 mil millones de dólares liquidados (zona roja)

· 21:00-22:00: Pico en cadena - 4.2 mil millones de dólares, momento en que las APIs comienzan a limitar el tráfico

· 22:00-04:00: Deterioro sostenido - 9.1 mil millones de dólares liquidados en un mercado de baja liquidez

· Punto de inflexión clave: limitación de velocidad de API, retiro de market makers, libros de órdenes más delgados

La magnitud fue al menos un orden de magnitud mayor que cualquier evento previo en el mercado cripto; la comparación histórica muestra la naturaleza escalonada de este evento:

Figura 2: Comparación de eventos históricos de liquidación

El gráfico de barras ilustra dramáticamente la prominencia del evento de octubre de 2025:

· Marzo de 2020 (COVID): 1.2 mil millones de dólares

· Mayo de 2021 (caída): 1.6 mil millones de dólares

· Noviembre de 2022 (FTX): 1.6 mil millones de dólares

· Octubre de 2025: 19.3 billones de dólares, 16 veces el récord anterior

Pero las cifras de liquidación solo cuentan parte de la historia. La pregunta más interesante es sobre el mecanismo: ¿cómo desencadenó un evento externo del mercado este patrón específico de fallas? La respuesta revela debilidades sistémicas en la infraestructura de exchanges centralizados y en el diseño de protocolos blockchain.

Fallas off-chain: Arquitectura de exchanges centralizados

Sobrecarga de infraestructura y limitación de velocidad

Los exchanges implementan limitaciones de velocidad en sus APIs para prevenir abusos y gestionar la carga de los servidores. Durante operaciones normales, estos límites permiten el trading legítimo y bloquean ataques potenciales. Pero durante volatilidad extrema, cuando miles de traders intentan ajustar posiciones simultáneamente, estos mismos límites se convierten en cuellos de botella.

Los CEX limitan las notificaciones de liquidación a una orden por segundo, incluso cuando procesan miles de órdenes por segundo. Durante el evento en cadena de octubre, esto generó opacidad. Los usuarios no podían determinar la gravedad en tiempo real. Herramientas de monitoreo de terceros mostraban cientos de liquidaciones por minuto, mientras que los datos oficiales reportaban mucho menos.

La limitación de velocidad de API impidió que los traders modificaran posiciones en la primera hora crítica; las solicitudes de conexión expiraban, las órdenes fallaban al enviarse. Las órdenes stop-loss no se ejecutaron, las consultas de posiciones devolvían datos desactualizados; este cuello de botella de infraestructura convirtió un evento de mercado en una crisis operativa.

Los exchanges tradicionales configuran la infraestructura para la carga normal más un margen de seguridad. Pero la carga normal y la carga bajo presión son muy diferentes; el volumen diario promedio no predice bien la demanda máxima. Durante el evento en cadena, el volumen de trading se multiplicó por 100 o más, y las consultas de datos de posiciones por 1,000, ya que cada usuario revisaba su cuenta simultáneamente.

Figura 4.5: Interrupción de AWS que afecta servicios cripto

La infraestructura en la nube con autoescalado ayuda, pero no responde al instante; iniciar réplicas adicionales de bases de datos toma minutos. Crear nuevas instancias de API Gateway también toma minutos. En esos minutos, el sistema de márgenes sigue marcando el valor de las posiciones con datos de precios dañados de libros de órdenes sobrecargados.

Manipulación de oráculos y vulnerabilidades de precios

Durante el evento en cadena de octubre, una decisión clave de diseño en los sistemas de márgenes se hizo evidente: algunos exchanges calculan el valor colateral usando precios internos de mercado spot en lugar de flujos de datos de oráculos externos. En condiciones normales, los arbitrajistas mantienen la coherencia de precios entre mercados. Pero bajo presión de infraestructura, este acoplamiento colapsa.

Figura 3: Diagrama de flujo de manipulación de oráculos

Este diagrama de flujo interactivo visualiza cinco etapas del vector de ataque:

· Venta inicial: presión de venta de 60 millones de dólares sobre USDe

· Manipulación de precios: USDe cae de 1.00 a 0.65 dólares en un solo exchange

· Falla del oráculo: el sistema de márgenes usa datos internos dañados

· Disparo en cadena: el colateral se devalúa, comienzan las liquidaciones forzadas

· Amplificación: 19.3 billones de dólares en liquidaciones (amplificación de 322x)

El ataque explotó el uso de precios spot para colaterales sintéticos envueltos en Binance. Cuando el atacante vendió 60 millones de dólares en USDe en un libro de órdenes relativamente ilíquido, el precio spot cayó de 1.00 a 0.65 dólares. El sistema de márgenes, configurado para marcar colaterales según el precio spot, revaluó a la baja todas las posiciones colateralizadas con USDe en un 35%. Esto disparó llamadas de margen y liquidaciones forzadas en miles de cuentas.

Estas liquidaciones forzaron más ventas en el mismo mercado ilíquido, bajando aún más el precio. El sistema de márgenes observó estos precios más bajos y marcó a la baja más posiciones, creando un bucle de retroalimentación que amplificó la presión de venta de 60 millones de dólares en 19.3 billones de dólares en liquidaciones forzadas.

Figura 4: Bucle de retroalimentación de liquidaciones en cadena

Este diagrama de bucle ilustra la naturaleza auto-reforzante de la cadena:

Caída de precio → disparo de liquidaciones → ventas forzadas → caída de precio aún mayor → [el ciclo se repite]

Si se hubiera utilizado un sistema de oráculos bien diseñado, este mecanismo no habría funcionado. Si Binance hubiera usado un precio promedio ponderado por tiempo (TWAP) de múltiples exchanges, la manipulación instantánea no habría afectado la valoración del colateral. Si hubieran usado flujos de precios agregados de Chainlink u otros oráculos multi-fuente, el ataque habría fallado.

El evento de wBETH de hace cuatro días mostró una vulnerabilidad similar. wBETH debe mantener una paridad 1:1 con ETH. Durante el evento en cadena, la liquidez se agotó y el mercado spot wBETH/ETH mostró un descuento del 20%. El sistema de márgenes devaluó el colateral wBETH en consecuencia, disparando liquidaciones de posiciones que en realidad estaban totalmente colateralizadas por ETH subyacente.

Mecanismo de Auto-Deleveraging (ADL)

Cuando las liquidaciones no pueden ejecutarse al precio de mercado actual, los exchanges implementan ADL, distribuyendo las pérdidas entre los traders con posiciones ganadoras. ADL cierra forzosamente posiciones ganadoras al precio actual para cubrir el déficit de las posiciones liquidadas.

Durante el evento en cadena de octubre, Binance ejecutó ADL en varios pares. Los traders con posiciones largas ganadoras vieron sus operaciones cerradas forzosamente, no por mala gestión de riesgo propia, sino porque otras posiciones se volvieron insolventes.

ADL refleja una decisión arquitectónica fundamental en los derivados centralizados. El exchange garantiza que no perderá dinero. Esto significa que las pérdidas deben ser absorbidas por una o varias de las siguientes partes:

· Fondo de seguro (reservas del exchange para cubrir déficits de liquidación)

· ADL (cierre forzoso de posiciones ganadoras)

· Pérdidas socializadas (distribución de pérdidas entre todos los usuarios)

El tamaño del fondo de seguro en relación al interés abierto determina la frecuencia de ADL. El fondo de seguro de Binance en octubre de 2025 sumaba unos 2 mil millones de dólares. Frente a 4 mil millones de dólares en interés abierto de contratos perpetuos de BTC, ETH y BNB, esto da una cobertura del 50%. Pero durante el evento en cadena de octubre, el interés abierto total superó los 20 mil millones de dólares. El fondo de seguro no pudo cubrir el déficit.

Tras el evento de octubre, Binance anunció que mientras el interés abierto total se mantenga por debajo de 4 mil millones de dólares, garantizan que no habrá ADL en los contratos USDⓈ-M de BTC, ETH y BNB. Esto crea una estructura de incentivos: el exchange puede mantener un fondo de seguro mayor para evitar ADL, pero esto inmoviliza capital que podría usarse para generar ganancias.

Fallas on-chain: Limitaciones de los protocolos blockchain

El gráfico de barras compara los tiempos de inactividad en diferentes eventos:

· Solana (febrero 2024): 5 horas - cuello de botella en el throughput de votos

· Polygon (marzo 2024): 11 horas - desincronización de versiones de validadores

· Optimism (junio 2024): 2.5 horas - sobrecarga del secuenciador (airdrop)

· Solana (septiembre 2024): 4.5 horas - ataque de spam de transacciones

· Arbitrum (diciembre 2024): 1.5 horas - falla de proveedor RPC

Figura 5: Interrupciones de redes principales - Análisis de duración

Solana: Cuello de botella de consenso

Solana experimentó múltiples interrupciones entre 2024 y 2025. La de febrero de 2024 duró unas 5 horas, la de septiembre de 2024, entre 4 y 5 horas. Ambas se debieron a causas similares: la red no pudo manejar el volumen de transacciones durante ataques de spam o actividad extrema.

Detalle de la Figura 5: Las interrupciones de Solana (febrero: 5 horas, septiembre: 4.5 horas) resaltan problemas recurrentes de resiliencia bajo presión.

La arquitectura de Solana está optimizada para throughput. En condiciones ideales, procesa 3,000-5,000 transacciones por segundo, con finalización sub-segundo. Este rendimiento supera en varios órdenes de magnitud a Ethereum. Pero durante eventos de presión, esta optimización crea vulnerabilidades.

La interrupción de septiembre de 2024 fue causada por una avalancha de transacciones basura que saturó el mecanismo de votos de los validadores. Los validadores de Solana deben votar sobre los bloques para lograr consenso. Normalmente, priorizan las transacciones de voto para asegurar el progreso del consenso. Pero el protocolo trataba las transacciones de voto igual que las normales en el mercado de fees.

Cuando el mempool se llenó con millones de transacciones basura, los validadores tuvieron dificultades para propagar votos. Sin suficientes votos, los bloques no se finalizaban. Sin bloques finalizados, la cadena se detenía. Los usuarios veían sus transacciones atascadas en el mempool. No se podían enviar nuevas transacciones.

StatusGator registró múltiples interrupciones de Solana entre 2024 y 2025, mientras que Solana nunca las reconoció oficialmente. Esto genera asimetría de información. Los usuarios no pueden distinguir entre problemas locales y problemas a nivel de red. Los servicios de monitoreo de terceros aportan rendición de cuentas, pero las plataformas deberían mantener páginas de estado completas.

Ethereum: Explosión de fees de gas

Ethereum experimentó picos extremos de fees de gas durante el auge DeFi de 2021, con fees de más de 100 dólares por una simple transferencia. Interacciones complejas con smart contracts costaban entre 500 y 1,000 dólares. Estos costos hicieron que la red fuera inutilizable para transacciones pequeñas y habilitaron un vector de ataque diferente: la extracción de MEV.

Figura 7: Costos de transacción durante presión de red

Este gráfico de líneas muestra dramáticamente el aumento de fees de gas durante eventos de presión en varias redes:

· Ethereum: 5 dólares (normal) → 450 dólares (congestión máxima) - aumento de 90x

· Arbitrum: 0.50 dólares → 15 dólares - aumento de 30x

· Optimism: 0.30 dólares → 12 dólares - aumento de 40x

La visualización muestra que incluso las soluciones Layer 2 experimentan aumentos significativos en fees de gas, aunque partan de un nivel mucho más bajo.

El Maximum Extractable Value (MEV) describe las ganancias que los validadores pueden extraer reordenando, incluyendo o excluyendo transacciones. En entornos de fees altos, el MEV se vuelve especialmente lucrativo. Los arbitrajistas compiten por adelantarse a grandes operaciones en DEX, los bots de liquidación compiten por ser los primeros en liquidar posiciones subcolateralizadas. Esta competencia se traduce en guerras de fees de gas.

Los usuarios que quieren asegurar la inclusión de sus transacciones durante la congestión deben ofertar más que los bots de MEV. Esto genera situaciones donde el fee de transacción supera el valor de la transacción. ¿Querés reclamar tu airdrop de 100 dólares? Pagá 150 dólares de gas. ¿Necesitás añadir colateral para evitar una liquidación? Competí contra bots que pagan 500 dólares de prioridad.

El límite de gas de Ethereum restringe la computación total por bloque. Durante la congestión, los usuarios pujan por el espacio escaso en los bloques. El mercado de fees funciona como se diseñó: quien paga más, tiene prioridad. Pero este diseño hace que la red sea cada vez más cara en periodos de alta demanda, justo cuando los usuarios más la necesitan.

Las soluciones Layer 2 intentan resolver esto moviendo la computación off-chain, mientras heredan la seguridad de Ethereum mediante liquidaciones periódicas. Optimism, Arbitrum y otros rollups procesan miles de transacciones off-chain y luego envían pruebas comprimidas a Ethereum. Esta arquitectura reduce el costo por transacción durante operaciones normales.

Layer 2: Cuello de botella del secuenciador

Pero las soluciones Layer 2 introducen nuevos cuellos de botella. Optimism experimentó una interrupción en junio de 2024 cuando 250,000 direcciones reclamaron un airdrop simultáneamente. El secuenciador, que ordena las transacciones antes de enviarlas a Ethereum, colapsó bajo la carga y los usuarios no pudieron enviar transacciones durante horas.

Esta interrupción muestra que mover la computación off-chain no elimina la demanda de infraestructura. El secuenciador debe procesar transacciones entrantes, ordenarlas, ejecutarlas y generar pruebas de fraude o ZK para liquidar en Ethereum. Bajo tráfico extremo, el secuenciador enfrenta los mismos desafíos de escalabilidad que una blockchain independiente.

Debe mantenerse la disponibilidad de múltiples proveedores RPC. Si el proveedor principal falla, los usuarios deberían cambiar automáticamente a alternativas. Durante la interrupción de Optimism, algunos proveedores RPC siguieron funcionando, otros no. Los usuarios con wallets conectadas por defecto al proveedor caído no podían interactuar con la cadena, aunque la cadena seguía online.

Las interrupciones de AWS han demostrado repetidamente el riesgo de infraestructura centralizada en el ecosistema cripto:

· 20 de octubre de 2025 (hoy): interrupción en la región Este de EE.UU. afecta a Coinbase, Venmo, Robinhood y Chime. AWS reconoce aumento de errores en DynamoDB y EC2.

· Abril de 2025: interrupción regional afecta simultáneamente a Binance, KuCoin y MEXC. Varios exchanges principales quedan fuera de línea cuando fallan sus componentes alojados en AWS.

· Diciembre de 2021: interrupción en la región Este de EE.UU. deja fuera de línea a Coinbase, Binance.US y el exchange “descentralizado” dYdX durante 8-9 horas, afectando también almacenes de Amazon y servicios de streaming.

· Marzo de 2017: interrupción de S3 impide a los usuarios iniciar sesión en Coinbase y GDAX durante cinco horas, junto con interrupciones generalizadas de internet.

El patrón es claro: estos exchanges alojan componentes críticos en la infraestructura de AWS. Cuando AWS sufre una interrupción regional, múltiples exchanges y servicios principales quedan fuera de línea simultáneamente. Los usuarios no pueden acceder a fondos, operar ni modificar posiciones durante la interrupción, justo cuando la volatilidad del mercado puede requerir acción inmediata.

Polygon: Desincronización de versiones de consenso

Polygon (antes Matic) sufrió una interrupción de 11 horas en marzo de 2024. La causa raíz fue la desincronización de versiones de validadores: algunos ejecutaban software antiguo, otros versiones actualizadas. Estas versiones calculaban las transiciones de estado de manera diferente.

Detalle de la Figura 5: La interrupción de Polygon (11 horas) fue la más larga de los eventos analizados, resaltando la gravedad de las fallas de consenso.

Cuando los validadores llegan a conclusiones diferentes sobre el estado correcto, el consenso falla y la cadena no puede producir nuevos bloques porque no hay acuerdo sobre la validez. Esto genera un punto muerto: los validadores con software antiguo rechazan los bloques de los actualizados y viceversa.

Resolverlo requiere coordinar la actualización de los validadores, pero esto toma tiempo durante una interrupción. Cada operador debe ser contactado, instalar la versión correcta y reiniciar su validador. En una red descentralizada con cientos de validadores independientes, esta coordinación puede tomar horas o días.

Las hard forks suelen usar un trigger por altura de bloque. Todos los validadores actualizan antes de un bloque específico, asegurando activación simultánea, pero esto requiere coordinación previa. Las actualizaciones incrementales, donde los validadores adoptan nuevas versiones gradualmente, corren el riesgo de la misma desincronización que causó la interrupción de Polygon.

Trade-offs de arquitectura

Figura 6: Trilema blockchain - Descentralización vs. rendimiento

Este diagrama de dispersión visualiza diferentes sistemas en dos dimensiones clave:

· Bitcoin: alta descentralización, bajo rendimiento

· Ethereum: alta descentralización, rendimiento medio

· Solana: descentralización media, alto rendimiento

· Binance (CEX): mínima descentralización, máximo rendimiento

· Arbitrum/Optimism: descentralización media-alta, rendimiento medio

Insight clave: ningún sistema logra máxima descentralización y máximo rendimiento a la vez; cada diseño implica trade-offs para diferentes casos de uso.

Los exchanges centralizados logran baja latencia mediante simplicidad arquitectónica; el motor de matching procesa órdenes en microsegundos, el estado reside en bases de datos centralizadas. No hay sobrecarga de consenso, pero esta simplicidad crea un punto único de falla; bajo presión, las fallas en cascada se propagan por sistemas estrechamente acoplados.

Los protocolos descentralizados distribuyen el estado entre validadores, eliminando puntos únicos de falla. Las cadenas de alto throughput mantienen esta propiedad durante interrupciones (los fondos no se pierden, solo la actividad se suspende temporalmente). Pero lograr consenso entre validadores distribuidos introduce sobrecarga computacional; los validadores deben acordar antes de finalizar transiciones de estado. Si ejecutan versiones incompatibles o enfrentan tráfico abrumador, el consenso puede detenerse temporalmente.

Añadir réplicas mejora la tolerancia a fallos, pero aumenta el costo de coordinación. En sistemas tolerantes a fallos bizantinos, cada validador extra añade sobrecarga de comunicación. Las arquitecturas de alto throughput minimizan esta sobrecarga mediante comunicación optimizada, logrando rendimiento superior pero siendo vulnerables a ciertos ataques. Las arquitecturas orientadas a seguridad priorizan diversidad de validadores y robustez de consenso, limitando el throughput base pero maximizando la resiliencia.

Las soluciones Layer 2 intentan ofrecer ambos atributos mediante diseño por capas. Heredan la seguridad de Ethereum (L1) mediante liquidación, mientras ofrecen alto throughput off-chain. Pero introducen nuevos cuellos de botella en secuenciadores y RPC, mostrando que la complejidad arquitectónica resuelve algunos problemas y crea nuevos patrones de falla.

La escalabilidad sigue siendo el problema fundamental

Estos eventos revelan un patrón consistente: los sistemas se configuran para la carga normal y fallan catastróficamente bajo presión. Solana maneja tráfico regular eficazmente, pero colapsa si el volumen sube 10,000%. Los fees de Ethereum son razonables hasta que la adopción DeFi causa congestión. La infraestructura de Optimism funciona bien hasta que 250,000 direcciones reclaman un airdrop simultáneamente. La API de Binance funciona normalmente, pero se limita durante eventos de liquidación en cadena.

El evento de octubre de 2025 mostró esta dinámica a nivel de exchange. Durante operaciones normales, los límites de API y conexiones de base de datos de Binance son suficientes, pero durante el evento en cadena, cuando cada trader intenta ajustar posiciones simultáneamente, estos límites se vuelven cuellos de botella. El sistema de márgenes, diseñado para proteger al exchange mediante liquidaciones forzadas, amplificó la crisis creando vendedores forzados en el peor momento.

El autoescalado no protege suficientemente contra aumentos escalonados de carga. Iniciar servidores extra toma minutos; en ese tiempo, el sistema de márgenes marca posiciones con precios dañados de libros de órdenes ilíquidos. Cuando la nueva capacidad está online, la reacción en cadena ya se propagó.

Sobreprovisionar recursos para eventos raros consume fondos durante operaciones normales. Los operadores de exchanges optimizan para la carga típica y aceptan fallas ocasionales como una decisión económicamente razonable. El costo del downtime se externaliza a los usuarios, que sufren liquidaciones, operaciones atascadas o inaccesibilidad de fondos durante movimientos críticos del mercado.

Mejoras de infraestructura

Figura 8: Distribución de patrones de fallas de infraestructura (2024-2025)

El gráfico circular de causas raíz muestra:

· Sobrecarga de infraestructura: 35% (más común)

· Congestión de red: 20%

· Fallas de consenso: 18%

· Manipulación de oráculos: 12%

· Problemas de validadores: 10%

· Vulnerabilidades de smart contracts: 5%

Varios cambios arquitectónicos pueden reducir la frecuencia y gravedad de fallas, aunque cada uno implica trade-offs:

Separación de sistemas de precios y liquidaciones

El problema de octubre se debió en parte a acoplar el cálculo de márgenes con el precio spot. Usar la tasa de conversión para activos envueltos en vez del precio spot habría evitado la mala valoración de wBETH. Más generalmente, los sistemas críticos de gestión de riesgo no deberían depender de datos de mercado manipulables. Sistemas de oráculos independientes con agregación multi-fuente y TWAP ofrecen flujos de precios más robustos.

Sobreprovisionamiento y redundancia de infraestructura

La interrupción de AWS de abril de 2025 que afectó a Binance, KuCoin y MEXC demostró el riesgo de dependencia de infraestructura centralizada. Ejecutar componentes críticos en múltiples proveedores de nube aumenta la complejidad y el costo, pero elimina fallas correlacionadas. Las redes Layer 2 pueden mantener múltiples proveedores RPC con failover automático. El costo extra parece desperdicio en operaciones normales, pero previene horas de downtime en picos de demanda.

Mejoras en pruebas de estrés y planificación de capacidad

El patrón de sistemas que funcionan bien hasta fallar muestra falta de pruebas bajo presión. Simular cargas 100x debería ser práctica estándar; identificar cuellos de botella en desarrollo cuesta menos que descubrirlos durante una interrupción real. Sin embargo, las pruebas realistas siguen siendo un reto. El tráfico de producción muestra patrones que las pruebas sintéticas no capturan; el comportamiento de usuarios durante un colapso real difiere del de pruebas.

El camino a seguir

Sobreprovisionar es la solución más confiable, pero entra en conflicto con los incentivos económicos. Mantener 10x de capacidad extra para eventos raros cuesta dinero todos los días para evitar un problema que ocurre una vez al año. Hasta que las fallas catastróficas impongan suficiente costo para justificar el sobreprovisionamiento, los sistemas seguirán fallando bajo presión.

La presión regulatoria podría forzar cambios. Si la regulación exige 99.9% de uptime o limita el downtime aceptable, los exchanges deberán sobreprovisionar. Pero la regulación suele seguir a los desastres, no prevenirlos. El colapso de Mt. Gox en 2014 llevó a Japón a regular formalmente los exchanges cripto. El evento en cadena de octubre de 2025 probablemente desencadene una respuesta regulatoria similar. No está claro si estas respuestas especificarán resultados (máximo downtime aceptable, máximo slippage durante liquidaciones) o métodos (proveedores de oráculos específicos, umbrales de circuit breaker).

El desafío fundamental es que estos sistemas operan en mercados globales 24/7, pero dependen de infraestructura diseñada para horarios comerciales tradicionales. Cuando la presión ocurre a las 02:00, los equipos corren para desplegar parches mientras los usuarios enfrentan pérdidas crecientes. Los mercados tradicionales detienen operaciones bajo presión; los cripto simplemente colapsan. Si esto es una característica o un defecto depende de la perspectiva.

Los sistemas blockchain han logrado una complejidad técnica notable en poco tiempo. Mantener consenso distribuido entre miles de nodos es un logro de ingeniería real. Pero lograr confiabilidad bajo presión requiere ir más allá de arquitecturas prototipo hacia infraestructura de nivel producción. Esta transición requiere fondos y priorizar la robustez sobre la velocidad de desarrollo de funciones.

El reto es cómo priorizar la robustez sobre el crecimiento durante un bull market, cuando todos ganan dinero y el downtime parece problema de otro. Cuando el próximo ciclo ponga a prueba los sistemas, aparecerán nuevas debilidades. Si la industria aprende de octubre de 2025 o repite el patrón sigue siendo una incógnita. La historia sugiere que descubriremos la próxima vulnerabilidad crítica con otro fracaso multimillonario bajo presión.