Methodology

1. Where calls come from

We track an approved list of public callers. Today that means public Telegram channels, read through Telegram's public web preview (t.me/s/<channel>) without logging in. A scheduled pass runs about every 30 minutes: it reads the newest page of each channel (a few pages the first time we see one), stores new posts, extracts calls, fetches prices, re-labels outcomes and recomputes scores. Reposts of identical text from the same channel are stored once. We count every call we capture, winners and losers, including calls the caller later deletes.

Callers added by visitors. Anyone can add a public Telegram channel from the leaderboard or Check. We check it automatically on the spot: it must have a public preview, a post in the last 3 weeks, and at least 3 of its newest posts must name a token or contract address. Bot, tracker and trending feeds are turned away. Channels that pass are tracked like the rest from that moment on, are marked "Added by the community", and rank only after enough scored calls. Calls made before we started tracking are not backfilled beyond the newest few pages.

2. Reading a post

A post becomes a call when it names something tradable and says, or clearly implies, to buy or sell it. Four kinds count as calls: trade signals, conditional signals, directional calls and memecoin calls.

• Pre-filter. Posts that name nothing we could price (no $TICKER, #TAG, XXXUSDT pair, contract address, major coin name, or pump.fun / DexScreener / Birdeye link) are skipped as chatter.
• Rules first for memecoins. Memecoin callers often post a bare contract address. A rule-based extractor reads those as memecoin calls (always long). When the rules see a memecoin call, we use the rules.
• Language model for the rest. Other posts are classified and extracted by a large language model (currently Google Gemini): the instrument, direction, and any entry, stop and targets.
• Second look. Posts the model filed as non-calls are re-checked by the rules, and reclassified as memecoin calls when the rules find one.
• Edits. If a post is edited after we stored it, we keep scoring the original text and flag the call as edited.

3. Price data

• Listed coins and perpetuals (for example BTCUSDT-PERP): hourly candles from Binance public market data, using the spot USDT pair as the reference price. Coins not listed on Binance spot are not priced this way.
• DEX tokens (a contract address): the most liquid pool from DexScreener, and hourly candles for that pool from GeckoTerminal (Solana, Ethereum, Base, BSC, Arbitrum and Polygon).
• Price snapshots. On each pass we also record the current DexScreener price of every memecoin called in the last 14 days, as a single point (open = high = low = close). These points fill gaps when hourly candles are missing or late. Pairs quoted in SOL, ETH or BNB are converted to USD with Binance spot prices.

So for most calls our price history has one point per hour, plus a snapshot roughly every 30 minutes for recent memecoins. We do not see every trade or the exact intra-hour path.

4. Labelling an outcome

Each call is evaluated at five horizons: 15m, 1h, 4h, 1d and 1w after the post. For a horizon, we take every price point whose start time is at or after the post time and no later than post time plus the horizon.

• No price points in the window: insufficient_data. This is common at 15m, because hourly candles start on the hour and snapshots come about every 30 minutes.
• The start price is the open of the first point in the window, which can be up to an hour after the post. The end price is the close of the last point in the window.
• The return is measured in the call's direction: a short call gains when the price falls.

Calls with an entry and a stop are judged as a trade. The entry is the midpoint of the stated entry range. If the price never trades through the entry in the window, the call is unresolved. Once the entry is touched, we go through the price points in time order, starting with the one where the entry was touched, and look for the first one that reached the first target or the stop. Whichever came first decides the call: the first target makes it a win and the stop makes it a loss, and anything that happens afterwards is ignored. If neither is reached, the label follows the return from entry to the last close, as in section 6. The result in R (multiples of the distance from entry to stop) is measured at the exit price: the stop, the first target, or the last close. We also record the best and worst excursion in the window. Same-candle rule: with hourly data, a single price point can touch both the target and the stop, and we cannot tell which came first. In that case we assume the stop came first and label the call a loss at −1R. This is the conservative choice: it never gives the caller a win we cannot prove.

All other calls are judged as an event study: the move from the start price to the end price. Memecoin calls get the labels in section 5; everything else gets the labels in section 6.

5. Memecoin labels

For a memecoin call, we compare the highest price in the window to the start price (the peak multiple) and the last price to the start price (the terminal multiple). The first rule that matches wins, except that a 2x or 5x reached before a collapse beats rugged and dead (see "Order of events" below):

A 2x or 5x hit means the price touched that level at some point in the window, measured from our start price. It does not mean a follower could have sold there: the peak may have lasted seconds and liquidity may have been too thin. We also record the time it took to reach 2x.

Order of events. When a token both reached 2x and crossed the rugged or dead level in the window, the label follows what happened first, using the price points in time order. A call that hit 2x and only later went to zero is a 2x_hit (or 5x_hit, counting only the peak before the collapse); a call that collapsed first is rugged or dead. If the 2x and the collapse happen within the same price point, we cannot tell the order and count the collapse first. For a liquidity rug, we assume the liquidity was pulled right after the last healthy liquidity reading, so the 2x only counts if it was complete before that reading.

6. Directional labels

For other calls without a resolved target or stop, the label follows the return in the call's direction:

• win: +0.25% or more;
• loss: −0.25% or less;
• neutral: in between.

The ±0.25% band is narrow on purpose (we judge direction, not size), but it means small moves count. Fees, funding and slippage are not deducted.

7. Which verdict a page shows

Each call has up to five labels, one per horizon. Caller and token pages show, for each call, the longest horizon that has a real result (1w, then 1d, 4h, 1h, 15m), skipping insufficient_data and unresolved. A recent call therefore shows a short-horizon verdict that can change as time passes. The summaries on a caller page (2x rate, rug-or-dead rate, win rate, average return) are computed from those per-call verdicts. Win rate is wins divided by wins plus losses; neutral calls are not in it.

8. The caller score

The score used for ranking is computed from the 1d outcomes over all of a caller's calls (the "overall" bucket). It is a number from 0 to 1:

score = 0.85 × base + 0.15 × extra − compliance penalty, clamped to 0…1

Base (85%)

Extra (15%)

Compliance penalty

0.05 for each call marked as policy-blocked or unverifiable, plus 0.10 if the source is inactive, capped at 0.35.

The score is a ranking aid, not a forecast. Read it with the caller's actual calls, sample size and flags.

9. Leaderboard and minimum sample

The leaderboard lists active, publicly listed callers whose score covers at least the minimum sample, currently 10 calls (the public_leaderboard_min_sample setting). The sample counts captured calls, including ones still without a result. Callers are ordered by score. Each leaderboard publication is saved as a snapshot with a hash of its contents, so a published ranking can be checked later. On Pulse, a caller is shown as ranked when they meet the same minimum. Callers below it still have public pages, labelled as new or with too few calls.

10. Deleted, edited and late flags

• Deleted ✕. When we re-read a channel's public page, a post we stored whose message number falls between the lowest and highest numbers on that page, but is no longer there, is flagged deleted. Deleted calls keep counting. We only check pages we re-read (usually the newest), so older deletions can be missed, and a post hidden for another reason (for example by Telegram) can be flagged as deleted.
• Edited ✎. When a stored post's text changes, the call is flagged edited and we keep scoring the original text.
• Late ↗ (pre-call run-up). We measure how far the price had already moved before the call: from the open about 1 hour and about 6 hours before, to the open of the hour in which the call was posted, using hourly candles. The call is flagged late when the bigger of the two moves is at least +100% for memecoins or +5% for other coins. For calls less than an hour old without candles yet, we use DexScreener's reported 1h and 6h change at the time of our snapshot, which can include a few minutes after the post. We measure calls from the last 45 days and stop trying after 14 days without price data. The leaderboard's late share is late calls divided by calls we could measure.

"Late" is a heuristic. A big run-up before a call often means the caller's circle bought first and followers became exit liquidity, but it can also be an honest call on momentum, or news. The flag describes the price, not intent. Deleted and edited flags are also facts about the post, not accusations.

11. Limitations

• Coarse prices. Hourly candles and roughly 30-minute snapshots miss short spikes and dips and the exact order of events inside an hour; when the order inside one price point matters, we assume the outcome worse for the caller (sections 4 and 5). The start price can be up to an hour after the post, which can make a call look better or worse than following it immediately would have been.
• Extraction errors. Both the rules and the language model make mistakes: a token named as a warning can be read as a call, a call can be missed, the direction or levels can be misread, or the wrong token picked when several are named.
• Data gaps. Thin or new tokens may have no pool, no candles or late data; coins not on Binance spot may be unpriced. Those calls show no result or insufficient_data.
• No costs. Returns ignore fees, slippage, price impact, funding and taxes. A label is not what a follower would have earned.
• Heuristic flags. Late, deleted and edited are detected automatically and can be wrong.
• Coverage. We only see the channels we track and the posts we manage to read. A caller's record here is not their full history.
• Past only. Records describe past tracked calls and do not predict future ones.

12. Token safety

Token pages for Solana tokens show a token safety checklist. The data comes from RugCheck's public token report, refreshed at most every 5 minutes; when RugCheck is down we read only the mint account from Solana RPC (mint and freeze authority, Token-2022 extensions). Holder figures use RugCheck's top holders and leave out AMM pools, lockers and the burn address, so a pool holding half the supply doesn't look like a whale. The verdict is our own rule set, applied in order:

• Danger if the mint authority is still active (more tokens can be minted), the freeze authority is still active (holders can be frozen), less than 50% of the main pool's LP is locked or burned, or a single wallet that isn't a pool, locker or burn address holds more than 20%.
• Caution if more than 3 insider wallets are detected, the creator launched 3 or more other tokens within any 7 days, the top 10 holders (pools, lockers and burn excluded) hold more than 35%, the token metadata can still be changed, or only the RPC authority check was available.
• Clean if none of these apply.

The main pool is the one with the most liquidity. A smaller pool with under 50% locked and at least $1,000 of liquidity is shown as a note but doesn't change the verdict. "Clean" means none of our checks fired, not that a token is safe: a dev can still sell, and holder data covers only the largest wallets. Not investment advice.

13. Corrections

If a call was misread, mispriced or wrongly flagged, tell us with evidence and we will check it. See Disputes. When this methodology changes in a way that moves scores, we will update this page and its date.