La verdad explosiva detrás de los bots de criptomonedas que anticipan a los ladrones para "salvar" fondos — pero deciden quién recibe el reembolso

Fuente: CryptoNewsNet Título original: La explosiva verdad detrás de los bots de crypto que anteponen a los ladrones para “salvar” fondos — pero deciden quién recibe el reembolso Enlace original:

El incidente de Makina Finance

Makina Finance perdió 1,299 ETH, aproximadamente 4.13 millones de dólares, en una explotación de préstamo flash y manipulación de oráculos.

El atacante drenó los fondos del protocolo y transmitió la transacción al mempool público de Ethereum, donde debería haber sido detectada por los validadores e incluida en el siguiente bloque.

En cambio, un constructor MEV identificado por la dirección 0xa6c2 antepuso la transacción de drenaje, redirigiendo la mayor parte de los fondos a una custodia controlada por el constructor antes de que el hacker pudiera moverlos fuera de la cadena.

La transacción del hacker falló. Los fondos quedaron en dos direcciones asociadas con el constructor MEV.

La conclusión inmediata es que los usuarios de Makina evitaron una pérdida total. La señal más profunda es quién terminó teniendo el dinero y qué significa eso para la arquitectura emergente de respuesta a emergencias en crypto.

El actor más importante en esta historia no es el atacante ni el protocolo, sino la cadena de suministro de construcción de bloques que interceptó la explotación y ahora controla si los usuarios recuperan sus fondos, en qué condiciones y con qué rapidez.

Los bots y constructores MEV se están convirtiendo en la última línea de defensa de crypto, no por diseño sino por posición estructural. Eso es un problema, porque la capacidad de rescate está concentrada en manos de intermediarios que maximizan beneficios y operan con una responsabilidad poco clara.

El MEV como respaldo ya es un patrón

El incidente de Makina no es un caso aislado. Chainalysis documentó una dinámica similar durante la explotación de Curve y Vyper en 2023, señalando que hackers de sombrero blanco y operadores de bots MEV ayudaron a recuperar fondos, reduciendo las pérdidas realizadas por debajo de las estimaciones iniciales.

El patrón es mecánico: mientras las explotaciones o intentos de rescate sean visibles en canales de transacción públicos, buscadores y constructores sofisticados pueden competir para reordenar transacciones.

A veces salvan fondos. A veces los capturan. De cualquier forma, actúan como una capa de respuesta a emergencias de facto.

Cuando una transacción de explotación entra en el mempool público, los buscadores MEV monitorean oportunidades rentables. Si un hacker drena un protocolo y transmite la transacción públicamente, un buscador puede construir una transacción competidora que se ejecute primero, redirigiendo los fondos a una dirección diferente.

El buscador agrupa la transacción y la envía a un constructor de bloques, quien la incluye si la ganancia supera las ofertas competidoras. Si el bloque del constructor es elegido por un validador, la transacción del buscador se ejecuta y la del hacker falla.

Esto es extracción de beneficios con un efecto secundario beneficioso, más que altruismo puro. Pero también es el mecanismo más confiable que ha desarrollado crypto para interceptar explotaciones en tiempo real, porque opera en la capa de ordenamiento de transacciones en lugar de depender de cortacircuitos o intervenciones de gobernanza a nivel de protocolo.

Por qué la dependencia de constructores MEV es incómoda

El problema con los rescates basados en MEV es que concentran la capacidad de respuesta a emergencias en una cadena altamente intermediada.

En Ethereum, MEV-Boost domina la producción de bloques. El panorama de relés de Rated muestra que aproximadamente el 93.5% de los bloques recientes se enrutan vía MEV-Boost, en comparación con aproximadamente el 6% usando producción de bloques estándar.

Dentro de MEV-Boost, la participación en el mercado de relés está aún más concentrada: Ultra Sound Money representa aproximadamente el 29.84% del tráfico de relés, y Titan aproximadamente el 24.24%, lo que significa que los dos relés más grandes gestionan juntos más del 54% de la producción de bloques.

Si la mayoría de los bloques fluyen a través de MEV-Boost y la mayor parte del tráfico de MEV-Boost pasa por dos relés, la capa de rescate depende estructuralmente de un pequeño conjunto de intermediarios. Eso genera rápidamente problemas de gobernanza.

Si un constructor termina teniendo fondos rescatados, ¿quién autoriza la custodia? ¿Quién establece la recompensa? ¿Qué impide extorsión o demandas de rescate? ¿Y si el constructor está en el extranjero, es anónimo o opera en una jurisdicción con poca aplicación de la ley?

El caso de Makina ilustra el problema. Los fondos están en custodia del constructor, pero no hay un SLA público, recompensa predefinida ni mecanismo claro para devolver los fondos a Makina o a sus usuarios.

El constructor podría devolver los fondos voluntariamente, negociar una recompensa, exigir una tarifa más alta que las normas del sector, o negarse a devolver los fondos en absoluto.

La enrutación privada empeora el problema

Un artículo académico de 2025 titulado “Sandwiched and Silent” documentó una enrutación privada generalizada de transacciones y encontró que muchas víctimas migran hacia canales privados después de ser sandwichadas por bots MEV.

Sin embargo, la enrutación privada no elimina el MEV, solo lo traslada de los mempools públicos a canales de orden privado controlados por constructores y relés.

Para los protocolos, eso significa que los rescates en mempool público se vuelven menos confiables porque las transacciones de explotación cada vez más se enrutan a través de canales privados accesibles solo a un subconjunto de constructores.

Un intento de civilizar el caos

Safe Harbor es un marco desarrollado por SEAL que busca reemplazar el modelo de “constructor MEV como custodio accidental” por respondedores autorizados, SLAs explícitos y incentivos limitados.

SEAL describe Safe Harbor como un marco legal y técnico que permite a los protocolos preautorizar a sombreros blancos para intervenir durante explotaciones activas.

La regla operativa principal es que los fondos rescatados deben enviarse a direcciones de recuperación oficiales en un plazo de 72 horas, con recompensas predefinidas y exigibles.

SEAL afirma que Safe Harbor fue motivado por el hack de Nomad, donde los sombreros blancos estaban dispuestos a ayudar pero estaban limitados por la ambigüedad legal sobre si devolver fondos podría ser perseguido como acceso no autorizado a computadoras.

Safe Harbor elimina esa ambigüedad al dar a los protocolos una forma de preautorizar la intervención y establecer términos claros. SEAL afirma que Safe Harbor ya protege más de $16 mil millones en varios protocolos importantes, incluyendo ciertos DEXs, Pendle, algunas soluciones de capa 2 y zkSync.

Immunefi, la plataforma de recompensas por bugs, ha operacionalizado Safe Harbor con términos más estrictos.

Immunefi describe Safe Harbor como un marco desarrollado por SEAL que redirige fondos a una bóveda controlada por el protocolo en la plataforma de Immunefi. En la página del programa Safe Harbor de Immunefi, los términos establecen: “Tienes 6 horas para transferir los fondos de vuelta.”

El incumplimiento de las seis horas constituye una violación material. Eso es cuatro veces más rápido que el requisito base de 72 horas de SEAL.

Safe Harbor no elimina la dependencia de la infraestructura MEV. Solo intenta formalizarla.

Si un constructor antepone una explotación y el protocolo ha adoptado Safe Harbor, se espera que el constructor reconozca la intervención como autorizada y redirija los fondos a la dirección de recuperación designada por el protocolo dentro del SLA.

Pero eso asume que los constructores monitorean los registros de Safe Harbor, respetan los términos y priorizan el cumplimiento sobre el beneficio.

Rango de escenarios

La tasa esperada de recuperación de usuarios en una explotación puede modelarse como: recuperación esperada = probabilidad de intervención × (1 - porcentaje de recompensa) × (1 - porcentaje de fallo o fuga).

Safe Harbor busca aumentar la probabilidad de intervención reduciendo la ambigüedad legal y limitando el porcentaje de recompensa de antemano.

En el caso base, la adopción de Safe Harbor aumenta en los próximos 12 meses. Más protocolos añaden términos de Safe Harbor a sus marcos de gobernanza, y más sombreros blancos se registran como respondedores autorizados.

La probabilidad de intervención aumenta porque los respondedores tienen claridad legal y términos de recompensa fijos. Las tasas de recuperación mejoran, especialmente para protocolos que adoptan SLAs más estrictos, como la ventana de seis horas de Immunefi.

En el escenario alcista, la capa de rescate se profesionaliza. Los protocolos construyen direcciones de bóveda seguras, comprimen los SLAs a horas sencillas y negocian previamente los cronogramas de recompensas con equipos de sombreros blancos conocidos.

Los constructores integran los registros de Safe Harbor en sus algoritmos de ordenamiento de transacciones, redirigiendo automáticamente los fondos rescatados a direcciones designadas sin intervención manual.

En el escenario bajista, la dependencia de los constructores se intensifica. El flujo privado de órdenes y la concentración de relés hacen que los rescates sean menos transparentes y más oligopólicos. Los protocolos que no han adoptado Safe Harbor terminan negociando con constructores después del hecho, sin palanca o SLA claros.

La gobernanza pasa a depender de intermediarios que mantienen fondos y establecen términos unilateralmente.