This paper assesses the security surface a professional participant inherits by trading Polymarket through its public interfaces. It covers the settlement chain, the collateral and position primitives, the matching venue, wallet custody, API credentials, the gasless relayer, and outcome resolution. It is written from public primary sources only: Polymarket's published developer documentation, the two ChainSecurity audit reports Polymarket has made public, CFTC filings and orders, and dated reporting on the incidents discussed.

• Desk review of public documentation and published audit reports — not a penetration test, code review, or independent verification of deployed bytecode.
• No non-public material, no vendor questionnaire response, and no privileged communication was used.
• Audit findings are reported exactly as the auditor classified and resolved them; no severity has been re-rated here.
• Where a control is undocumented publicly, this paper says so rather than assuming it exists.

The most common institutional error with Polymarket is treating it as a single counterparty. It is not. Collateral safety, execution integrity, credential safety and payout correctness each rest on a different party and fail in a different way. A control that protects one does nothing for the others.

┌──────────────────────────────────────────────────────────────┐
   │  Trader / institution                                        │
   │  signer key  ·  L2 API credentials  ·  relayer API key       │
   └──────────────┬───────────────────────────────────────────────┘
                  │ EIP-712 signed order (never a custody transfer)
   ┌──────────────▼───────────────────────────────────────────────┐
   │  Off-chain CLOB  clob.polymarket.com                         │
   │  price/time priority · operator may match, may not mint      │
   └──────────────┬───────────────────────────────────────────────┘
                  │ settle matched, signed orders
   ┌──────────────▼───────────────────────────────────────────────┐
   │  Polygon PoS                                                 │
   │  CTF Exchange  ──  Conditional Tokens (ERC-1155)             │
   │                    collateral: USDC.e, 1:1 escrowed          │
   └──────────────┬───────────────────────────────────────────────┘
                  │ payout vector
   ┌──────────────▼───────────────────────────────────────────────┐
   │  UMA Optimistic Oracle                                       │
   │  propose ($750 bond) → challenge window → token-holder vote  │
   │  ← this is the layer that has actually failed in production  │
   └──────────────────────────────────────────────────────────────┘

Polymarket settles on Polygon PoS. Positions are ERC-1155 conditional tokens issued by the Gnosis Conditional Tokens Framework and collateralised in USDC.e. Minting a complete set of outcome tokens requires depositing the full notional; redeeming a complete set returns it. Because every outstanding share is backed one-for-one by escrowed collateral in the contract, venue solvency is a property of the code path rather than of an operator's balance sheet — there is no fractional-reserve position for the venue to take.

• Collateral sits in the conditional-tokens contract, not in an operator-controlled omnibus account.
• Positions are standard ERC-1155 tokens: transferable, independently custodiable, and visible on a public chain without asking the venue for a statement.
• Chain-level risk — validator liveness, congestion, reorg depth, bridged-asset risk on USDC.e — is inherited from Polygon and is not controlled by Polymarket.
• Public settlement is a control in itself: an institution can reconcile its own positions against chain state rather than against a venue-supplied report.

Polymarket runs a hybrid model: the central limit order book operates off-chain at clob.polymarket.com for latency, while matched trades settle on-chain through the exchange contract. Orders are EIP-712 typed-data signatures. The operator's power is therefore bounded — it can decline to match, delay, or fail to include an order, but it cannot settle a trade the account did not sign, and it cannot move collateral outside a signed order.

ChainSecurity assessed the exchange and governance contracts and published its report dated 3 November 2022. Its executive summary states that the contracts show a high level of functional correctness, handle signatures correctly, and that the codebase provides a high level of security. The finding counts and dispositions are reproduced below exactly as published.

• Audit scope was the exchange and governance components, assessed at specified commits — not the whole platform, and not the off-chain matching infrastructure.
• The report explicitly notes that audits are time-boxed and cannot uncover all vulnerabilities.
• One low-severity finding is recorded as risk accepted and one as acknowledged; neither was code-corrected.
• Off-chain components — matching, APIs, relayer, front end — are outside the published audit scope, so integrators should assume no third-party assurance over them.

Polymarket accounts are smart wallets. The documentation identifies three types: the Deposit Wallet, the default smart wallet used by all account wallets deployed on or after 4 May 2026; the legacy Proxy Wallet created through Magic Link or Google authentication on polymarket.com; and the legacy Safe wallet created with an external signer such as MetaMask or Rabby. ChainSecurity assessed the two proxy wallet factories in a report dated 11 April 2024, covering functional correctness, signature handling and Gas Station Network interaction, and concluded that the codebase provides a high level of security.

• For a Magic Link or Google-derived legacy proxy wallet, the practical attack surface is the email or Google account, not the chain. Compromise of that identity is compromise of the trading account.
• For institutions, an external signer under existing key-management policy — hardware custody, quorum approval, defined rotation — puts custody inside controls you already audit.
• Gasless operations are authorised by a Relayer API key with a named signer address; that key is a live capability and must be inventoried and rotated like any other production credential.
• Contract-level assurance from the factory audit does not extend to the identity provider, the browser session, or the operator's front end.

Polymarket exposes separate surfaces for discovery (gamma-api), trading (clob), analytics (data-api) and gasless wallet operations (relayer-v2), plus public and authenticated WebSocket streams. Public market data requires no credentials. CLOB authentication is explicitly two-layer: an L1 layer using a private-key signature, and an L2 layer using API-key credentials for routine authenticated requests.

• Separate the layers operationally: the L1 signing key is a custody-grade secret; L2 API credentials are operational secrets with a shorter, enforced rotation cycle.
• Read paths (market data, positions, activity) should run on credentials that cannot place or cancel an order. Do not reuse a trading credential for analytics.
• Hold credentials server-side only. A key that reaches a browser bundle, a mobile binary, or a log line is already disclosed.
• Public endpoints need no credential — never attach one to a request that does not require it.
• Instrument authenticated WebSocket order and trade streams as a live control: an unexpected fill on a stream you did not originate is your fastest takeover signal.
• Reconcile independently. Chain state and the data API are two views; disagreement between them is an incident, not a formatting issue.

Outcomes are resolved by UMA's optimistic oracle. Anyone may propose a resolution by staking a $750 USDC.e bond. If nobody disputes it within the challenge window, the proposal stands. If it is disputed, UMA token holders vote to settle the matter. The mechanism is economically secured by the value of stake, which makes it a governance surface, not a data feed.

In March 2025 that surface was captured. A market on whether Ukraine would agree to a minerals deal with the U.S. before April saw its 'yes' probability move from 9% to 100% between 24 and 25 March despite no agreement having been reached, and resolved 'yes' with more than $7 million of open interest. Reporting traced the outcome to a large UMA holder — a top-five governance staker with roughly 1.3 million UMA tokens by on-chain data, with reporting citing accounts holding as much as five million tokens — voting through a premature resolution. Polymarket called the situation unprecedented, stated on Discord that because this was not a market failure it was unable to issue refunds, and said it would build monitoring and systems so that it does not repeat.

• The trade was correct and the payout was wrong. No smart contract failed, no key was stolen, and no refund followed. Contract-level assurance does not cover this.
• Resolution risk scales with the value of governance stake required to swing a vote, not with the size of your position — a small market can be captured cheaply.
• Ambiguous, subjective or source-dependent questions carry materially more resolution risk than mechanically verifiable ones.
• Read the resolution criteria and the named settlement source before sizing, and treat vague criteria as a risk premium rather than an edge.
• Monitor the proposal and challenge window on markets where you hold size; the dispute path is time-bounded and only useful if you are watching it.
• Cap per-market exposure on subjective questions independently of your overall book limits.

The security consequence is structural, not cosmetic. A CFTC-designated contract market operating an intermediated venue is subject to core-principle obligations including market surveillance and recordkeeping, which is a different control regime from a permissionless on-chain book resolved by token vote. Institutions should establish which entity and which venue any given order is routed to, because the counterparty, the resolution mechanism and the available recourse differ between them.

• Assume no third-party assurance exists over any off-chain component; act as if the operator's availability is best-effort.
• Keep an independent record of every order you signed. Signature-level records are the only evidence that survives a dispute with any venue.
• Rehearse credential revocation before you need it, and measure how long it actually takes end to end.

• ChainSecurity — Code Assessment of the Exchange Smart Contracts, produced for Polymarket, 3 November 2022 (finding counts and dispositions, executive summary conclusions).
• ChainSecurity — Code Assessment of the Proxy Wallet Factories Smart Contracts, produced for Polymarket, 11 April 2024 (scope: functional correctness, signature handling, Gas Station Network interaction).
• Polymarket Documentation — Wallets and Authentication (wallet types, deployment date boundary, Relayer API keys).
• Polymarket Documentation — API (integration surfaces, public data access, two-layer CLOB authentication, WebSocket streams, relayer-v2 gasless submission).
• CFTC Release 8478-22, 3 January 2022 — $1.4M civil monetary penalty against Blockratize, Inc. d/b/a Polymarket.
• CFTC Industry Filings — Designated Contract Markets, filing 49571: QCX LLC d/b/a Polymarket US, designated 9 July 2025.
• CFTC — Polymarket US Amended Order of Designation (petition to remove the FCM intermediation restriction; surveillance representations).
• CoinDesk, 26–27 March 2025 — UMA governance attack coverage: top-five staker, ~1.3M UMA, $7M Ukraine minerals market, Polymarket's no-refund position.
• The Defiant, 27 March 2025 — premature resolution traced to an oracle whale; reporting of up to five million governance tokens across accounts.
• PR Newswire / CoinDesk, 21 July 2025 — Polymarket acquires CFTC-licensed exchange and clearinghouse QCEX for $112 million.