PolyLab PolyLab Docs Independent analyzer for Polymarket
Documentation is in progress. Every page in this section describes the current implementation and may change as PolyLab evolves.
Start Here

How PolyLab Works

In Progress Last updated 2026-03-10

A high-level walkthrough of the current PolyLab data flow, from Polymarket upstream APIs to scanner rows and holder-based enrichment.

Current Implementation

This page is intentionally explicit and implementation-first. If the product or upstream APIs change, the current behavior described here can change with them.

End-to-end overview

PolyLab is built around a periodic data pipeline:

  1. Fetch active Polymarket markets and events from the Gamma API.
  2. Normalize them into outcome-level rows in SQLite.
  3. Enrich those rows with tags, category, icon, event slug, and canonical Polymarket URL.
  4. Periodically fetch holder lists for each condition and wallet PnL for the wallets seen in those holder lists.
  5. Compute derived display fields such as APR, implied odds, and counts-based smart-money context.
  6. Serve the current snapshot through /api/markets, /api/tags, /api/status, and /api/markets/{market_id}/holders.

Why the system is snapshot-based

The scraper fetches the active market set, writes a fresh active_market_outcomes snapshot, and re-creates indices around that snapshot. This design favors a simple and predictable read path for the scanner over continuous tick-level updates.

The tradeoff is important:

  • reads are simple and cheap
  • the scanner can stay fast on static hosting plus a small FastAPI backend
  • the displayed state is not a live feed

What comes directly from Polymarket

PolyLab directly reuses upstream values such as:

  • market question
  • outcomes and outcome prices
  • spread
  • volume
  • liquidity
  • start and end dates
  • event slug and images when available
  • event tags

These are documented in detail in Markets and Events Source.

What PolyLab computes

PolyLab also computes or derives several fields locally:

  • per-outcome rows from a market-level payload
  • Polymarket event URL from the resolved event_slug
  • primary category from the first available event tag
  • APR from current price and time remaining
  • implied odds as 1 / price
  • counts of profitable and losing holders per YES / NO side
  • refresh timestamps shown in the UI

What Smart Money means here

In the current implementation, Smart Money is not a proprietary predictive model. It is a descriptive layer built from:

  • top holder rows from the holders endpoint
  • wallet PnL values from the wallet-PnL endpoint
  • simple PnL-sign logic such as total_pnl > 0 and total_pnl < 0

That means Smart Money fields are best read as contextual counts, not as proof of informed positioning.

Where to go deeper