In crypto and prediction markets, trust can’t stop at login. It has to be assessed continuously.
October 2026 already has a name in security circles: Black October. A pair of decade-old PHP flaws uncovered with help from AI. A supply-chain compromise of LiteLLM, a widely used AI gateway. Weak keys behind eight certificate authority certificates. Then, on October 29, a tampered vendor script drained an estimated $2.7 million from roughly 700 Polymarket accounts.
Picture a trader opening Polymarket on Thursday afternoon. Real site, real login, no dodgy link to click. But someone had tampered with a script from a performance-monitoring vendor running on the page. It read the trader’s balance and open positions, then tried to sell them and move the money out, all inside a session the trader had already opened. Nobody broke into Polymarket. They broke into a vendor Polymarket trusted.
Polymarket moved quickly: it paused trading, reset every active session, and referred the case to UK law enforcement. It has since returned about $3.9M to traders, covering the drained funds plus losses from the trading pause, and says 95% of affected wallets have been made whole. Its separately regulated US platform was not affected.
Many security experts see last month as the start of a new era, not a blip. AI is making old vulnerabilities cheaper to find and exploit, while defence still moves at human speed. So for any platform where a logged-in session can move money, the useful question isn’t whether a vendor will ever be compromised. It’s what a compromised session is allowed to do.
Your attack surface is every script you let into the page
A modern web app runs code from a long list of outside vendors: analytics, performance monitoring, chat, experimentation. Any of them loaded directly into the page runs with the same privileges as your own code. Compromise one, and the attacker doesn’t need to break your smart contracts or your login. They inherit a session your customer already trusted.
On a trading venue, a compromised script reaches straight into customer funds. For Polymarket, that meant a trading pause, a law-enforcement referral, and a reimbursement program within a day.
The browser already ships with two guardrails that often go unused. Subresource Integrity pins a third-party script to a hash, so a tampered file refuses to load. A strict Content Security Policy limits where scripts can load from and where they can send data. Neither is novel. They often stay off because vendors push updates without notice, and a pinned hash breaks the moment they do. That friction is the point. A vendor whose code can change under you without a version bump is a vendor you can’t audit. Polymarket’s own fix followed the same playbook: it redeployed its third-party scripts with version pinning, sandboxing, and a stricter content security policy.
Hygiene like this comes first. It just can’t see everything: a malicious browser extension, malware on a trader’s device, or a compromise of your own code can all slip past it. So the next layer has to sit somewhere else.
Continuous risk assessment catches what checkpoints miss
Most trust decisions cluster at the front door: sign-up, identity verification, login. This attack walked past that door because it was already open.
Trust shouldn’t be a checkpoint you clear once. It should be assessed continuously, so a change mid-session registers the moment it happens. A full liquidation of open positions. A withdrawal to an address the account has never used. A burst of actions faster than any human clicks. None of these needs a new gate. Each is a shift in a risk picture that’s already being assessed.
Regulated US sports betting has re-checked geolocation throughout the session for years. We’ve built on that: location, device, and behavioural signals stream passively all session and are scored for risk as they arrive, building a profile of each account.
A deviation from that profile is the signal: a new device, a location that doesn’t add up, a session acting out of character. Pair it with what you know about how the account trades, and a hijack stands out. Polymarket’s attacker ran inside traders’ own browsers. The pattern it left, selling positions and sending funds to an attacker’s wallet, is exactly what a behavioural profile is built to flag.
A session that suddenly behaves like someone else or a bot gets flagged the moment it changes, and you choose the response. Real traders keep trading.
Make the decision somewhere a script can’t reach
The principle behind client-side defence is simple: anything your page can do, a script inside your page can do too. So the strongest decisions get made where no script can reach.
Two principles follow:
- Collect signals that are hard to forge from inside the page, and evaluate them server-side. Device integrity, automation detection, true location, and a behavioural baseline for how this account normally behaves. When an attack runs inside the trader’s own browser, device and location confirm the real trader is there. Behaviour shows they aren’t the one acting.
- Make high-risk actions earn a response. Wherever an order or withdrawal passes through your own systems before it executes, a session that suddenly acts out of character should meet a response, not a confirmation. When the flag is high-confidence and the transaction is high-value, automate that response, such as an ID check or a hold.
None of this patches a compromised vendor. What it does is turn a silent drain into a flagged attempt.
Yes, we’re a vendor in the page too
A fair question at this point: isn’t GeoComply a vendor in the page too? It is. These are the questions we’d want every operator to ask every vendor in the critical path, starting with us:
- What exactly does your code execute in our page, and how is it pinned and versioned?
- Does any decision rely on trusting output from the client, or is it validated server-side?
- If your infrastructure were compromised tomorrow, what could an attacker do inside our users’ sessions?
- When your signals and ours disagree, who makes the final call, and who gets alerted?
- Who outside your company has audited those answers?
Good vendors answer these quickly. We expect to be held to the same bar.
Security and market integrity are the same question
Prediction markets face a second trust test alongside security. Regulators and the press are asking who is behind a trade, whether accounts are linked, and whether someone knows something they shouldn’t.
The signals that expose a hijacked session answer those questions too: the real device, the real location, the accounts that keep showing up together. Treat them as one shared set of signals instead of three separate budgets, and every check does three jobs.
What this means for leadership
For CEOs, general counsel, and risk leaders at prediction markets, and at the exchanges, brokers, and sportsbooks entering the category:
- Treat every third-party script like your own code. Inventory it, pin it, and give someone ownership of it.
- Assess risk continuously. Login proves who arrived. Continuous assessment catches the moment something changes mid-session, so you can respond to the risk in real time, before money moves.
- Connect security, AML, and market integrity. All three rely on the same signals: who’s really behind a session, where they are, and which accounts are linked. Run them separately and each team sees only part of the picture.
Prediction markets price the world’s uncertainty. Their future depends on removing uncertainty about the venue itself.
We’ve spent 15+ years on the regulated side of this problem, in markets where every transaction has to stand up to an auditor. If you’re mapping where these checks belong on your platform, we’re glad to compare notes.
Kip Levin | CEO, GeoComply
Kip Levin is CEO of GeoComply, the location- and device-based trust infrastructure running on 300+ million devices worldwide. He previously spent a decade in senior leadership at Flutter Entertainment, including serving as President and COO of FanDuel Group. Before that, he spent 12 years leading product and ecommerce at Ticketmaster. Kip on LinkedIn
