How a Belphor signal's outcome is measured

Updated 3 October 2026 · by AtroX · Belphor Research · the data behind this guide

Every signal is measured against its price at detection: "reached +X%" uses the highest price seen after it, "down 80% or more" uses the most recent price reading taken at least six hours after it, and, where a table applies the ten-reading rule, a share computed over fewer than ten such readings is printed as "too few readings" instead of a number. The six tables at belphor.com/data are recomputed daily from the raw record; this page describes their method as it stood on 3 October 2026.

The reference price

Every outcome starts from one price: the price at detection. For a takeover it is the price when the takeover instruction executed, for a migration the price when the new pool appeared, for an ignition the price when the scanner found the pool. Every multiple on the data pages, a peak of 1.56x or a latest reading of 0.50x, is a later price divided by that one. Prices come from Belphor's own snapshot record of DexScreener pair data.

"Reached +X%": the peak

A signal reached +50% when the highest price observed after detection was at least 50% above the detection price. The peak says the coin traded there at some point. It does not say a buyer could have sold there, and it says nothing about where the coin ended, which is why every table that prints a peak also prints a later reading.

"Down 80% or more", and why it is not "went to zero"

A signal is down 80% or more when its most recent price reading, taken at least six hours after detection, was 20% of the detection price or lower. On the ignition table a pool that drained below $1k of liquidity counts as zero. Until 23 September 2026 the same column was labelled "went to zero"; the label changed because the measure never was zero. A coin at 0.19x of its detection price, the median latest reading of the takeovers between $15k and $50k as of 3 October 2026, is down 80% or more without being at zero.

Covered: which signals have a later reading

A signal is covered when Belphor holds a price reading for it at least six hours after detection. Every "down 80% or more" share is computed over covered signals only, and the covered count is printed beside it in the "With a later reading" column. Where coverage is partial the share describes the covered coins, not the whole set: on the takeover table, 22 of 352 takeovers are covered, so the share down 80% or more describes only the 22 covered coins. The other 330 have no qualifying later reading, so the rate for all 352 is unknown. For CTO outcomes, peak rates use the eligible takeover count. The weekly page computes its rates over covered signals. Use the denominator stated by each table.

The ten-reading rule, and why the JSON prints null

Some outcome rates are suppressed below ten qualifying observations. This is not a universal rule across the six tables: time-to-peak distributions include smaller samples. Read each table's denominator and suppression rule. Where the rule applies, the page shows "too few readings" in that cell, the CSV leaves it empty beside the covered count, and the JSON prints null for the rate. The JSON keeps the raw share under a key of the same name ending in _raw, so the arithmetic stays checkable, and the file says plainly that it is not an estimate. Belphor's guides never quote a _raw value.

When two rows differ: the thirty rule

The data pages compare two rows in words only when both rows hold at least 30 signals and their shares differ by more than two points. Otherwise the page says "the record does not separate them", whatever the numbers look like. Every guide built on these tables uses the same rule, which is why the entry-timing guide, on twelve takeovers, separates nothing.

What gets left out

Demo and test rows are excluded everywhere. A radar signal is excluded when its price cannot be verified: a market cap above $250M at detection, or a peak of 100x or more with no matching price snapshot in the record. The count of excluded rows is printed under each table it would have changed. Periods when part of the detection was not recording or not alerting are written into a detection record on the pages they affect, so a gap in a table is never silent.

The six tables

Fetched from the public JSON of each page on 3 October 2026. Every page is recomputed daily from the raw record; this table is a dated snapshot of their samples.

Reproducing a number

Each page carries a "Cite as" line with its formula version, the first characters of an input hash, and the covered and missing counts. The weekly page also freezes the source row ids and the values it read, and hashes them into that line, so any week can be reproduced after the fact. Every page has a JSON and a CSV twin with the same numbers, under a CC BY 4.0 license: reuse them with attribution to Belphor.

What the method does not do

It does not measure trades. A detection is not an entry: a real buyer arrives later, pays network and platform fees and slippage, and exits by a rule that may sell long before the peak or long after it. The cost side is in crypto trading fees explained, and testing a rule against live prices before risking money is in paper trading crypto. The guides built on this method: takeover success rate, entry timing, time to peak, migration outcomes, death rate by pool age and the score against outcomes.