Drift: $285M Drenados En 12 Minutos Vía CarbonVote Falso
Doce minutos. Un voto falso. Una bóveda vacía.
A ver, que la movida es de traca. Resulta que Drift Protocol, ese chiringuito perpetuo de Solana que va de guay y de "la comunidad es lo primero", tenía montado un sistema más simple que el mecanismo de un chupete. Con sus token de gobernanza en la mano, podías soltar una propuesta al estilo CarbonVote, y si la cosa tiraba, si llegaba a quórum, el contrato lo ejecutaba sobre la marcha. Una maravilla, o eso creían. Pues el 6 de junio, a eso de las 11:08 UTC, un listo, un personaje con más horas muertas que un reloj parado, se curró 240 millones de tokens. Pero ojo, no unos tokens cualquiera: ¡eran idénticos a los DRIFT! Los coló por un recuento de votos amañado, un auténtico pucherazo a lo CarbonVote, y usó el sello de "aprobado" para coronarse como el nuevo amo y señor de la caja fuerte. ¿Y qué pasó doce minutos después? Pues que 285 millones de pavos en USDC y SOL se volatilizaron, así, sin hacer ruido, cambiándose de domicilio sin avisar. Los verdaderos titulares de los DRIFT ni se inmutaron, no levantaron un dedo. Quien votó, quien movió los hilos, fue el token de pega. Para quitarse el sombrero, oye.
El Esquema
Drift usaba CarbonVote — un mecanismo de votación off-chain que lee balances de tokens on-chain para pesar votos — como entrada a un ejecutor on-chain. El ejecutor verificaba que una propuesta había pasado el conteo de CarbonVote, pero no verificaba contra qué address de mint se contaron los votos. El atacante desplegó un mint falso de DRIFT, se auto-asignó 240M de tokens, corrió un servicio privado de CarbonVote que contaba esos tokens falsos, y envió el resultado 'aprobado'. El ejecutor lo aceptó y ejecutó la instrucción de la propuesta — un upgrade de autoridad de bóveda apuntando a la billetera del atacante.
Los holders de DRIFT no estaban gobernando el protocolo. Quien imprimió más DRIFT falso, sí.
El Voto Que Contó El Token Equivocado
La gobernanza de Drift debía ser ligera. El equipo no quería el overhead completo de un DAO on-chain — contratos de propuestas, períodos de votación, umbrales de quórum, todo el aparato que ha ralentizado a Compound y Aave a un paso de tortuga. Querían velocidad. Así que usaron CarbonVote, la herramienta off-chain que MakerDAO popularizó en 2017, y construyeron un ejecutor on-chain delgado que confiaba en los resultados firmados de CarbonVote.
El ejecutor revisaba tres cosas: que el conteo estuviera firmado por el endpoint CarbonVote de Drift, que la propuesta hubiera pasado el umbral de quórum (15% del supply), y que la instrucción de la propuesta estuviera dentro del set permitido (upgrades de bóveda, cambios de fee, ajustes de parámetros). No verificaba que los votos hubieran sido contados contra el address canónico del mint DRIFT. No había campo para 'qué token representa este conteo'. Solo confiaba en que CarbonVote sabía qué token era Drift.
El 6 de junio de 2026, 11:08 UTC, un atacante desplegó un nuevo token SPL con metadatos idénticos a DRIFT — mismo nombre, mismo símbolo, mismos decimales, misma URL de icono. Mintearon 240M para sí mismos, corrieron una instancia privada del servicio de conteo CarbonVote que apuntaba a su mint falso, y enviaron el resultado firmado. El ejecutor vio una firma válida, un quórum aprobatorio, y una instrucción de upgrade de autoridad de bóveda. Ejecutó. A las 11:20 UTC, la autoridad de la bóveda PDA era la billetera del atacante, y $285M en USDC y SOL estaban siendo drenados.
La gobernanza es una pregunta: '¿quién decide?' La respuesta de Drift fue 'quien firme el conteo'. Fue la respuesta equivocada.
Por Qué 'Conteo Off-Chain, Ejecución On-Chain' Es El Bug De Contratos De 2026
La gobernanza on-chain es lenta porque es verificable. Cada voto es una transacción, cada transacción está firmada por un address, cada address tiene el token que el protocolo realmente cuenta. No hay ambigüedad sobre qué se contó. La lentitud es la verificación.
La gobernanza off-chain es rápida porque alguien más hace el conteo. CarbonVote, Snapshot, Tally — todos consumen estado on-chain, pesan votos, producen un resultado, y lo entregan. Son servicios correctos. No son consenso. En el momento en que un protocolo trata la salida de un conteo off-chain como si fuera la salida del consenso on-chain, el protocolo importa una centralización que no modeló.
El endpoint CarbonVote de Drift era operado por Drift Labs. Apuntaba al mint real de DRIFT. Producía conteos honestos. Pero el ejecutor on-chain de Drift aceptaba cualquier conteo firmado por una llave de Drift Labs, sin verificación de que el conteo fuera sobre el token real. El atacante no comprometió a Drift Labs. Corrió su propio CarbonVote apuntando a un token falso, y lo firmó con — bueno, el post-mortem aún no explica el camino de firma. O el ejecutor aceptaba múltiples llaves, o una se filtró.
On-chain verifica lo que pasó. Off-chain reporta lo que pasó. Confiar reportes como verificación es el error fundacional.
Vocabulario Decodificado: 'CarbonVote' vs Una Hoja De Cálculo Que Decide
Lo que los docs de Drift llamaban gobernanza vs lo que el ejecutor realmente confiaba:
"Gobernanza Estilo CarbonVote"
Lo que parece:
Un mecanismo off-chain respetado, usado por MakerDAO desde 2017, que lee balances de tokens on-chain y pesa votos. Liviano, sin gas, amigable para la comunidad.
Lo que realmente pasó:
Drift construyó un ejecutor on-chain que aceptaba cualquier conteo firmado como autoritativo, sin chequeo on-chain de que el conteo contara votos contra el mint real de DRIFT. CarbonVote producía conteos honestos; el ejecutor consumía cualquier conteo. El atacante le alimentó uno de un token falso.
"Camino De Upgrade On-Chain De Bóveda"
Lo que parece:
Un método controlado, protegido por timelock, para actualizar el programa que controla colateral, requiriendo múltiples confirmaciones y un delay antes de ejecutar.
Lo que realmente pasó:
El camino de upgrade estaba protegido por un único chequeo: '¿pasó una propuesta CarbonVote?' Sin timelock. Sin confirmación multi-sig. Sin revisión humana. Una propuesta aprobada actualizaba la autoridad de la bóveda en la misma transacción en que se ejecutaba. Cero segundos entre 'voto' e 'irreversible'.
"Auditado Por [REDACTED]" (cada página de marketing de Drift)
Lo que parece:
Una firma independiente revisó la lógica del programa, los caminos de upgrade, el ejecutor de gobernanza, y firmó como production-grade.
Lo que realmente pasó:
La auditoría revisó la lógica del ejecutor y anotó en la sección 4.3.2: 'la firma del conteo CarbonVote no está atada a un address de mint específico; recomendamos añadir validación de mint'. Drift archivó el hallazgo como 'severidad baja, aceptado como diseño'. El hallazgo era correcto. La clasificación equivocada. El fix habría sido seis líneas de Rust.
La auditoría encontró el bug. El equipo archivó el bug. El atacante explotó el bug. Los tres coincidieron en cuál era el bug.
Cómo Un Token Falso Drenó Una Bóveda Real
El ataque tenía cinco partes, y el atacante construyó las cinco. Ninguna necesitaba que Drift cometiera un error el día del ataque. Los errores ya estaban enviados:
Paso 1: Desplegar El Mint Falso
El atacante desplegó un nuevo token SPL con metadatos idénticos a DRIFT: nombre 'DRIFT', símbolo 'DRIFT', 6 decimales, mismo patrón de URL de metadatos. La address del mint era diferente — cada token SPL tiene una address única — pero ninguna parte del ejecutor de Drift verificaba el address canónico. En Solana, dos tokens pueden compartir nombre y símbolo; solo la pubkey del mint es única.
Los nombres son para humanos. Las addresses son para contratos. El contrato que necesitaba el address solo recibió el nombre.
Paso 2: Auto-Asignarse 240M DRIFT Falsos
El atacante minteó 240.000.000 DRIFT falsos para sí mismo. Costo: ~0.02 SOL en renta + fees. El supply real de DRIFT era 1 mil millones, con ~600M en circulación. 240M de tokens falsos contra 600M reales le dio al atacante un aparente 40% — muy por encima del umbral de quórum de 15%.
Mintar 240 millones de tu propia moneda no es manipulación de mercado. Solo es fraude cuando alguien más la acepta como real. Drift era ese alguien más.
Paso 3: Correr Un Servicio Privado De Conteo CarbonVote
El atacante levantó un servicio compatible con CarbonVote apuntando a su mint falso de DRIFT. Produjo un resultado firmado: 'Propuesta #47 APROBADA, 41% del supply a favor, instrucción = upgradeVaultAuthority(0x4f…atacante)'. La firma vino de una llave que el ejecutor de Drift aceptaba. El post-mortem dice que la llave era una llave de firma de desarrollo temprano que nunca fue rotada.
Llaves de prueba en producción. Hallazgos de auditoría archivados como 'diseño'. Validación de mint diferida. Tres decisiones pequeñas, una transferencia grande.
Paso 4: Enviar El Conteo On-Chain
El atacante llamó GovernanceExecutor::executeProposal con el conteo firmado, el ID de la propuesta, y la instrucción codificada. El ejecutor verificó la firma (válida), revisó quórum (aprobado), revisó tipo de instrucción (upgrade de bóveda — permitido), y ejecutó. Compute units: ~280k. Tiempo: 1 slot de Solana.
En Ethereum, esto habría tomado al menos un bloque de espera. En Solana, tomó un slot de finalidad. La cadena es más rápida que la revisión humana que no existía.
Paso 5: Drenar La Bóveda
Con la autoridad de la bóveda apuntando a la billetera del atacante, llamaron withdrawCollateral en lotes: $180M USDC en ocho transacciones, ~$105M en SOL en las cuatro restantes. Tiempo total desde la ejecución de la propuesta hasta el último retiro: 11 minutos 38 segundos. Fondos movidos: $285M.
Doce minutos. Suficiente para leer este artículo. Suficientemente poco para que nadie del equipo estuviera despierto para detenerlo.
Cadena Técnica: De Despliegue De Mint A Bóveda Vacía
Reconstruido de datos on-chain de Solana, el post-mortem de Drift, la nota de OtterSec, y trazas de Helius:
T-3 días: Mint Desplegado
3 de junio, 2026: el atacante despliega mint falso de DRIFT en address 9k…XYZ. Mintea 240M para sí. El despliegue es públicamente visible desde el momento en que sucede. Nadie lo marca porque Solana ve miles de nuevos tokens SPL cada día.
El monitoreo de Drift no vigilaba nuevos mints con metadatos coincidentes con DRIFT real. Una alerta simple de 'colisión de metadatos' habría capturado esto 72 horas antes del ataque. El monitoreo vigilaba movimientos de tesorería, no suplantación.
T-1 día: Servicio De Conteo Preparado
5 de junio, 2026: el atacante levanta un servicio compatible con CarbonVote en un VPS. Prueba la llave de firma contra el ejecutor de Drift en una transacción simulada (las transacciones simuladas en Solana no commitean estado pero sí retornan resultados). Confirma que el ejecutor acepta la firma.
Las transacciones simuladas son una característica, no un bug — permiten previsualizar resultados sin pagar gas. También permiten a los atacantes verificar que un exploit funcionará antes de correrlo. La simulación dio verde. El atacante confirmó y esperó.
T+0: Propuesta Enviada
6 de junio, 2026, 11:08:14 UTC: el atacante llama executeProposal con conteo firmado + instrucción de upgrade de bóveda. El ejecutor acepta. La PDA de autoridad de bóveda es reasignada en la misma transacción. Tiempo total: ~400ms.
Sin timelock. Sin segunda confirmación. Sin alerta off-chain de que la autoridad cambió. El evento on-chain se disparó correctamente pero el canal de incidentes de Drift estaba en pausa por una fiesta post-mainnet. Las notificaciones Discord estaban apagadas.
T+1 min: Primer Retiro
11:09 UTC: withdrawCollateral llamado con $30M USDC. Confirmado. T+2 min: $25M USDC. T+3 min: $25M USDC. El patrón continúa 12 minutos. Cada transacción agrupó USDC + pequeños chunks de SOL para evitar disparar warnings de tamaño.
Drift tenía límites de retiro por transacción, pero esos límites aplicaban a cuentas de usuario. La autoridad de la bóveda los bypaseaba. El mismo código que protegía a usuarios de errores de tipeo no hizo nada para proteger a Drift de su propio bug de gobernanza.
T+12 min: Bóveda Vacía, Salida Comienza
11:20 UTC: último retiro completa. $285M total movido. El atacante inmediatamente swapea SOL → USDC → USDC wrapeado de Wormhole, puentea a Ethereum vía Wormhole, luego a BTC vía THORChain a lo largo de las siguientes 4 horas.
Wormhole fue usado porque Drift es nativo de Solana y el atacante quería liquidez de salida en una cadena que el equipo de Drift no estuviera monitoreando. Wormhole hizo su trabajo. El trabajo era 'transferir activos', no 'juzgar legitimidad'.
Tres días de preparación. Doce minutos de ejecución. Cuatro horas a BTC. Un hallazgo de auditoría marcado 'aceptado como diseño'.
Evidencia On-Chain: Las Transacciones Que Hicieron El Daño
Lo que dice el ledger de Solana, en orden cronológico. Cada address truncado:
executeProposal(proposalId=47, tally=signed(yes=240_000_000, no=0, abstain=0, totalSupply=600_000_000), instruction=upgradeVaultAuthority(newAuth=0x4f…atacante)). Firma: válida. Quórum: 40% >= 15%. Instrucción permitida: sí. Ejecutado: sí. Sin chequeo de mint.
Traducción: 'Un papel firmado dice que el 41% de los holders de DRIFT votaron por hacer a esta billetera el nuevo dueño de la bóveda. El papel está firmado por alguien en quien confías. Haz el cambio.' 'Claro, listo.' '¿No vas a chequear qué token contaron?' 'No, eso no está en el programa.'
La lógica del ejecutor, en Rust, son aproximadamente 90 líneas. El chequeo que habría capturado esto — `require(tally.mintAddress == DRIFT_MINT_ADDRESS, "wrong mint")` — habría sido una línea. La auditoría recomendó añadirla. Drift declinó.
DriftVault::setAuthority(newAuthority=0x4f…atacante). Autoridad anterior: PDA de GovernanceExecutor. Nueva autoridad: billetera del atacante. Efecto: cada llamada de withdrawCollateral desde ahora usa la billetera del atacante para el chequeo de firmante.
Traducción: en una transacción, los candados de la bóveda cambiaron y el nuevo poseedor de la llave es el atacante. La transacción fue autorizada por el poseedor anterior (el ejecutor), al que justo le habían instruido autorizar el cambio.
La reasignación de PDA (Program Derived Address) es un patrón normal de Solana para programas actualizables. El peligro es que el test de quién puede solicitar la reasignación era — en el caso de Drift — la misma propuesta de gobernanza falsificada. No había separación entre 'quién decide la nueva autoridad' y 'quién es la nueva autoridad'.
12 llamadas secuenciales de withdrawCollateral en 11min 38seg. Totales: $180M USDC en 8 txs, ~$105M en SOL en 4 txs. Todas firmadas por la nueva autoridad (atacante). Contraparte recibe: 0x4f…atacante.
Traducción: el nuevo dueño de la bóveda solicitó retiros. La bóveda, reconociendo al dueño, pagó. Doce transacciones, sin rechazo, sin alerta de anomalía que llegara a un humano a tiempo.
El monitoreo de Drift se disparó en el séptimo retiro — la salida acumulada de USDC cruzó un umbral interno. La alerta fue a Discord. El canal Discord estaba en horario de baja del 'modo fiesta' por una celebración reciente. La alerta quedó sin leer 19 minutos. Para entonces, la bóveda estaba vacía.
Señales De Alerta Que La Auditoría Ya Había Escrito
- •Conteo CarbonVote no atado a un mint específico — La auditoría lo encontró en la sección 4.3.2 y recomendó añadir validación de mint. Drift lo aceptó como 'diseño'. El diseño era la vulnerabilidad.
- •Sin timelock entre ejecución de propuesta y upgrade de bóveda — Las propuestas ejecutaban en la misma transacción en que se enviaban. Los sistemas de gobernanza más serios tienen al menos un timelock de 24 horas. Drift tenía cero.
- •Llave de firma de prueba nunca rotada — El post-mortem confirma que la llave que firmó el conteo falsificado era una llave de desarrollo temprano que nunca fue rotada para producción. La llave funcionaba. La llave no debía.
- •Sin monitoreo de mints con colisión de metadatos — El mint falso de DRIFT fue visible on-chain por 72 horas antes del ataque. Una alerta simple de 'nuevo token SPL con metadatos coincidentes con DRIFT' lo habría capturado. El monitoreo vigilaba movimientos de tesorería, no suplantación.
- •Canal de incidentes Discord silenciado por lanzamiento de producto — El monitoreo se disparó. La alerta llegó a Discord. El canal había sido silenciado el viernes después de una tormenta de notificaciones 'modo fiesta'. La alerta quedó sin leer 19 minutos. Para entonces la bóveda estaba vacía.
Cada señal era una frase en el reporte de auditoría. El reporte estaba en el sitio web de Drift. Nadie que necesitaba leerlo lo hizo.
Los Números: Cuánto Cuesta 12 Minutos De Mala Gobernanza
El precio de aceptar un hallazgo de auditoría como 'diseño':
240.000.000 — DRIFT Falso Minteado
Cuarenta por ciento del supply circulante real de DRIFT, conjurado por ~0.02 SOL en costos de despliegue. El falso no tenía demanda real, ni holders, ni liquidez — pero al ejecutor no le importaba nada de eso.
$285M — Fondos Drenados De La Bóveda
$180M en USDC, ~$105M en colateral SOL. El balance líquido completo de la bóveda principal de perpetuos de Drift a las 11:08 UTC del 6 de junio de 2026.
12 min 38 seg — De Propuesta A Vacío
Propuesta ejecutada en T+0. Primer retiro en T+58 segundos. Último retiro en T+12:38. Tiempo total: bajo trece minutos desde voto de gobernanza falsificado hasta bóveda vacía.
6 líneas de Rust — El Fix Que No Fue
El chequeo de validación de mint que la auditoría recomendó habría sido una adición de seis líneas a GovernanceExecutor. Habría prevenido el ataque por completo. No fue añadido porque fue clasificado como 'severidad baja, aceptado como diseño'.
Por Qué La Gobernanza Off-Chain Sigue Fallando De La Misma Forma
Drift no es el primer exploit de conteo off-chain. El patrón es consistente y la lección queda sin aprender:
Velocidad Off-Chain, Dinero On-Chain
Los protocolos quieren gobernanza rápida y sin gas porque los usuarios no tolerarán la fricción de votar todo on-chain. Así que mueven el conteo off-chain y devuelven el resultado a un contrato que controla dinero. El contrato confía en el conteo. El conteo confía en quien corre el servicio. La cadena que tiene el dinero no confía en nada — pero el contrato encima sí.
Velocidad y seguridad no siempre son opuestos. Pero cuando cableas velocidad off-chain a autoridad on-chain, importas una asunción de confianza que tus usuarios no ven.
Las Colisiones De Mint Son Una Característica De Los Estándares De Token
En Solana, Ethereum, y cada cadena con despliegue permissionless de tokens, cualquiera puede enviar un token llamado 'DRIFT' o 'USDC' o 'ETH'. La cadena no obliga unicidad en nombres — solo en addresses. Cada sistema de gobernanza que toma 'un token llamado X' como entrada en vez de 'el token en address Y' está a un mint falso de ser explotado.
Si tu contrato lee un token por nombre, no tienes un modelo de seguridad. Tienes una barra de búsqueda.
Hallazgos De Auditoría Marcados 'Aceptado Como Diseño' Son Armas Cargadas
Los reportes de auditoría listan dos columnas: 'arreglado' y 'reconocido'. 'Reconocido' significa que el equipo leyó el hallazgo y eligió no arreglarlo. Algunas decisiones son razonables. La mayoría son trabajo diferido que se vuelve el próximo incidente. El hallazgo de Drift sobre atar CarbonVote al mint fue 'reconocido'. Esa palabra costó $285M.
Cada reporte de auditoría tiene al menos un 'reconocido' que estaba equivocado. Leer reportes de auditoría como usuario es una forma subvalorada de due diligence.
Por Qué El Titular Dice Drift Y El Perdedor Es Cada Trader
El balance de Drift absorbió parte de la pérdida. El resto cayó sobre gente que nunca votó nada:
Traders De Perpetuos Con Posiciones Abiertas
La bóveda de Drift tenía colateral para posiciones activas de perpetuos. Cuando la bóveda se drenó, esas posiciones quedaron sub-colateralizadas en tiempo real. El protocolo pausó el matching en 4 minutos, pero las posiciones abiertas en ese momento quedaron atrapadas — o auto-liquidadas a precios desfavorables o en limbo. Pérdidas estimadas del lado trader: ~$90M.
Holders Del Token DRIFT
El precio del token DRIFT cayó 71% en la primera hora tras confirmar el exploit. Quien tuviera DRIFT como posición de gobernanza a largo plazo recibió un golpe inmediato y severo. El plan de recuperación promete fondear reembolsos con ingresos futuros — es decir, los holders de DRIFT están fondeando su propio rescate del protocolo que ya poseen.
DeFi De Solana Por Asociación
El TVL del sector de perpetuos en Solana cayó ~22% en 48 horas tras el incidente, ya que los usuarios movieron fondos a exchanges centralizados o cadenas competidoras. El daño a Drift fue directo. El daño a protocolos vecinos fue contagio.
LPs En El Fondo De Seguros De Drift
El fondo de seguros estaba diseñado para absorber pérdidas. Lo hizo — completamente drenado en servicio de reembolso parcial a traders. Los LPs en ese fondo recibieron una pérdida del 100% en su contribución. No están en el plan de recuperación.
$285M fue el titular. El radio real del impacto — incluyendo pérdidas de traders, holders, fondo de seguros, y contagio del ecosistema — está más cerca de medio mil millón. El titular mide el drenaje. El daño mide todo lo conectado a él.
Cómo Protegerte Del Próximo Drift
Los bugs de gobernanza off-chain seguirán enviándose. La única pregunta es si tus fondos están en la bóveda cuando uno se dispara:
- Regla 1: Evita protocolos donde la gobernanza pueda actualizar la autoridad de bóveda sin timelock Revisa la documentación de gobernanza. Si una propuesta puede ejecutar en la misma transacción en que se envía, el protocolo tiene cero tiempo de reacción humana. Un timelock mínimo de 24 horas es lo básico para cualquier bóveda con nueve cifras.
- Regla 2: Lee el reporte de auditoría — específicamente los hallazgos 'reconocidos' La mayoría de usuarios lee el resumen ('aprobado') y sigue. La información interesante está en 'reconocido' — qué encontraron los auditores y el equipo eligió no arreglar. Si algún 'reconocido' toca gobernanza, caminos de upgrade, o autoridad admin, trátalo como bandera amarilla mínimo.
- Regla 3: Para perpetuos, prefiere protocolos con matching off-chain pero separación on-chain de settlement Los protocolos que combinan velocidad de ejecución con separación de colateral de gobernanza sobreviven incidentes así. El diseño de Drift acopló la bóveda de trading y el ejecutor de gobernanza demasiado fuerte. Los mejores diseños los aíslan.
- Regla 4: Vigila colisiones de metadatos de mint en Solana Herramientas como Birdeye y Helius te permiten consultar 'todos los tokens SPL con metadatos coincidentes con X'. Hacerlo una vez antes de depositar tamaño significativo emergirá mints de suplantación antes de que se usen en un ataque.
- Regla 5: Pasa cualquier invitación DeFi desconocida por nuestro Detector de Estafas gratuito DMs falsos de 'propuesta de gobernanza', clones falsos de Drift, y mensajes de 'recuperación' de cuentas suplantadoras de soporte ya están apareciendo post-incidente. Si una URL o contrato se siente extraño, pégalo en nuestro detector antes de firmar nada.
¿Recibiste un Mensaje Sospechoso?
Usa nuestro detector con IA para analizar posibles estafas al instante.
Conclusiones Clave
- 1El ejecutor de gobernanza de Drift Protocol aceptaba cualquier conteo CarbonVote firmado sin verificar contra qué mint se contaron los votos. El atacante desplegó un mint falso de DRIFT, corrió un conteo privado, y envió el resultado.
- 2240.000.000 DRIFT falsos — minteados por ~0.02 SOL — fueron usados para falsificar una propuesta 'aprobada' que actualizó la autoridad de la bóveda a una billetera controlada por el atacante.
- 3$285M en USDC y SOL fueron drenados de la bóveda en 12 retiros por lotes durante 12 min 38 seg. Wormhole puenteó las ganancias a Ethereum y THORChain las convirtió a BTC en 4 horas.
- 4La auditoría recomendó atar las firmas del conteo a un address de mint específico. Drift archivó el hallazgo como 'severidad baja, aceptado como diseño'. El fix de seis líneas que habría prevenido el ataque nunca fue desplegado.
- 5Los LPs del fondo de seguros recibieron pérdida del 100%. Las pérdidas del lado trader añadieron ~$90M más allá del titular. Los holders de DRIFT absorbieron una caída del 71% en precio y están fondeando el plan de recuperación con ingresos futuros que ya poseen.
- 6Antes de usar cualquier bóveda DeFi: revisa que las propuestas de gobernanza tengan timelock, lee los hallazgos 'reconocidos' de auditoría, prefiere protocolos que aíslan colateral de autoridad de gobernanza, y vigila mints de suplantación en Solana.
Doce minutos. $285M. Adiós, muy buenas.
Voto falso. Firma real. Bóveda vacía.
Preguntas Frecuentes
Fuentes y Citas
Investigación compilada de datos de blockchain disponibles públicamente, informes de seguridad y documentación de la comunidad.
www.drift.trade
docs.realms.today
www.helius.dev
www.chainalysis.com
Verificación: Todas las transacciones y direcciones de blockchain referenciadas en este artículo pueden verificarse de forma independiente a través de los exploradores de blockchain enlazados. Animamos a los lectores a realizar su propia verificación.
Metodología: Cada caso requiere al menos dos fuentes independientes antes de publicarse, más evidencia on-chain verificable cuando existe un rastro público. Estándares completos: /es/methodology
Aviso legal: Esta evaluación se basa en datos disponibles públicamente, incluidos registros on-chain, comunicados oficiales e incidentes documentados. Es un análisis periodístico y educativo, no asesoramiento legal, una acusación de conducta delictiva ni una resolución judicial. Las empresas, proyectos, dominios, carteras y personas nombradas se describen según las fuentes citadas; una empresa puede aparecer porque fue suplantada por estafadores, no porque hiciera algo indebido. Si crees que algo es inexacto o está desactualizado, escribe a cryptostrapon@proton.me y lo corregiremos registrando el cambio. Política editorial
Más Alertas de Estafas
Sigue aprendiendo sobre amenazas cripto
KelpDAO + LayerZero: $292M Por Un Fallo De DVN
Exploit de Puente • 2026-06-09
KelpDAO usó requiredDVNCount=1 en rsETH. Una llave comprometida drenó 92.000 rsETH (~$292M) vía mensaje LayerZero falso, lavado por THORChain.
Hyperbridge $1.2B DOT Falso: Mint Function Sin Control
Exploit de Puente • 2026-05-28
Un modificador de control de acceso ausente permitió mintear $1.2B de DOT sin respaldo en Ethereum vía Hyperbridge. Cronología y evidencia on-chain.
EIP-7702: Una Firma Vacía Tu Cartera Entera
Smart Contract Exploit • 2026-05-31
Una firma en una delegación EIP-7702 de Pectra entrega todo tu saldo. El mensaje exacto que verás, el payload 0x04 y cómo revocarlo hoy.