Polymarket’s breach tests the meaning of ‘made whole’

Updated 2 November 2026: Added DebugBear’s disclosure that its DNS records were compromised through its domain registrar.

Updated 31 October 2026: Polymarket has published its reimbursement policy and progress figures. This editorial has been revised to assess that disclosure.

Polymarket’s promise to make affected traders whole now has a published valuation basis. The question is whether users can reconcile that policy with the positions they held before the attack.

In its 30 October postmortem, the company said it was returning $3.9 million: $2.7 million plus $1.2 million for pause-related losses. It reported that 95% of affected wallets had been fully refunded that afternoon. These are company figures, not an independently reconciled payment total.

The company’s incident record shows a trading disruption from 18:05 to 19:05 UTC on 29 October. Polymarket said a third-party provider had been compromised, that it had identified and fixed the issue, and that affected users would be “made whole”. Its status page now lists the incident as resolved.

The disclosure covers Polymarket international. It does not establish a breach of Polymarket US. The $3.9 million package should not be described as the amount stolen, because it includes compensation for losses during the trading halt.

The policy addresses two different harms: an attacker taking a trader’s holdings and a halt preventing them from acting on those holdings. That distinction matters when the asset being reimbursed can expire before ordinary trading resumes.

The position matters

In its technical investigation, Hudson Rock examined malicious JavaScript retrieved from a DebugBear URL. The code sought an authenticated user’s trading client and signer. Depending on the account, it attempted to sell positions and move proceeds, or transfer position tokens directly. The researchers also found production build metadata recording removal of the DebugBear integration.

Those findings have limits. Examining the code does not prove that every attempted action succeeded, and Hudson Rock did not establish total losses or the complete sequence of transfers for each victim. The findings do, however, give a concrete reason to examine compensation at the position level.

A prediction-market account can contain cash and contracts with very different exposures. Under Polymarket’s published resolution rules, a winning share pays $1, a losing share becomes worthless, and trading ends once the market resolves. A trader who loses their shares also loses the ability to hold them through that outcome.

Consider a hypothetical account holding 1,000 Yes shares. An unauthorised sale at 40 cents produces $400, which is then stolen. If those shares later cost 60 cents, returning $400 would buy roughly 667 shares before fees, assuming enough shares were available at that price. Buying back the original 1,000 would cost $600.

That example is not a reconstruction of this incident. It shows why the proceeds of a forced sale and the cost of replacing a position can differ. If the price falls instead, the calculation changes again. A policy needs to work consistently in either direction.

This problem exists in other traded markets too. Event contracts add a deadline: the relevant event may occur before a reimbursement is processed, leaving no opportunity to re-enter the trade.

A refund needs a valuation rule

The postmortem says compensation for taken or force-sold positions uses their value when taken and includes sale slippage. For qualifying pause-related losses, the reference is value at the pause, covering markets that ended during it or positions sold just after reopening.

Those rules answer an important part of the question raised in the original version of this editorial. Affected users still need an account-level calculation they can compare with their holdings and unauthorised transactions.

The remaining detail is how those reference values were calculated. A valuation time is useful, but a trader also needs the price source, treatment of fees and the quantity of contracts included. That would let them check a payment without reconstructing the platform’s assumptions.

Thin order books make this harder. A displayed price may be available for only a small part of a position. If compensation relies on a quoted price, users need to know how it accounts for the cost of buying back their full holding.

For resolved markets, the relevant question is whether the payment follows the published policy consistently. Recreating the original position through trading is no longer possible once the event has settled.

Polymarket says it identified eligible wallets from trading and on-chain data without requiring claims, and offers a form for disputed or missing payments. It has not published an affected-wallet count or a reconciliation for the remaining wallets.

The incident review should include the trades

The technical investigation also deserves a full response. Reuters reported that DebugBear acknowledged a security incident and told customers using its real user monitoring product to remove the embedded code. Polymarket’s own notice referred to a compromised third-party provider without naming it.

DebugBear identifies DNS-record compromise

In a public company update, DebugBear says its DNS records were compromised through its domain registrar. Its initial investigation indicated that the attack targeted a specific customer’s website. The company did not name that customer in the statement.

DebugBear said it had found no indication that its internal systems were compromised, while stressing that its investigation continued. The statement does not explain how access through the registrar was obtained. It adds the vendor’s account of the incident without establishing a final root cause or changing Polymarket’s published reimbursement policy.

Polymarket says it removed the compromised script, reset active sessions and is adding stronger controls to third-party scripts. A further technical review should explain how those controls limit what outside code can do within the trading interface.

There is a separate question for the market record. If unauthorised sales executed, they may have affected prices or trading volume. The evidence reviewed here does not establish that any particular market’s odds were materially distorted. Polymarket should investigate whether that happened and identify affected periods if it did, so users of its price data can interpret them correctly.

The postmortem moves the discussion beyond a general reimbursement promise. The next test is practical: can each affected trader check the calculation, challenge an error and recover the amount due under the published rules?