Skip to content

A Vendor’s Script, Not a Smart Contract, Forced Polymarket’s Trading Halt

Polymarket placed its exchange in cancel-only mode and paused the relayer that submits traders’ signed transactions at 18:05 UTC on October 29, 2026, after detecting an incident. Its status page logged the event as a major outage affecting the Predictions trading API and marked it resolved an hour later, at 19:05 UTC. In between, the platform said it had identified and fixed the issue, attributed it to a compromised third-party provider, referred the matter to law enforcement, and promised that anyone affected would be made whole.

What cancel-only mode actually does

Cancel-only mode is the emergency brake on a trading venue. Users can cancel or reduce existing orders but cannot place new ones. Pausing the relayer at the same time closes a second channel: the service that submits signed transactions to the blockchain on a trader’s behalf. Switching off both paths makes it far harder for an attacker to keep selling positions through the platform’s own infrastructure while engineers isolate the cause. The ordering is deliberate: a venue halts new risk first and answers questions about the cause second.

Where the compromise sat

The root cause was not a flaw in Polymarket’s core contracts. Security researchers at Hudson Rock reported that a script loaded from a web performance monitoring vendor contained code that looked for a logged-in user’s trading session and tried to sell their positions and move the assets. Polymarket’s own statement is narrower: it said one of its third-party providers was compromised and did not name the vendor. The two accounts are not contradictory, but only the platform’s statement is confirmed.

The on-chain figure is reported, not settled

Blockchain analytics firm Arkham said it traced roughly $2.65 million to a single wallet it attributes to the suspected attacker, accumulated through a series of USDC.e-to-POL swaps. That number is an analyst estimate, not an independently confirmed loss. Polymarket has not said how many accounts were affected, how the vendor was compromised, or how much money was ultimately taken.

What the make-whole pledge commits the platform to

The make-whole pledge is a promise to compensate users, and it is the clearest signal that Polymarket intends to absorb the loss rather than dispute responsibility for a vendor’s failure. The commitment does not by itself confirm the scale of the damage, because the platform has not published a final tally of affected accounts or total losses. It does, however, shift the near-term question from who pays to how quickly the platform can identify every affected user and restore their balances.

A supply-chain failure, not a protocol failure

The distinction matters for anyone who treats an audit as proof of safety. A smart-contract review would not have caught this failure, because the malicious code arrived through a vendor that already had legitimate access to the frontend. For a user, the exploit could look like an ordinary signature request or a quietly sold position. The lesson is specific: a prediction-market position is only as safe as the weakest vendor connected to the page that manages it, not the protocol underneath. The relevant question after an incident like this is not whether the contracts were audited, but how the platform reviews and isolates the third-party code running beside them.

Adapted from Polymarket Halts Trading After Third-Party Provider Breach Drains User Wallets.