Introduction

Polymarket is the world's largest prediction market. With Polymarket you can bet on the outcome of future events in a wide range of topics, like sports, politics, and pop culture. Get accurate real-time probabilities of the events that matter most to you.

Severity and Rewards

Vulnerabilities are classified by Impact and Likelihood. The combination determines the severity and guides the reward amount.

Risk Classification Matrix

Severity Level	Impact: Critical	Impact: High	Impact: Medium	Impact: Low
Likelihood: High	Critical	High	Medium	Low
Likelihood: Medium	High	High	Medium	Low
Likelihood: Low	Medium	Medium	Low	Informational

Impact Definitions

Smart Contracts

Reward calculation

The tier sets the reward ceiling. It does not set severity. If direct theft is possible, the finding is Critical even when the affected contract sits in Tier 2, 3, or 4.

For a Critical finding, reward = min(applicable tier ceiling, max(tier Critical minimum, 10% of directly affected funds)). Apply the formula to every tier.

Directly affected funds

Directly affected funds are assets that the submitted root cause can steal, irreversibly lock, burn, mint without backing, or wrongfully pay under production-reachable conditions before practical remediation.

• Aggregate repeatable impact across all users and markets reachable through the same root cause.
• Count balances or approvals only where the proof shows the exploit can exercise them without a separate key compromise or an unrelated victim action.
• Do not count total protocol TVL solely because the vulnerable contract is reachable.
• For oracle bugs, count collateral payable by every condition the same root can resolve incorrectly.
• For ramps and adapters, use demonstrated concurrent or repeatable exposure, not annual flow volume.
• A multi-call exploit or ordinary composition through scoped contracts is still direct. The number of transactions or contracts in the path does not reduce demonstrated impact.

Impact inheritance

Where a Tier 2, 3, or 4 root gives the attacker Tier 1-equivalent reach, the Tier 1 ceiling applies. Examples:

• A shared wallet or beacon bug that reaches many deployed wallets.
• A fee-module bug that systematically drains makers through reusable approvals.
• An oracle-adapter bug reusable across many markets.
• A ramp or adapter bug repeatable against the backing reserve or global ledger.

One root receives one reward. Use the highest applicable tier and aggregate affected funds once. Rewards do not stack by contract or tier.

Web2

Severity	Description	Examples
Critical	Vulnerabilities that can lead to severe loss of user funds, permanent system disruption, or widespread compromise	- Execute arbitrary system commands - Retrieve sensitive data/files from a running server, such as: /etc/shadow, database passwords, blockchain keys (this does not include non-sensitive environment variables, open source code, or usernames) - Taking down the application/website - Supply-chain compromise or web cache poisoning that reaches a wallet connecting origin (any page that loads the trading interface, connects to or holds a user wallet, or sends script to a page that does) - Subdomain takeover when the subdomain is a wallet connecting origin (any page that loads the trading interface, connects to or holds a user wallet, or sends script to a page that does) - Showing a user an attacker-controlled deposit address - Direct theft of user funds - Malicious interactions with an already-connected wallet, such as: Modifying transaction arguments or parameters, Substituting contract addresses, Submitting malicious transactions - Injection of malicious HTML or XSS through metadata
High	Vulnerabilities that cause notable financial loss or significantly harm user trust, but on a lesser scale than Critical.	- Taking state-modifying authenticated actions (with or without blockchain state interaction) on behalf of other users without any interaction by that user, such as: Changing registration information, Commenting - Injecting/modifying the static content on the target application without JavaScript (persistent), such as: HTML injection without JavaScript, Replacing existing text with arbitrary text, Arbitrary file uploads, etc. - Improperly disclosing confidential user information, such as: Email address - Subdomain takeover when the subdomain is not a wallet connecting origin (any page that loads the trading interface, connects to or holds a user wallet, or sends script to a page that does)
Medium	Vulnerabilities that lead to limited financial damage or moderate system impact.	- Injecting/modifying the static content on the target application without JavaScript (reflected), such as: Reflected HTML injection, Loading external site data
Low	Findings that pose minimal direct risk but reflect areas for improvement or best practices.	- Changing details of other users (including modifying browser local storage) without already-connected wallet interaction and with significant user interaction, such as: Iframing leading to modifying the backend/browser state - Taking over broken or expired outgoing links, such as: Social media handles, etc. - Temporarily disabling user to access target site, such as: Locking up the victim from login, Cookie bombing, etc.

Payout

• Remote code execution, server side secrets, stay Critical but pay the minimum. The full range opens only if the report shows funds were lost.
• Pay 10% of the funds a bug could take, within the band.

In addition to the above definitions, we will also use the Cantina Bug Bounty Severity Classification Framework to determine severity.

Likelihood Definitions

• High: Very easy to exploit or highly incentivized.
• Medium: Exploitation is possible under certain conditions.
• Low: Difficult to exploit or requires very specific conditions.

Smart Contract Tier Rules

The following rules apply exclusively to Smart Contract Tiers 1-4 and do not apply to Web & App findings.

Proxy and beacon coverage

Every scoped proxy entry automatically includes:

• The proxy and its state.
• The implementation active when the report is submitted.
• Any implementation activated after discovery but before remediation.
• Initializer, storage-layout, delegatecall, and upgrade-authorization flaws affecting the proxy.
• For beacon systems, the beacon, forwarder, active default implementation, authorized legacy implementations, and deployed beacon proxies.

Legacy retirement

Unless Polymarket has informed Cantina that it is retired, a legacy deployment stays in scope while any of the following is true:

• It holds funds or positions.
• Users retain effective approvals to it.
• Production services still call it.
• Unresolved markets or redemptions depend on it.

Absent such notice, remove or lower it only after a signed retirement record confirms all four conditions are false or safely bounded.

Any legacy deployment or asset, including any funds held therein, is considered strictly out of scope as soon as Polymarket informs Cantina of its retirement, regardless of whether it is technically paused.

Future deployment activation

Newly deployed contracts enter scope at the time they are deployed and activated through a scoped proxy, beacon, registry, or production integration. This includes new oracle aggregators, reporter modules, implementations, and modules.

Addresses that exist only in configuration, or that are predicted but not yet deployed, are not in scope.

The scope will be updated to list each new contract under the tier that matches its authority and blast radius. Until it is listed, the contract is covered under this rule at the tier appropriate to its function.

Privileged paths

Compromise of a legitimate privileged key stays out of scope. An unprivileged bug that bypasses authorization, escalates into a privileged path, or lets an attacker replace an implementation stays in scope.

Prohibited Actions

• No Unauthorized Testing on Production Environments: Do not test vulnerabilities on mainnet or public testnet deployments without prior authorization. Use local test environments or private test setups.
• No Public Disclosure Without Consent: Do not publicly disclose details of any vulnerability before it has been addressed and you have received written permission to disclose.
• No Exploitation or Data Exfiltration: Do not exploit the vulnerability beyond the minimum steps necessary to demonstrate the issue. Do not access private data, engage in social engineering, or disrupt service.
• No Front-Running or MEV Exploitation: Do not use knowledge gained from vulnerability research to front-run transactions, extract MEV, or gain trading advantage on Polymarket or related markets.
• No Conflict of Interest: Individuals currently or formerly employed by Polymarket, or those who contributed to the development of the affected code, are ineligible to participate.

Disclosure Requirements

You must report vulnerabilities directly to the Spearbit/Cantina platform. Please include:

• A clear description of the vulnerability and its impact.
• Steps to reproduce the issue, ideally with a proof of concept (always need a proof of concept for smart contracts)
• Details on the conditions under which the issue occurs.
• Potential implications if the vulnerability were exploited.

Reports should be made as soon as possible—ideally within 24 hours of discovery.

Proof of Concept Requirements

• Smart Contract Critical/High: MUST include a working Foundry test on a local Polygon fork demonstrating the exploit. The PoC should clearly show: (a) the initial state, (b) the exploit steps, (c) the resulting impact (e.g., stolen funds, frozen state).
• Smart Contract Medium/Low: Written technical explanation of the attack path required. Foundry PoC encouraged but not required.
• Web/App Critical/High: MUST include step-by-step reproduction with screenshots or video.
• Reports without adequate PoC will be triaged at lower priority and may be downgraded in severity.

Eligibility

To be eligible for a reward, you must:

• Be the first to report a previously unknown, non-public vulnerability within the defined scope.
• Provide sufficient information to reproduce and fix the vulnerability.
• Not have exploited the vulnerability in any malicious manner.
• Not have disclosed the vulnerability to third parties before receiving permission.
• Comply with all Program rules and applicable laws.

You must also be of legal age in your jurisdiction and not be a resident in a country under sanctions or restrictions, as required by applicable laws.

Other Terms

By submitting a report, you grant Polymarket the rights necessary to investigate, mitigate, and disclose the vulnerability. Reward decisions and eligibility are at the sole discretion of Polymarket. The terms, conditions, and scope of this Program may be revised at any time. All participants are responsible for reviewing the latest version before submitting a report.