Module 01 · Prediction Markets 101

Polymarket Fundamentals: Markets, Shares, and Resolution

20 minfocused lesson0copyable prompts3completion checks4source links

Open lesson + course map

On this lesson

Course outline

Module 1 · Prediction Markets 101

How Prediction Markets Price Information Polymarket Fundamentals: Markets, Shares, and Resolution Reading Order Books Without a Finance Background

Module 2 · Market Research

Building a Source-Verified Event Research Desk Using LLMs to Summarize Events Without Inventing Facts Building a Personal Watchlist of Tracked Markets

Module 3 · Signal Aggregation

Designing a Multi-Source Signal Pipeline Weighting Signals by Source Reliability Using Python to Aggregate and Score Signals Automatically

Module 4 · Paper Decision Logic

Paper Exposure Limits and No-Action Rules Precommitted Paper Entry and Exit Rules Logging Simulated Decisions for Honest Review

Module 5 · Risk and Responsible Research

Loss Budgets and No-Trade Rules in Paper Simulation Avoiding Common Beginner Losses and Overconfidence Traps Capstone: Build a Signal-to-Paper-Decision Workflow

Understand Polymarket by separating an event, a market, outcome tokens, order-book trading, and resolution. This is a read-only conceptual lesson. Platform architecture, terms, availability, fees, and restrictions can change; verify official documentation on the access date.

// concept

Markets and Events

In current Polymarket documentation, a market is a binary question with Yes/No outcomes, while an event can group one or more related markets. Identifiers such as slugs, condition IDs, question IDs, and token IDs serve different technical purposes. Do not join datasets by a display title alone.

The current CLOB documentation describes off-chain order matching and on-chain settlement. That architecture does not remove market, smart-contract, wallet, custody, bridge, stablecoin, operational, legal, or user-error risk. This course does not instruct wallet or order setup.

// concept

Resolution Is Part of the Product

Before interpreting a market, save:

exact question and description;
resolution source and rules;
end/close date and timezone;
conditions for Yes, No, invalid/other outcomes where applicable;
dispute/process information;
current active/closed/resolved state;
retrieval timestamp and source URL.

Words such as “official,” “announced,” “takes office,” “reaches,” or “by” can control settlement. A forecast about the real-world event can differ from a forecast about how a contract will resolve.

// concept

Shares and Prices

Outcome tokens represent conditional claims under the platform’s mechanism. Displayed prices can be read as market-implied probabilities only with caveats. A user who paid a price does not automatically realize the simple difference from a unit payout: fees, spread, slippage, timing, invalidation, and other costs/risks may apply.

For analysis, avoid calculating hypothetical returns unless the contract, fee, and execution assumptions are explicit. Prefer calibration and market-structure questions over “how much could I make?”

// concept

Use Read-Only Data

Public methods can provide markets, order books, prices, and spreads without authenticated trading credentials. Read-only access is still subject to platform terms and rate limits. Cache responsibly, identify your client where required, and never evade geographic restrictions or access controls.

Pin fields because APIs evolve. Store raw response, retrieval time, endpoint/version information, and a normalized table. Treat status transitions and resolution changes as events rather than overwriting history.

// worked_example

Worked Example

An event page groups four candidate markets. A researcher mistakenly treats each Yes price as exclusive probabilities summing to one. The contract structure may not support that shortcut. The corrected note reads each market/rules, observes individual order books, and labels any sum only as an exploratory diagnostic.

// failure_cases

Failure Cases

7 cases to diagnose

Treating an event container as one binary market.
Joining by title instead of stable identifiers.
Ignoring resolution source and contract wording.
Presenting gross payout arithmetic as guaranteed return.
Assuming on-chain settlement eliminates operational/legal risk.
Using authenticated order endpoints in a research lesson.
Circumventing availability or rate limits.

// pakistan_angle

Pakistan Angle

Polymarket’s current geographic page should be checked, but absence from a restricted list is not legal advice or a regulator approval. Pakistan’s PVARA framework and SECP warnings should be checked on the research date. Do not fund, promote, intermediate, or advise on a virtual-asset service without qualified compliance review.

Learners can complete the full lesson using public documentation and a spreadsheet. No real funds, identity documents, wallet, VPN, or geoblock check is required.

// hands_on

Hands-On Exercise

Choose one event and map event ID/slug, child markets, questions, token/outcome labels, dates, resolution rules/source, status, and read-only price fields. Save a sanitized raw response or screenshot and a normalized table. Do not authenticate or place an order.

// completion_rubric

Completion Rubric

3 grading bands

Complete
event/market/token/resolution concepts and stable identifiers are correctly mapped with timestamps.
Needs revision
the market is understood but structure, status, or resolution details are incomplete.
Not complete
real trading credentials, circumvention, or guaranteed-return language appears.

// sources

Sources

4 official sources — check every claim yourself