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

Impact	Description	Examples
Critical	Vulnerabilities that can lead to severe loss of user funds, permanent system disruption, or widespread compromise	- Manipulation of governance voting result deviating from voted outcome and resulting in a direct change from intended effect of original results - Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield - Permanent freezing of funds - Protocol insolvency - Unauthorized minting or burning of CollateralToken (pUSD) leading to collateral de-pegging or unbacked positions - Bypassing oracle resolution (UmaCtfAdapter/NegRiskUmaCtfAdapter) to force incorrect market outcomes, resulting in wrongful payouts from ConditionalTokens - Exploiting the UUPS upgrade mechanism in CollateralToken to inject a malicious implementation - Unauthorized position splitting/merging/redeeming in NegRiskAdapter or ConditionalTokens leading to extraction of collateral not owed to the attacker - Exploiting FeeModule fee calculation (CalculatorHelper) to systematically extract funds from makers during order matching - Bypassing ERC1155 partition validation in ConditionalTokens.splitPosition() to mint unbacked position tokens (e.g., collection ID collision via ECMH) - Exploiting PermissionedRamp witness signature verification to wrap/unwrap collateral without authorization
High	Vulnerabilities that cause notable financial loss or significantly harm user trust, but on a lesser scale than Critical.	- Temporary freezing of funds - Theft of unclaimed yield or accumulated protocol fees (e.g., from Vault or FeeModule/NegRiskFeeModule) - Permanent denial-of-service to specific market operations (order matching, position conversion, collateral wrapping/unwrapping) without direct fund loss - Bypassing signature verification (any of the 4 types: EOA, POLY_PROXY, POLY_GNOSIS_SAFE, POLY_1271) to execute unauthorized orders on behalf of users, without resulting in direct fund theft - Circumventing the UserPausable mechanism in CTFExchangeV2 to trade on behalf of a paused user - Manipulating FeeModule fee refund calculations to systematically overcharge users beyond their signed feeRateBps limit - Exploiting NegRiskOperator to flag/unflag questions in a way that disrupts market resolution without causing incorrect payouts - Bypassing NonceManager to replay cancelled orders that result in unintended fills
Medium	Vulnerabilities that cause limited financial damage, temporary disruption to protocol operations, or degraded functionality without direct fund loss.	- Temporary griefing of specific market operations (order matching, position conversion) lasting more than 1 hour but less than 24 hours - Gas consumption attacks forcing significantly elevated operational costs for the protocol or users - Incorrect event emission leading to off-chain system desynchronization (e.g., wrong OrderFilled/OrdersMatched/FeeCharged events causing CLOB state mismatch) - Logic errors in CalculatorHelper fee calculation that produce small but systematic over/under-charges not catchable by existing validation - Bypassing NonceManager to replay cancelled (but not filled) orders under narrow conditions without significant fund impact - Temporary inability to process specific order types or match types (COMPLEMENTARY, MINT, MERGE) - Incorrect payout precision/rounding in ConditionalTokens.redeemPositions() leading to small systematic over/under-payments - Exploiting CollateralOnramp/CollateralOfframp pause mechanism to block wrapping/unwrapping for specific assets
Low	Findings that pose minimal direct risk but represent deviations from intended behavior, defense-in-depth weaknesses, or minor specification violations.	- Missing input validation that does not lead to fund loss but deviates from specification - Events emitting incorrect or incomplete data without direct financial or operational impact - Non-critical access control improvements (e.g., functions that should be restricted but have no harmful effect when called by unauthorized parties) - Order validation edge cases that produce unexpected but non-exploitable states - Minor deviations between documented and actual contract behavior - ERC1155 callback edge cases in ConditionalTokens that don't lead to reentrancy or fund loss - Incorrect view function return values that don't affect on-chain state

The following are explicitly excluded from Critical severity:

• Issues in the Gnosis ConditionalTokens contract that do not arise from Polymarket's specific integration patterns or usage (e.g., generic CTF bugs affecting all users of the framework)
• Centralization risks from admin/operator key compromise (see "Out of Scope — All Categories")
• Oracle manipulation that requires compromising UMA's DVM or dispute resolution system itself, rather than exploiting Polymarket's adapter logic

The following are explicitly excluded from High severity:

• Temporary DoS lasting less than 1 hour that self-resolves without intervention
• Issues requiring compromised admin/operator private keys as a prerequisite (see "Out of Scope")
• Fund freezing that affects only the attacker's own funds

The following are explicitly excluded from Medium severity:

• Issues that only affect a single user's own funds through their own actions
• Gas inefficiencies without security impact
• Theoretical MEV extraction below $1,000 in value
• Temporary disruptions lasting less than 1 hour

The following are explicitly excluded from Low severity:

• Best practice recommendations without demonstrated impact
• Gas optimization suggestions
• Code style or readability issues
• Issues in test files or deployment scripts
• Informational findings about known design tradeoffs (e.g., single oracle per condition)

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 - Subdomain takeover with already-connected wallet interaction - 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 without already-connected wallet interaction
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.

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.

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.