Documentation is in progress. Every page in this section describes the current implementation and may change as PolyLab evolves.
Pipeline

Refresh, Storage, and Snapshots

In Progress Last updated 2026-03-10

The current coordinated refresh pipeline, table roles, and snapshot lifecycle behind the public scanner.

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.

Coordinated refresh cycle

The project runs a coordinated refresh job:

  1. scrape market and event data
  2. write a fresh market snapshot
  3. optionally run smart-money enrichment if the 6-hour interval has elapsed

The smart-money step only runs after a successful scrape.

Cadence

JobCurrent cadencePurpose
Market scrapeEvery 60 minutesRefresh active market snapshot and tags
Smart-money enrichmentEvery 6 hoursRefresh holders and wallet-PnL context

Snapshot replacement rules

The scraper drops and rebuilds:

  • active_market_outcomes
  • market_tags

This means each scrape creates a clean active snapshot instead of incrementally updating old rows.

Storage tables

TableRole
active_market_outcomesMain outcome-level market snapshot
market_tagsTag rows attached to market ids
holdersSampled holder rows keyed by condition id
wallets_statsWallet-level PnL and alias data
market_smart_money_statsBackground smart_money_win_rate storage and timestamp
request_logsAPI request timing logs in the metrics database

How holders are refreshed

For each distinct condition_id in the active snapshot, PolyLab fetches holders, deletes prior holder rows for that condition, and inserts the new sampled rows with a fresh snapshot_at.

How wallet stats are refreshed

PolyLab extracts unique wallet addresses from sampled holder rows, fetches wallet PnL, and upserts into wallets_stats.

What survives between scrapes

The smart-money-related tables are not dropped on every market scrape. They are updated by the smart-money job and can therefore be newer or older than the market snapshot depending on job timing.

Why this architecture was chosen

The current design keeps the read path straightforward:

  • the app reads from a compact snapshot table
  • tag logic stays simple
  • holder and wallet enrichment can be refreshed on a slower schedule

The cost is that PolyLab is a snapshot system, not a live state mirror.