Alex Morgan
On October 29, users of Polymarket’s international platform began reporting positions sold and funds withdrawn without their authorization. The platform temporarily stopped new trades and relayer operations, then said a third-party provider had been compromised.
According to Bitquery’s estimate, funds left 737 accounts in one hour, totaling about $2.73 million. This is not Polymarket’s official total: the platform has not disclosed either the number of affected accounts or the final loss.
The unusual part is not only the scale. Bitquery found no broken smart contract or bypassed blockchain rule. The withdrawals carried valid approvals and traveled through Polymarket’s normal infrastructure. The system executed transactions that looked technically authorized even though account owners said they had not requested them.
What happened on October 29
Bitquery’s on-chain analysis places the first drains at 17:10 UTC. Five accounts were emptied in the initial burst, one for about $75,000. After a 13-minute pause, activity accelerated to as many as 40 withdrawals in a single minute.
By 18:10 UTC, Bitquery counted 737 affected accounts. The largest individual drain in its dataset was about $358,000. The distribution was highly uneven:
- 39% of affected wallets lost less than $100;
- four accounts represented 43% of the tracked amount;
- 33 accounts lost open positions as well as cash balances.
At 18:05 UTC, Polymarket’s official status page announced cancel-only mode: users could cancel existing orders, but no new orders or trades were processed. Relayer actions were paused at the same time.
At 18:37 UTC, Polymarket said it had identified and fixed the issue. It attributed the incident to a compromised third-party provider, referred the matter to law enforcement and promised to make affected users whole. The incident was marked resolved at 19:05 UTC.
How a third-party script could reach user funds
A modern trading platform rarely runs only its own code. A page may load outside components for analytics, performance monitoring, customer support and error detection.
The website owner installs this integration, not each user. In this case, reports point to a monitoring script embedded in Polymarket’s website. When someone opened the platform, their browser loaded that component automatically with the rest of the page. Users did not install a DebugBear application or browser extension themselves.
An external component runs beside the main application inside an already trusted page. If its supplier is compromised, malicious code can arrive through the normal integration and interact with an active session.
Polymarket did not publicly name the provider. However, the Associated Press and other publications linked the incident to performance-monitoring company DebugBear. DebugBear reported its own security incident that day and advised customers to remove its Real User Monitoring embed.
BleepingComputer analyzed a copy of the malicious JavaScript. It reported that the code checked for an authenticated Polymarket session, assessed balances and positions, and attempted to use the platform’s ordinary functions to move them.
That is different from exploiting a smart contract. The contract may correctly verify an approval and execute exactly what it receives. The failure happens earlier, in the interface that prepares an action on behalf of an authenticated user.
Deposit wallets, approvals and relayers
Three components explain the path.
The deposit wallet holds an account’s funds on Polygon. Bitquery says it contained pUSD, backed one-to-one by USDC.
An approval tells the wallet that an action is permitted. To the blockchain, it is a cryptographically valid instruction. The chain cannot know whether the person understood the action, whether the interface was altered or whether outside code abused an authenticated session.
The relayer submits the transaction and pays the network fee for the user. This makes the platform easier to use because every action does not require a separate payment in the network’s native token.
Bitquery’s findings indicate that this route worked as designed on October 29. The crucial difference was the destination: funds were directed to an address controlled by the attacker.
Therefore, “the transaction had a valid approval” does not mean “the user voluntarily approved the withdrawal.” The first describes what the blockchain verified. The second concerns human intent, which cannot be reconstructed from the on-chain record alone.
Why pausing the relayer mattered
Bitquery observed that the main wave stopped almost at the same time as the relayer. That does not prove every detail of the attack, but it shows the importance of the execution infrastructure.
In the preceding two weeks, the median day had about 47 Polymarket withdrawals swapped to POL through Relay. On October 29, a single address received 981 transfers.
The anomaly raises a clear monitoring question: should the system stop automatically when one new address receives funds from hundreds of independent accounts in a short period? A single rule can generate false positives, but a combination is more meaningful:
- an unusual number of accounts;
- the same destination address;
- a sharp increase in withdrawal frequency;
- positions sold immediately before withdrawal;
- activity far outside the previous baseline.
Where the assets went
Bitquery says funds were converted to POL, collected at one primary address, then split among new wallets and moved toward Ethereum through bridges.
The investigation also describes a newly created Polymarket account used to handle stolen outcome shares. Unlike a cash balance, these positions need to be sold or redeemed through market infrastructure. Bitquery says some shares were transferred to the new account and converted back into pUSD.
At the investigation’s last snapshot, 19:49 UTC on October 29, most tracked funds were still on Polygon. This describes the blockchain at a particular moment, not a final accounting of recovered or lost money.
Why 737 accounts and $2.73 million remain estimates
Bitquery linked the transfers to one destination and traced activity across Polygon and Ethereum. On-chain analysis shows addresses, amounts and timing, but it does not identify the attacker or reveal how every approval was obtained. Public account labels may also be incomplete.
The estimate covers funds on the route Bitquery identified. Other addresses or withdrawal methods could change the total, while POL and ETH valuations depend on the prices used at the snapshot time.
The precise formulation is therefore: Bitquery estimated $2.73 million in tracked losses from 737 accounts. Polymarket has not officially confirmed those figures.
Compensation and platform responsibility
Polymarket said every affected user would be made whole. At publication time, it had not released a final count, a total reimbursement amount or a timetable for completing payments.
For users, the source of the compromise does not separate neatly from the platform. A customer interacts with a complete product, not with an isolated smart contract, relayer or monitoring vendor. If an external dependency runs inside a trusted interface and can reach an authenticated session, its security becomes part of the platform’s security.
This is also not the first incident in this category. In June 2026, Polymarket reported that another compromised vendor had injected malicious code into its frontend for some users. Both cases involve a third-party dependency and the user interface, but there is not enough evidence to claim the same technical mechanism or a direct connection between them.
A secure smart contract does not cover the whole system
Blockchain security is often discussed through contract audits: can someone bypass a check, change a balance or withdraw funds contrary to protocol rules?
The Polymarket incident illustrates another boundary. Even when a contract behaves correctly, users still depend on the browser interface, their authenticated session, external scripts, the signing flow and the service that transmits transactions.
A blockchain can confirm that a transaction satisfies technical rules. It cannot confirm that a person saw an honest interface, understood the destination and intended that exact action.
The full security path is therefore:
third-party code → browser session → approval → relayer → smart contract → destination address
On October 29, the end of that chain worked as designed. A compromise near the beginning was enough for correct execution to produce the wrong result for users.
Polymarket restricted operations, restored trading and promised compensation. The next important steps are confirmation of those payments and a clear account of what will prevent another third-party dependency from turning a trusted interface into a source of valid but unwanted transactions.
