Exploit de Ajna: 775.400 dólares fugados y ningún botón de pausa en el protocolo de préstamos DeFi

Si tienes saldo en el protocolo de préstamos DeFi Ajna v2, retíralo ahora. El propio equipo de desarrollo lo pidió el 29 de agosto de 2026: retirar todos los tokens de cotización, devolver los préstamos en curso y suspender cualquier otra interacción con el protocolo. Entre el 28 y el 29 de agosto salieron unos 775.400 dólares de siete pools de la cadena Ethereum. Medido por la cuantía, es un incidente pequeño. Medido por lo que revela sobre una determinada forma de construir protocolos DeFi, está entre los más instructivos de este verano.

La razón está en la construcción. Ajna v2 está edificado como inmutable: sin órgano de gobernanza, sin vía de actualización, sin clave de administrador que pudiera detener el contrato. Una actualización de seguridad con el protocolo en marcha queda por tanto técnicamente descartada. La única instancia capaz de poner fin a la fuga son los usuarios, retirando su capital. La llamada del equipo no es, por eso, una precaución más entre otras medidas. Es la única reacción disponible.

El exploit de Ajna en resumen: 775.400 dólares de siete pools de Ethereum

Un protocolo de préstamos DeFi es un conjunto de contratos inteligentes mediante el cual los usuarios pueden prestar criptoactivos y tomarlos prestados contra garantías depositadas, sin que se interponga un banco o una empresa. En Ajna el capital prestado se encuentra en pools que reúnen cada uno un activo de garantía y un activo de préstamo.

La firma de seguridad Defimon publicó el 29 de agosto a las 09:29 UTC un desglose por pools. Según él, el daño se reparte así: el pool syrupUSDC fue el que más perdió, unos 173.700 dólares, seguido de wstETH con unos 159.800 y de rETH con alrededor de 143.000 dólares en total repartidos en dos transacciones. A cbETH le correspondieron unos 136.900 dólares, también en dos pasos; al pool WBTC unos 101.800; a WETH/USDC unos 42.000 y a sDAI unos 18.000 dólares. En conjunto, eso da los 775.400 dólares mencionados. El portal Cryptopolitan cita, apoyándose en DefiLlama, un valor ligeramente distinto de unos 775.000 dólares; la diferencia está en la valoración de los tokens afectados y carece de relevancia para el análisis.

La cronología es apretada. El 28 de agosto a las 15:16 UTC se desplegaron en Ethereum los contratos de ataque. Poco más de una hora después, a las 16:19 UTC, se ejecutó la primera extracción del pool cbETH, registrada en el bloque 25854888. La declaración pública del equipo no llegó hasta la mañana siguiente. Entretanto, la fuga siguió su curso.

Eso deja huella en el tamaño del protocolo. El valor total bloqueado, es decir, la suma de todos los activos depositados en el protocolo, quedó tras el incidente en unos 246.880 dólares. En los treinta días anteriores eso equivale a un retroceso del 71,3 %. Ajna ya era un protocolo pequeño antes del ataque. Ahora es muy pequeño.

Cálculo de liquidación en lugar de oráculo: cómo funcionó el ataque

Según el análisis del servicio especializado The Crypto Times, se trata de una manipulación de la contabilidad de liquidaciones y no de un ataque a una fuente de precios. Esa diferencia es el núcleo del caso y exige dos definiciones breves.

Qué aporta un oráculo en un protocolo de préstamos

Un oráculo es un servicio que suministra a un contrato inteligente precios del mundo exterior, por ejemplo la cotización actual del éter en dólares. Casi todo protocolo de préstamos necesita algo así para decidir cuándo una posición está infragarantizada. Justo por eso los oráculos son un objetivo predilecto: quien tuerce brevemente el precio suministrado puede hacer liquidar posiciones sanas o presentar garantías sin valor como si lo tuvieran.

Ajna renuncia deliberadamente a los oráculos. La valoración resulta de las pujas de los prestamistas dentro del propio pool. Este diseño descarta la clase de ataque más habitual y, en ese aspecto, ha demostrado su utilidad. El atacante tuvo que tomar otro camino.

Por qué las matemáticas de la liquidación fueron el punto de ataque

Una liquidación es el proceso por el cual un protocolo realiza las garantías de un prestatario porque su posición rebasa el límite admitido. En ese momento el contrato calcula cuánta garantía se entrega por cuánta deuda y qué ocurre con el resto. En todo protocolo de préstamos ese cálculo es el punto más exigente del código, porque debe mantener limpios a la vez los intereses, las comisiones, las liquidaciones parciales y los redondeos.

Exactamente ahí se apoyó el ataque. El atacante provocó liquidaciones y aprovechó cómo el protocolo contabiliza los restos que surgen en ellas, para hacerse asignar más valor del que le correspondía. Repetido en siete pools, eso arrojó la suma observada. Llama la atención que no hubiera claves robadas ni infraestructura comprometida. El contrato hizo exactamente lo que preveía su código.

Es además notable que Ajna v2 estuviera auditado. El caso se suma así a una observación que CoinGecko recoge en su informe sobre el estado de la seguridad cripto en 2026: de 245 incidentes registrados entre enero de 2025 y julio de 2026, con un daño total de 3.630 millones de dólares, 147 afectaron a protocolos auditados, que concentraron el 88,44 % del capital sustraído. Una auditoría superada es una señal de calidad. No es una garantía.

Protocolo inmutable sin gobernanza: por qué falta el botón de pausa

Un contrato inteligente inmutable es un contrato cuyo código ya no puede modificarse tras su despliegue. No hay ninguna dirección autorizada a introducir lógica nueva ni ninguna función que detenga el funcionamiento. En parte del entorno DeFi esta arquitectura es un ideal declarado, porque hace innecesaria la confianza en un equipo. Nadie puede cambiar después las reglas en beneficio propio, tampoco los desarrolladores.

El precio se hace visible cuando llega el daño. Con un protocolo actualizable, un equipo habría podido clausurar los pools afectados el 28 de agosto hacia las 16:30 UTC y corregir el fallo. En Ajna v2 esa vía no estaba abierta. The Crypto Times lo formula así: un parche de código con el protocolo en marcha no es aquí la vía de reacción habitual, y son los propios usuarios quienes asumen la función del botón de pausa. Eso no es un descuido del equipo, sino la consecuencia de una decisión de diseño deliberada.

Para ti como inversor se deriva de ahí una pregunta que precede a cualquier consideración de rentabilidad: ¿quién puede detener este protocolo en una emergencia, y con qué rapidez? La respuesta difiere por completo según el proveedor, y rara vez figura en la página de inicio. En nuestra comparativa de proveedores de préstamos cripto ves qué modelos trabajan con custodia y mecánica de emergencia y cuáles te dejan por completo a tu suerte.

Defimon avisó una hora antes: qué dice la cronología sobre las vías de reacción

La firma de seguridad Defimon afirma que su vigilancia detectó los contratos de ataque ya preparados más de una hora antes de la primera extracción y que avisó al equipo de Ajna por su canal de Discord, sin que a ese mensaje siguiera reacción alguna. Esta versión procede de un proveedor que se anuncia precisamente con esa detección temprana, y hasta ahora no ha sido confirmada de forma independiente. No existe una declaración pública del equipo de Ajna sobre este punto.

Aun si la descripción fuera exacta en todos sus detalles, la limitación decisiva sigue en pie. Un aviso solo sirve si su destinatario puede actuar. Con un contrato inmutable y sin gobernanza, el equipo no habría podido desconectar nada ni siquiera reaccionando de inmediato. Únicamente habría podido avisar antes, y los usuarios habrían tenido que retirar antes. En este principio constructivo la cadena de alerta termina siempre en ti.

Eso distingue el caso de aquellos incidentes en los que una red puede detenerse de forma centralizada. En el exploit de Maya Protocol, por ejemplo, se detuvo la operativa para evitar más daños. Esa opción no existe en todas partes y es en sí misma discutida, porque presupone que alguien tenga el poder de detener un sistema abierto.

Qué tienen que hacer ahora en concreto los usuarios de Ajna

La instrucción del equipo es escueta e inequívoca. Consta de tres acciones, y el orden no es indiferente.

Primero: retirar los tokens de cotización. Ajna llama token de cotización al activo de un pool que se presta, es decir, el lado en el que un prestamista aporta su capital. Quien figure como prestamista en alguno de los pools debería deshacer esa posición. Esto vale expresamente también para los pools que no aparecen en el desglose de Defimon: el desglose documenta dónde ya ha salido dinero, no dónde está seguro.

Segundo: devolver los préstamos en curso. Quien haya depositado garantías como prestatario solo las recupera mediante la devolución. Mientras la deuda siga abierta, la garantía permanece en el contrato y, con ello, en un sistema cuyo cálculo de liquidación es demostrablemente atacable.

Tercero: ninguna interacción nueva. Ningún préstamo nuevo, ningún depósito nuevo, ningún ajuste de las pujas existentes. Cada transacción adicional expone otra vez capital al fallo aún abierto.

Para la ejecución rige el mismo principio que en cualquier actuación de emergencia en DeFi: accede a las direcciones exclusivamente desde tus propios marcadores y nunca desde resultados de búsqueda ni desde mensajes que te lleguen sin haberlos pedido. Tras conocerse un exploit, el número de páginas de rescate falsas aumenta con regularidad, porque los estafadores cuentan justamente con las prisas que se han generado.

Cómo comprobar si tu protocolo de préstamos tiene una salida de emergencia

La cuestión del botón de pausa se aclara en pocos minutos si sabes qué buscar. Tres puntos bastan para una primera valoración.

Tres preguntas a la documentación

Primera: ¿existe una función de pausa y quién puede activarla? La documentación suele mencionarla bajo epígrafes como emergency pause, guardian o circuit breaker. Si falta cualquier referencia a ella, hay que suponer una arquitectura inmutable.

Segunda: ¿es actualizable el contrato y quién guarda las claves? Una vía de actualización significa que un fallo puede corregirse. Significa a la vez que alguien puede cambiar las reglas mientras tu dinero está en el contrato. Ambas cosas van juntas y no son una contradicción, sino una ponderación que deberías hacer con conocimiento de causa.

Tercera: ¿cómo te llega un aviso? Si la única cadena de comunicación es un canal de Discord que no lees, para ti prácticamente no existe. Un servicio de notificaciones para tus propias direcciones no cuesta nada y te da, llegado el caso, la ventaja que importa.

Quien rehúya esta comprobación encontrará la respuesta más sencilla en los proveedores supervisados: allí responde una empresa bajo supervisión, y la reacción ante una incidencia forma parte del modelo de negocio. Esa vía cuesta rentabilidad y te quita control. Pero también te quita la tarea de ser tú mismo el interruptor de emergencia a las 16:19 UTC.

Ajna en contexto: un verano con muchos incidentes pequeños

El exploit de Ajna no está solo. Un día antes, el 28 de agosto de 2026, la aplicación de tarjetas Avici, asentada sobre Solana, perdió según el recuento de DefiLlama 500.859,22 dólares en saldos de tarjeta, con 1.685 usuarios afectados. Las primeras estimaciones se habían movido entre 600.000 dólares y más de un millón; tras el análisis se impuso la cifra más baja. La causa fue, según el socio de tarjetas Rain, una versión defectuosa de un contrato de tarjeta que también usaban unos pocos programas más. Avici se ha comprometido a reembolsar íntegramente todos los saldos de tarjeta afectados.

Los dos casos se diferencian justamente en el punto que aquí importa. En Avici hay una empresa que puede asumir un compromiso y cuyo socio identifica el fallo. En Ajna hay un contrato que sigue funcionando y un equipo que pide a la gente que se retire. En un protocolo sin caja y sin gobernanza no está previsto ningún reembolso.

Para situar el orden de magnitud ayuda mirar la estadística. El informe de CoinGecko ya citado contabiliza, de enero de 2025 a julio de 2026, 245 incidentes con 3.630 millones de dólares de daño. Frente a esa vara de medir, 775.400 dólares son una nota al pie. Para los afectados la suma está perdida por completo, y sobre su importancia decide la parte que representa en la propia cartera, no la parte que representa en la estadística anual.

Impuestos y pruebas: qué documentar tras un exploit

Una pérdida por un exploit no es un caso fiscal sencillo, y este texto no sustituye al asesoramiento fiscal. Lo que merece la pena con independencia de ello es asegurar las pruebas, y de inmediato, mientras los datos sigan al alcance.

Guarda los hashes de transacción de tus depósitos y retiros, el saldo de la posición afectada antes del 28 de agosto de 2026, el comunicado público del protocolo con fecha y hora, y una prueba de las salidas obtenida de un explorador de bloques. Necesitarás esa documentación si más adelante entra en juego un reembolso, un acuerdo o un tratamiento fiscal. Quien la reúna solo entonces trabajará contra interfaces web ya borradas y canales de Discord archivados.

Importa separar dos operaciones: la salida provocada por el ataque y la venta posterior de una posición rescatada son fiscalmente dos cosas distintas. Anota ambas por separado, con fecha, cantidad y contravalor en euros.

Situar el exploit de Ajna: qué te llevas de todo esto

1. Si estás invertido en Ajna v2, actúa hoy. Retirar tokens de cotización, devolver préstamos, suspender la interacción, en ese orden. Dónde colocar tu capital en su lugar y en qué condiciones lo sitúa nuestra comparativa de préstamos cripto.
2. Aclara la cuestión de la emergencia en cada protocolo antes de depositar. Función de pausa, vía de actualización, canal de aviso. Quien no quiera hacer esa comprobación por sí mismo estará mejor atendido en proveedores supervisados; qué plataformas están autorizadas lo muestra el panorama de los exchanges de criptomonedas regulados.
3. Separa el saldo de negociación de la cartera de fondo. Lo que no empleas de forma activa no pertenece a un contrato inteligente, sino a tu propia custodia. Qué dispositivos entran en consideración y en qué se diferencian está en la comparativa de carteras hardware.

El desglose por pools y la cronología proceden del análisis de The Crypto Times del 29 de agosto de 2026. El proyecto publicó su llamamiento a los usuarios ese mismo día a las 04:58 UTC en su cuenta @ajnafi en X.

(29 de agosto de 2026. Este artículo no constituye asesoramiento de inversión. Los precios y las tarifas cambian; comprueba las condiciones con el proveedor antes de comprar.)