El hack de Avici demuestra dónde termina la autocustodia: el riesgo oculto de los contratos de tarjetas cripto
El incidente de Avici muestra por qué la autocustodia de una wallet no elimina el riesgo cuando los fondos pasan a contratos de saldo de tarjeta compartidos.
El hack de Avici demuestra dónde termina la autocustodia: el riesgo oculto de los contratos de tarjetas cripto
Tiempo de lectura: 6 minutos
Una wallet principal autocustodiada puede permanecer intacta mientras el saldo que un usuario transfirió para usar una tarjeta queda expuesto en otro contrato. Ese es el riesgo central que deja el incidente de Avici del 28 de agosto de 2026. No fue un compromiso de la blockchain Solana. Fue un incidente en una capa de contratos para saldos de tarjetas operada mediante infraestructura compartida. Para equipos que integran pagos cripto, la lección no es abandonar la autocustodia, sino mapear con precisión cuándo los fondos salen de su modelo de seguridad original.
Avici informó que 1.685 usuarios y US$500.859,22 en saldos de tarjeta fueron afectados. La empresa también afirmó que sus wallets autocustodiadas de Solana y EVM no se vieron afectadas y que no se observó más actividad no autorizada después de actualizar los contratos. Rain, el proveedor de infraestructura, dijo que un número reducido de programas usaba una versión desactualizada de sus contratos de Solana, que todos los programas afectados fueron actualizados y que los usuarios afectados serían resarcidos.
Qué está confirmado y qué no
Conviene separar los hechos publicados de las hipótesis técnicas. Avici confirmó su cifra de usuarios y saldos de tarjeta afectados, además del alcance limitado a esos saldos y la ausencia de nueva actividad no autorizada después de la actualización. Rain confirmó que algunos programas usaban una versión antigua y describió las medidas de actualización y resarcimiento. Son declaraciones, no un post-mortem independiente completo.
El analista on-chain Nikita publicó una secuencia que atribuye al atacante: primero SubmitSignatures, después AddCollateralAdmin y finalmente un retiro. Esa observación es útil para orientar una revisión, pero la interpretación de que existía un problema de verificación de firmas en la instrucción 0 sigue siendo análisis del investigador. Sin una investigación técnica independiente y completa, no debe presentarse como causa raíz confirmada.
Tampoco deben mezclarse cifras. The Defiant reportó actividad más amplia y un saldo aproximado de US$1,07 millones en la wallet atribuida al atacante. Esa cifra no equivale a la pérdida confirmada por Avici. FinanceFeeds también informó un impacto de infraestructura compartida: Tria habría comunicado 636 usuarios y US$431.945 afectados. Es un reporte secundario sobre otro programa que usaba la misma infraestructura, no una ampliación de la pérdida confirmada de Avici.
La frontera real de la autocustodia
🔐 La frase “mis fondos son autocustodiados” describe una propiedad de una wallet y sus claves, no de cada flujo posterior. Avici señaló que sus wallets autocustodiadas de Solana y EVM permanecieron intactas. La exposición cambió cuando usuarios recargaron tarjetas y esos fondos entraron en un contrato de saldo de tarjeta separado.
En este tipo de producto, la experiencia parece continua: el usuario deposita, consulta un saldo y paga. Desde seguridad, son dominios distintos. La wallet principal, el contrato de recarga, las instrucciones de autorización, los roles administrativos y la liquidación de tarjeta pueden tener claves, código, despliegues y propietarios diferentes. Rain había anunciado soporte de infraestructura de tarjetas para Solana junto con otras redes, una señal de que estos programas dependen de una capa de proveedores además de la aplicación visible al usuario.
La tesis educativa es sencilla: las wallets principales no fueron afectadas, pero el riesgo cambió de forma cuando los fondos pasaron a un contrato de saldo de tarjeta gestionado mediante infraestructura compartida. No es una contradicción de la autocustodia. Es una frontera de confianza que debe comunicarse, diseñarse y auditarse.
La secuencia técnica que debe investigarse
🧭 Si la secuencia observada por Nikita es correcta, el recorrido SubmitSignatures → AddCollateralAdmin → retiro sugiere una cadena de autorización que merece atención. Una operación que parece validar firmas puede convertirse en una puerta de escalamiento si la validación acepta un contexto, índice de instrucción, mensaje, firmante o reutilización que no corresponde a la acción sensible posterior.
Eso no prueba que la instrucción 0 fuera la vulnerabilidad, ni permite afirmar cómo se implementó el contrato. Sí proporciona un buen punto de partida para revisar la relación entre instrucciones, estado mutado y privilegios concedidos. El salto hacia AddCollateralAdmin es especialmente relevante: cualquier ruta que agregue una autoridad administrativa debe tratarse como una operación de alto riesgo, aun cuando se active desde una firma aparentemente válida.
No hay confirmación pública suficiente para afirmar si el contrato vulnerable fue auditado. Ese dato debe permanecer como desconocido, no como una inferencia a favor o en contra del proveedor.
Checklist de auditoría para saldos de tarjetas
✅ Una revisión útil no se limita al contrato que recibe fondos. Debe recorrer todo el ciclo de vida del saldo y cada dependencia compartida.
- Inventario de dependencias y versiones. Registrar programa, hash o versión desplegada, red, propietario de actualización y programas consumidores. Incluir contratos de tarjeta, librerías y servicios que construyen transacciones.
- Detección de deriva de despliegue. Comparar continuamente las versiones esperadas con las direcciones e identidades de programa en producción. Alertar cuando un socio quede en una versión antigua.
- Pruebas negativas de verificación de firmas. Probar índices de instrucción erróneos, mensajes modificados, firmantes no autorizados, firmas reutilizadas y firmas válidas para otra acción. Verificar que cada firma esté ligada a la operación, cuenta, importe y expiración exactos.
- Mínimo privilegio y rutas administrativas. Enumerar quién puede crear o añadir administradores, cambiar colateral, retirar fondos, pausar y actualizar. Exigir autorización separada, límites y trazabilidad para cada ruta.
- Propiedad de actualizaciones y rollout. Definir quién controla la autoridad de upgrade, cómo se aprueba una versión y cómo se confirma que todos los programas de socios migraron. Un contrato corregido no elimina el riesgo si una instancia anterior sigue activa.
- Monitoreo y límites por cuenta. Alertar sobre cambios de administrador, retiros atípicos y secuencias inusuales. Aplicar límites de retiro, ventanas temporales y revisiones adicionales por cuenta cuando el modelo lo permita.
- Contención y conciliación. Preparar pausas acotadas, preservación de evidencia, identificación de saldos expuestos y conciliación entre estado on-chain, libro interno y obligaciones de reembolso.
Compartir infraestructura también comparte riesgo
La noticia de Tria reportada por FinanceFeeds ilustra por qué un incidente de proveedor exige una respuesta de cartera, no solo de una marca. Un mismo contrato o una misma versión puede respaldar varios programas con usuarios y saldos separados, pero con una superficie técnica común. La segmentación de cuentas ayuda a limitar el alcance individual, pero no sustituye la gestión de versiones, los controles de privilegio ni el monitoreo de comportamiento.
Los equipos deben pedir una vista verificable de sus despliegues, sus autoridades y sus dependencias. También deben acordar por adelantado quién puede pausar, cómo se comunica una actualización urgente y cómo se reconcilian los saldos tras un incidente. Esa preparación transforma un proveedor compartido de una caja negra en una dependencia gobernable.
Conclusión
El incidente de Avici no demuestra que Solana fuera comprometida ni que la autocustodia sea inútil. Demuestra que la protección de una wallet termina donde empieza otro sistema de custodia, autorización o contrato. Para una tarjeta cripto, esa frontera puede estar en la recarga. Auditarla requiere revisar versiones, firmas, privilegios, monitoreo y respuesta como un solo flujo de fondos.
Este artículo será actualizado cuando Avici, Rain o los investigadores publiquen un post-mortem técnico con la causa raíz y el impacto definitivo.