Polymarket paró las operaciones durante una hora y después reabrió el trading
El incidente empezó a reflejarse públicamente a las 18:05 UTC, cuando Polymarket puso su plataforma internacional en modo «cancel-only»: los usuarios podían cancelar órdenes existentes, pero no abrir nuevas posiciones, y las acciones del relayer quedaron pausadas. A las 18:37 UTC, la plataforma comunicó que había identificado y corregido el problema, atribuyéndolo al compromiso de un proveedor externo. A las 19:05 UTC, su página de estado dio el incidente por resuelto.
La cifra de pérdidas sigue siendo una estimación, no un dato oficial de Polymarket. Bitquery rastreó 2,73 millones de dólares saliendo de 737 cuentas entre las 17:10 y las 18:10 UTC. Otros análisis on-chain han situado la cantidad en una horquilla similar, en torno a 2,6-2,7 millones. Polymarket no ha publicado por ahora un total propio de fondos robados ni el número definitivo de usuarios afectados, aunque ha asegurado que reembolsará a quienes hayan sufrido pérdidas.
El aviso se refería a Polymarket.com, su plataforma internacional. La página de estado muestra actualmente sus sistemas de trading y liquidación como operativos. El producto estadounidense es un servicio separado y no formó parte del incidente comunicado.
La blockchain no fue el punto débil: el ataque se produjo en la capa web
La investigación técnica apunta a un problema distinto al típico exploit de un smart contract. Hudson Rock analizó un script servido desde infraestructura de DebugBear, una herramienta de monitorización del rendimiento web, y detectó código capaz de localizar sesiones autenticadas de Polymarket, revisar posiciones e intentar venderlas o transferir activos. DebugBear reconoció el 29 de octubre que estaba afectada por un incidente de seguridad y pidió a los clientes de su producto RUM que retirasen temporalmente su código embebido.
Polymarket no ha identificado públicamente al proveedor comprometido, así que conviene mantener esa distinción: la relación con DebugBear procede de investigadores de seguridad y de fuentes independientes, no de una confirmación nominal de Polymarket. Reuters también identificó a DebugBear como el proveedor implicado citando a una fuente conocedora del caso.
Los datos on-chain de Bitquery tampoco muestran un smart contract roto. Las retiradas siguieron la ruta habitual, llevaban aprobaciones válidas y fueron procesadas por el relayer de Polymarket. Dicho de otra forma, la cadena registró operaciones técnicamente válidas aunque el origen de esas autorizaciones estuviera comprometido. Para entender la diferencia, es importante separar la seguridad de la propia blockchain de la seguridad de las aplicaciones y servicios que se ejecutan sobre ella.
Ser no custodial no elimina el riesgo de la interfaz y de los proveedores externos
Aquí está la parte más importante para el usuario. Una plataforma puede apoyarse en wallets controladas por sus usuarios y en liquidación on-chain y, aun así, depender de una web, una sesión autenticada, un relayer y código proporcionado por terceros. Si uno de esos componentes queda comprometido, el atacante puede intentar aprovechar permisos disponibles en el navegador sin necesidad de vulnerar la blockchain.
Eso cambia la forma de entender el riesgo. La autocustodia reduce determinadas dependencias de una plataforma centralizada, pero no convierte en irrelevante la seguridad del front-end. Un script externo cargado dentro de una sesión con capacidad para operar puede convertirse en una puerta de entrada. Es una diferencia parecida a la que explicamos al comparar DEX y CEX desde la perspectiva de la custodia y el riesgo: quién controla las claves importa, pero también qué software recibe permisos para interactuar con los activos.
Hay otro matiz relevante. Hudson Rock no encontró en la muestra analizada una rutina destinada a enviar contraseñas, seed phrases o claves privadas. El mecanismo estudiado se apoyaba principalmente en la autoridad ya disponible dentro de una sesión autenticada. No es lo mismo comprometer las claves de una wallet que conseguir que una aplicación legítima procese una operación que el usuario no pretendía realizar.
El incidente tampoco aparece de forma aislada. En junio de 2026 Polymarket ya confirmó otro compromiso de un proveedor externo que permitió inyectar código malicioso en su front-end y acabó afectando a fondos de usuarios. Ese antecedente no demuestra por sí solo un fallo estructural de todos los mercados de predicción, pero sí refuerza una idea: la cadena de suministro de software también forma parte de la superficie de ataque en cripto.
En España, que el servicio haya vuelto no significa que esté autorizado
Para un lector en España hay un segundo matiz que no conviene perder. La Dirección General de Ordenación del Juego abrió el 26 de mayo de 2026 un expediente sancionador contra Polymarket y Kalshi por una posible infracción de la normativa de juego, al considerar que estarían operando sin la habilitación administrativa exigida. Como medida cautelar, ordenó el bloqueo de sus páginas web hasta la resolución definitiva del procedimiento.
La última comunicación oficial publicada que hemos localizado de la DGOJ es la que anunció ese expediente y la medida de bloqueo. En la revisión realizada el 30 de octubre no hemos localizado una resolución final pública posterior. Por tanto, que Polymarket haya reanudado su actividad internacional no equivale a que esté autorizado para operar en España.
Tampoco es una cuestión que pueda reducirse a MiCA. La DGOJ considera que los mercados de predicción en los que se apuesta sobre acontecimientos futuros inciertos tienen naturaleza de juego de azar y que su explotación en España requiere una licencia administrativa específica. Para ampliar cómo cambian los riesgos según la infraestructura utilizada, nuestra guía sobre DeFi y sus riesgos explica las diferencias entre smart contracts, intermediarios y dependencias externas.
Quedan varias incógnitas importantes. Polymarket todavía no ha publicado una cifra oficial de pérdidas, el número definitivo de usuarios afectados, el calendario concreto de reembolsos ni un informe técnico completo del incidente. Tampoco ha nombrado públicamente al proveedor implicado. Cualquier comunicación sobre compensaciones debería comprobarse en los canales oficiales de la plataforma para evitar que el propio incidente sirva de excusa para nuevos fraudes.
La lección no es que una blockchain haya fallado. Es más concreta: la seguridad de una plataforma cripto no termina en sus smart contracts ni en quién guarda las claves. También depende del navegador, del front-end y de los proveedores que cargan código dentro de una sesión con permisos reales sobre el dinero del usuario.
