El drenaje de 600.000 dólares de Avici, explicado

El incidente de Avici comenzó el 28 de agosto de 2026, cuando se informó de que más de 600.000 dólares habían salido de cuentas que servían como garantía de las tarjetas. Las primeras estimaciones oscilaron entre unos 600.000 dólares y más de un millón a medida que se rastreaban las transacciones en la cadena. Posteriormente, varios informes señalaron que Rain, el socio emisor de las tarjetas de Avici, había identificado una vulnerabilidad en una versión antigua de un contrato de tarjetas de Solana y que los contratos afectados habían sido actualizados. Por eso, las primeras cifras no deben tratarse automáticamente como la pérdida final. 49 50 53

La distinción clave está entre las billeteras de autocustodia habituales de Avici y los contratos separados utilizados para respaldar los saldos de las tarjetas. Según los informes posteriores, el incidente afectó a estos últimos y no necesariamente a la infraestructura de billeteras que los usuarios empleaban para mantener otros activos en Solana o en redes EVM. 50 53

Cómo conectaba Avici las criptomonedas con los pagos Visa

Avici no ofrecía una cuenta bancaria convencional, sino un modelo de tarjeta garantizada. Según su documentación:

1. El usuario depositaba USDC en un contrato inteligente de garantía de préstamo.
2. Ese depósito generaba un saldo de crédito en dólares para la tarjeta.
3. Cada compra reducía dicho saldo.
4. El USDC equivalente a los gastos se liquidaba más tarde desde el contrato de la tarjeta, normalmente con un retraso de entre uno o dos días y, en algunos casos, de hasta una semana. 35

La documentación de Avici indicaba que el contrato de garantía estaba desplegado en una red EVM, aunque podía aceptar depósitos procedentes de Solana mediante un puente automático gestionado por la plataforma. También señalaba que la billetera de la tarjeta era independiente de la billetera inteligente y que Visa solo podía retirar fondos después de demostrar que se había realizado un pago. 33

Este diseño explica tanto el atractivo como el riesgo del producto. El usuario podía gastar contra sus criptomonedas sin entregar toda su billetera a un banco o a un exchange centralizado. Sin embargo, el dinero entraba en un sistema programable compuesto por contratos inteligentes, puentes entre redes, infraestructura del emisor de la tarjeta y mecanismos de autorización de transacciones.

En otras palabras, “autocustodia” no significa que todos los componentes del flujo de pago sean igual de sencillos, independientes o resistentes a fallos.

Qué ocurrió y cómo cambió la explicación

Primeros reportes: retiros no explicados de los saldos de las tarjetas

El 28 de agosto, Avici reconoció un problema que afectaba a los retiros de los saldos de las tarjetas, mientras observadores de la cadena detectaban movimientos hacia direcciones controladas por el atacante. Los primeros informes situaron el drenaje aparente entre aproximadamente 600.000 y 653.000 dólares. Más tarde, otros análisis siguieron más de un millón de dólares a través de la billetera sospechosa. Es posible que esas cifras correspondieran a fases o flujos distintos, por lo que no deben sumarse sin más. 49 51 54 58

En ese momento, la información pública no permitía determinar si la causa era un fallo en el contrato de la tarjeta, un mecanismo de autorización o retransmisión comprometido, un problema de abstracción de cuentas o de registro de administradores, una campaña de phishing u otro componente de la plataforma.

Actualización posterior: Rain señaló un contrato antiguo de Solana

Una actualización posterior atribuyó el incidente a una vulnerabilidad detectada por Rain en una versión antigua del contrato de tarjetas de Solana utilizado por Avici y por un pequeño número de otros proyectos. Según esos informes, los contratos relevantes fueron actualizados y no se había detectado nueva actividad no autorizada en el momento de la actualización. También se indicó que el incidente se limitó al contrato independiente de Solana que almacenaba los saldos de las tarjetas después de las recargas, mientras que las billeteras de autocustodia de los usuarios en Solana y redes EVM permanecían separadas. 50 62

Más tarde, otro informe cifró la pérdida reconciliada en 500.859,22 dólares y señaló que afectó a 1.685 usuarios. Avici prometió reembolsar íntegramente a los afectados. 53 Esta cifra es más concreta que las estimaciones iniciales obtenidas en tiempo real de la cadena, pero conviene distinguir entre los cálculos preliminares del ataque y la reconciliación comunicada después.

Por qué los informes de phishing siguen siendo importantes

La explicación del contrato no elimina el riesgo independiente de phishing. El 28 de agosto se informó de sitios falsos que imitaban a Avici y utilizaban supuestos airdrops o funciones de la plataforma para convencer a los usuarios de conectar sus billeteras y autorizar transacciones maliciosas. Esos informes atribuyeron más de 600.000 dólares en pérdidas a un sitio que suplantaba a Avici y señalaron que, en ese momento, no había pruebas públicas de una brecha interna de la plataforma. 2 4

Ambas explicaciones no son necesariamente incompatibles. Una vulnerabilidad en un contrato puede afectar a las cuentas que contienen los saldos de las tarjetas, mientras una campaña de suplantación independiente puede vaciar las billeteras de quienes firman transacciones maliciosas.

Sin un informe técnico completo que relacione direcciones afectadas, contratos, instrucciones de las transacciones y marcas de tiempo, no es seguro asumir que todas las pérdidas tuvieron el mismo origen.

Qué sigue pendiente de documentar

El registro público disponible todavía deja abiertas varias preguntas técnicas importantes:

• cuál era exactamente la versión vulnerable del contrato y cuáles eran sus direcciones de despliegue;
• qué instrucción o secuencia de transacciones permitió el ataque;
• si el atacante obtuvo privilegios administrativos no autorizados o aprovechó otra ruta de autorización;
• cuál era la lista completa de cuentas y saldos afectados;
• cómo se detectó la actividad y cuánto tiempo pasó hasta la actualización de los contratos;
• cómo funcionará el proceso de reembolso y cuál será su alcance; y
• si algún usuario debe renovar passkeys, sesiones, autoridades delegadas o credenciales de la billetera.

La atribución posterior de Rain es una explicación relevante para el incidente de los saldos de las tarjetas, pero no basta para afirmar que todos los drenajes relacionados con Avici procedieron de la misma vulnerabilidad. Para resolverlo haría falta un análisis posterior detallado, verificable de forma independiente.

Qué deben hacer ahora los usuarios afectados

1. Dejar de usar enlaces y contratos sospechosos

No interactúes con Avici ni con contratos relacionados con las tarjetas a través de enlaces enviados por mensaje directo, anuncios, respuestas en redes sociales o supuestos anuncios de airdrops. Mientras se confirman los detalles de la corrección, utiliza un dominio oficial guardado previamente o un canal de soporte verificado de forma independiente.

2. Diferenciar un problema de permisos de una clave comprometida

Si introdujiste una frase de recuperación, expusiste una clave privada, instalaste una extensión de billetera no confiable o firmaste una transacción desconocida, traslada los activos restantes a una billetera nueva utilizando un dispositivo o entorno limpio.

Revocar permisos no soluciona el compromiso de una frase semilla o de una clave de firma.

3. Revisar los permisos en cada red

En billeteras EVM, revisa las autorizaciones de tokens y elimina los permisos desconocidos o ilimitados concedidos a terceros. Comprueba también si hay claves de sesión, autoridades delegadas o permisos sospechosos relacionados con la abstracción de cuentas.

En billeteras de Solana, revisa las transacciones firmadas recientemente, las aplicaciones conectadas, los delegados desconocidos y las sesiones activas. Solana no utiliza exactamente el mismo modelo de autorizaciones que las redes EVM, por lo que una herramienta genérica para “revocar aprobaciones de tokens” puede no detectar todos los permisos relevantes.

4. Conserva las pruebas

Guarda las direcciones de las billeteras, las firmas de las transacciones, las URL sospechosas, capturas de pantalla, horarios y mensajes o anuncios que condujeron a la interacción. Esta información puede ayudar al proveedor de la billetera, al soporte autenticado de Avici o a los investigadores a distinguir un caso de phishing de un incidente en un contrato.

5. Desconfía de las estafas posteriores

No firmes una transacción de “verificación”, “reembolso” o “recuperación” enviada por una cuenta que no esperabas. Las víctimas conocidas suelen convertirse en objetivos de suplantadores que prometen devolver los fondos robados.

Qué revela el caso Avici sobre la autocustodia

La autocustodia cambia el modelo de riesgo, pero no elimina el riesgo. Un usuario puede evitar que un custodio centralizado tenga control unilateral sobre sus activos y, aun así, quedar expuesto al software de la billetera, la lógica de los contratos inteligentes, los puentes, los retransmisores, las passkeys, los permisos delegados, las interfaces web, los emisores de tarjetas y los procesos de liquidación.

El contraste con el robo de Coldcard ocurrido en 2026 ayuda a entenderlo. En ese caso, los informes describieron el robo de unos 594 BTC de aproximadamente 500 billeteras en alrededor de 25 minutos, después de que un problema de firmware debilitara la aleatoriedad utilizada para generar las semillas de las billeteras. El fallo estaba en el dispositivo y su firmware, no en la criptografía subyacente de Bitcoin. 30

Avici representa una clase distinta de fallo: un producto de pagos puede mantener el control del usuario sobre una billetera general y, al mismo tiempo, colocar la garantía de la tarjeta en un sistema de contratos especializado con dependencias propias. Coldcard pone de relieve los riesgos del hardware y de la generación de claves; Avici, los riesgos de los contratos, la autorización, la interfaz y la infraestructura de los socios.

La lección práctica no es que la autocustodia sea intrínsecamente insegura ni que la custodia centralizada sea automáticamente más segura. Es que la seguridad de un producto de pagos basado en autocustodia depende de todo el recorrido de la transacción.

Antes de utilizar uno, conviene identificar qué activos permanecen en la billetera habitual, cuáles pasan a un contrato de tarjeta o de garantía, quién puede autorizar los retiros, cómo se gobiernan las actualizaciones y qué ocurre si falla un socio o un contrato.