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.
Understanding the Data

Smart Money Methodology

In Progress Last updated 2026-03-10

The current holder-count logic behind PolyLab Smart Money context, including the exact PnL-sign rules and the hard limitations of the sampled data.

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.

What Smart Money means in PolyLab today

In the current implementation, Smart Money is a descriptive enrichment layer built from sampled holder rows and wallet PnL sign. It is not a model of informed flow, not a prediction engine, and not a complete reconstruction of market positioning.

Current count logic

The scanner computes counts by joining holder rows with wallet stats and applying simple sign rules:

  • profitable means ws.total_pnl > 0
  • losing means ws.total_pnl < 0

That produces fields such as:

  • yes_profitable_count
  • yes_losing_count
  • yes_total
  • no_profitable_count
  • no_losing_count
  • no_total

Outcome-specific semantics

For a YES row:

  • min_profitable checks holder rows on YES where ws.total_pnl > 0
  • min_losing_opposite checks holder rows on NO where ws.total_pnl < 0

For a NO row, the opposite-outcome logic flips accordingly through 1 - amo.outcome_index.

Source limits matter

Top 20 holders per outcome

The current holders client caps the effective sample to top 20 holders per outcome. Even when the scraper requests a much larger limit upstream, the client reduces it to a per-outcome maximum of 20 and re-sorts locally.

This is the single most important caveat in the smart-money layer.

Wallet PnL is a separate source

Wallet profitability is not inferred from the market itself. It comes from a separate wallet-PnL API and is then joined back onto sampled holder addresses.

smart_money_win_rate is not a current public filter

Background jobs still compute a smart_money_win_rate value into market_smart_money_stats, but that field is not exposed as a live public scanner filter in the current app contract. Public docs must not describe it as an active user-facing control.

Known data anomalies

  • a profitable wallet can be profitable for reasons unrelated to the current market
  • a losing wallet can still be directionally correct here but wrong elsewhere
  • the same wallet may hedge or net across venues
  • aliases may be missing or stale
  • holder sampling may miss smaller but relevant wallets
  • a system wallet can appear in the data, and PolyLab marks a known system wallet explicitly

system wallet

PolyLab currently inserts a known rewards/system wallet and tags it with wallet_tag = SYSTEM. This is useful for operational transparency, but it is not evidence of directionality.

Do not treat Smart Money counts as proof

Use the counts as context only:

  • they can help you find markets worth opening
  • they can help you compare sides inside the same market
  • they cannot validate a trade by themselves