Exploit de Polymarket: una clave filtrada, no un error de contrato
El 22 de mayo de 2026, el investigador on-chain ZachXBT detectó un vaciado en una de las billeteras de Polymarket. Las estimaciones iniciales rondaban los $520K. Para cuando el equipo confirmó los detalles, la cifra se acercaba a los $660K-$700K. Sin reentrancia. Sin manipulación de oráculos. Sin coreografía elaborada de flash loans. Solo una clave privada que terminó donde no debía.
El exploit de Polymarket no tocó la parte del stack que todo el mundo paga a Trail of Bits y OpenZeppelin para revisar. Golpeó una billetera interna de recarga, una cuenta operativa usada para financiar recompensas y mantener el flujo. El tipo de billetera que nunca aparece en el alcance de una auditoría porque no es un contrato. Es una clave que vive en la infraestructura de alguien.
Eso es lo incómodo. Después de un año en que los titulares giraron en torno a bridges y configuraciones erróneas de DVN, el mercado de predicciones más financiado del mundo fue vaciado mediante el fallo más básico del manual.
Lo que realmente ocurrió en Polygon
La cuenta drenada era una billetera de operaciones, no fondos de usuarios custodiados en los contratos principales del protocolo. Según el reporte de CoinDesk, ZachXBT detectó aproximadamente $520K moviéndose, y el equipo de Polymarket afirmó que los fondos de los clientes estaban a salvo. El atacante barrió POL y otros activos de la billetera en Polygon y luego hizo lo que siempre hacen los atacantes: los movió a través de un bridge y los dispersó antes de que nadie pudiera congelarlos.
Decrypt situó la cifra más cerca de los $700K e identificó específicamente que se trataba de una billetera interna de recarga. La discrepancia en los números es normal en las primeras 24 horas; el mecanismo no está en disputa. Alguien obtuvo la clave.
Esto es un exploit de POL en Polygon únicamente en el sentido de que POL era el activo que había en la billetera. La cadena no falló. El contrato no falló. Lo que falló fue la custodia de una clave operativa.
Por qué el UMA CTF Adapter no fue el problema
La resolución de mercados de Polymarket corre a través del oráculo optimista de UMA mediante el UMA CTF Adapter, el contrato que publica preguntas, gestiona disputas y liquida resultados. Esa es la pieza que, sobre el papel, concentra el mayor riesgo adversarial. Ha sido auditada. Ha sido probada en batalla a través de miles de mercados.
Y no tuvo nada que ver con esto.
Creo que este es el detalle que la gente va a pasar por alto y no debería. La capa de contratos inteligentes aguantó. El oráculo aguantó. Lo que falló fue una billetera que un humano controla con una clave a la que un humano (o un pipeline de CI, o un servicio de firma en caliente) tiene acceso. Pasamos el mercado alcista reforzando las partes que tienen verificación formal e ignorando las partes que tienen un archivo .env.
Las claves operativas son ahora la verdadera superficie de ataque
Este es el patrón en los incidentes de 2026. El Solidity está mejorando. Los auditores hacen bien su trabajo. Los métodos formales detectan los bugs de reentrancia que antes drenaban nueve cifras. Así que los atacantes se movieron.
Se movieron hacia el tejido blando:
- Billeteras calientes usadas para recompensas, recarga de gas y creación de mercado.
- Claves de deployer que nunca se rotaron tras el lanzamiento.
- Firmantes de multisig que reutilizan un laptop para firmar y navegar.
- Secretos de CI/CD que pueden firmar transacciones en producción.
Nada de eso aparece en un informe de auditoría. Cuando evalúo la seguridad en un exchange regulado, la revisión de contratos representa quizás un tercio del trabajo. El resto son HSMs, segregación de firmantes, documentación de ceremonias de claves, y la pregunta profundamente poco glamurosa de "quién puede mover dinero a las 3 de la mañana y qué lo detendría." Esa última parte es donde la mayoría de los equipos están expuestos.
Esta es la misma lección que la pérdida de Kelp DAO en LayerZero: $292M desaparecidos no por un bug en un contrato, sino por una configuración errónea en la capa operativa. Mecanismo diferente, misma causa raíz: la parte aburrida que nadie audita.
Cómo debería haber sido una billetera de operaciones de $660K
Si una sola clave puede mover $660K, eso es una decisión de diseño, no mala suerte. Algunas cosas que deberían ser básicas para cualquier billetera operativa que maneje valor significativo:
- Límites de gasto en la propia lógica de la billetera. Una billetera de recarga de recompensas no tiene ningún motivo para poder enviar su saldo completo en una sola transacción. Limítala en la cadena.
- Firma por umbral para cualquier monto por encima de un mínimo. Los pequeños pagos automatizados pueden ser en caliente. Cualquier cosa por encima de, digamos, $10K debería requerir un segundo firmante. Safe multisig con un umbral bajo para transferencias grandes no es difícil.
- Aislamiento de la clave respecto al entorno de la aplicación. La clave de firma de una billetera operativa nunca debería vivir donde el código de la aplicación, las dependencias o un runner de CI comprometido puedan leerla.
- Monitoreo que alerte a un humano ante salidas anómalas. ZachXBT detectó esto antes de que el equipo lo anunciara. Las propias alertas del equipo deberían adelantarse a un tercero mirando el mempool.
Nada de esto es novedoso. Es lo que se recorta cuando un equipo está construyendo rápido y la billetera es "solo para recompensas."
La brecha en el stack de auditoría que nadie gestiona
El problema más profundo es de orden jurisdiccional, internamente. La seguridad de los contratos inteligentes tiene un responsable claro: la firma de auditoría. La seguridad de las claves operativas tiene... quien configuró la billetera, generalmente bajo presión de plazos, y que casi nunca se revisita. Escribí sobre esta brecha en el contexto de la pila de auditoría rota de DeFi: la certificación cubre los contratos y se detiene en el límite del contrato. Todo lo operativo queda fuera del alcance y fuera de la mente.
Hasta que un regulador o una aseguradora obligue a que la seguridad operativa sea una partida presupuestaria con un responsable, esto seguirá ocurriendo. La seguridad operativa de DeFi en 2026 está aproximadamente donde estaba la seguridad de contratos inteligentes en 2019: se sabe que es importante, no la gestiona nadie y se financia en último lugar.
Polymarket estará bien. $660K es asumible para una plataforma de su tamaño, y hay que reconocerles que se comunicaron rápido y con claridad. Pero el próximo equipo al que le ocurra quizás no tenga margen para absorberlo. El compromiso de clave que vacía una tesorería en lugar de una billetera de recompensas está por llegar, y no será un bug de Solidity. Será una clave en un laptop.