Polymarket Sets $3.9M Refund Plan After Third-Party Script Compromise

TL;DR: Polymarket says its October 29 incident involved a compromised monitoring script. Its October 30 update put total refunds at $3.9 million, including losses linked to the trading pause.

Polymarket has published a more detailed account of the third-party compromise that disrupted its international platform on October 29. The update shifts the focus from whether trading had reopened to how the attack worked and how customers would be compensated.

The company’s explanation is also a reminder that an onchain application can depend on offchain website components with access to active user sessions.

In its October 30 postmortem, Polymarket said it was returning $3.9 million: $2.7 million associated with the attack and another $1.2 million for pause-related losses. It reported that 95% of affected wallets had been refunded in full as of that afternoon.

The company said a compromised performance-monitoring script used some active sessions to sell positions and move funds. Its response included removing the script, clearing caches, resetting sessions and temporarily stopping trading and relayer activity.

The 95% figure is a timestamped company report. It should not be presented as a live refund completion rate or as proof that every disputed customer amount has been resolved.

A third-party script runs because a website chooses to load it. Depending on its permissions and execution environment, that script may interact with parts of the page and the browser session that users associate with the trusted application.

Mozilla’s documentation on subresource integrity describes one defense: a browser can compare a downloaded resource against an expected cryptographic hash and refuse content that does not match. It helps separate an approved file from a changed file served through the same address.

That mechanism is useful but limited. It does not decide whether the approved code was safe, and an application still needs a sound process for reviewing updates and controlling which resources are permitted to run.

In a market tied to a time-sensitive outcome, stopping transactions can affect users even if their wallet was never directly drained. A position might settle during the outage, or its market value might change before trading resumes.

Compensation for those effects requires a defined reference point. An operator needs to determine the relevant timestamp, position size and valuation method, then apply the same approach consistently. Otherwise, a refund headline can conceal disagreement about which losses are included.

This is particularly important when forced sales interact with thin liquidity. The difference between a displayed quotation and an executable price can become material precisely when the platform is under stress.

Removing the malicious file closes the immediate route described in the postmortem. The longer-term question is how future code changes are verified, what privileges external scripts retain and how quickly unusual activity is detected.

There is a sensible hierarchy here. Preventing an unnecessary script from reaching a sensitive page is different from detecting bad behavior after it has already begun. Both can be useful, but they should not be treated as interchangeable protections.

Users and counterparties will also benefit from clear reconciliation of completed refunds and any remaining disputes. An incident can be operationally resolved while accounting work continues.

Polymarket’s update provides concrete information about those separate tasks. The next assessment should focus on verified compensation outcomes and the effectiveness of revised controls, without assuming that blockchain settlement alone protects a user from every component of the application used to reach it.

Written by the News Desk and edited by Samuel Rae.