PolyLab Docs | APR Methodology

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.

Exact formula

The current implementation computes APR with the formula:

((1.0 / price) - 1.0) * (365.0 / days)

Where days is the positive number of days between the current snapshot time and end_date.

Preconditions

APR is only computed when price is greater than 0 and less than 1.

The backend also requires:

end_date is present
snapshot_at is present
end_date is later than snapshot_at

If those conditions do not hold, APR stays null.

When APR is null

APR is intentionally null when:

price <= 0
price >= 1
the market has no usable end date
the market is expired at the snapshot time
the date math fails to produce a positive duration

Why the formula looks this way

The formula expresses a simple annualized return from buying an outcome at price and assuming a terminal payout of 1.0 if that outcome resolves correctly. It is a ranking heuristic, not a simulation of fees, slippage, or partial exits.

Short-duration annualization can overstate weak setups

APR gets mechanically larger as days gets smaller. A market with only a few hours left can show a very large annualized number even if the real-world trade is mediocre or difficult to execute.

This is why APR should almost never be read alone. Pair it with:

spread
liquidity
expiry
market structure

Storage versus fallback computation

The scraper writes APR into active_market_outcomes during snapshot creation. The API also contains a fallback APR expression so older database snapshots without an apr column can still serve the field.

Interpretation guidance

Use APR as a sorting aid, not as a proof of value.
Ignore APR on rows that are obviously too close to expiry to execute comfortably.
Treat APR as especially fragile in thin markets and long-shot markets.

APR Methodology