The Telegram Signal Leaderboard: How We Score Channels, and What the First Ranking Shows (2026)

Our channel leaderboard ranks anonymised Telegram signal channels with a single formula: rank = trust x (0.6 + 0.4 x min(1, completed / 30)) x recency. Trust is a 0-100 score built from a channel's own backtested signals and the share of its messages it edits or deletes. Confidence scales that score down until a channel has 30 completed trades. Recency scales it down again if the channel has gone quiet. Names are never published. This article gives you every weight, every threshold, the reasoning behind each one, and the SQL to reproduce all of it.

It is the companion to we backtested 13 Telegram signal channels, which reports what the data said. This one explains how we got there - including the parts we think are wrong.

Snapshot: 15 September 2026. 120 channels observed, 13 backtested, 10 scored, 8 ranked.

Where the numbers come from

Three properties of this pipeline matter before any formula does.

It only reads stored backtests. Building the snapshot makes no live market calls and re-runs no simulations. It aggregates rows that already exist because a user asked for a channel to be backtested. That means the leaderboard cannot invent data, and it also means it can only see the channels someone has looked at.

Channels are deduplicated across users. If eleven people copy the same public channel, it appears once, matched on its normalised Telegram identifier. Otherwise a popular channel would simply appear eleven times.

The price data is honest about its own source. Of the 235 backtested signals in the current snapshot:

That third row deserves the honesty it is asking for, because it is not one thing.

Sixty-four of the 90 are rows we never evaluated - ENTRY_NOT_REACHED, INSUFFICIENT_DATA, INCOMPLETE or INVALID. There was no candle run to record a source for. A signal we could not test is excluded from a channel's score, never counted as a zero. Scoring a channel badly because our cache was cold would be measuring ourselves, not them.

The other 26 are completed, scored trades from backtests run between January and April 2026, before we began stamping the data provenance onto every row. The candles are there - those rows record between 494 and 4,317 minutes of price each, and the entries filled - but we cannot now say which feed served them. All 26 belong to two channels, #99 and #28, which happen to be ranked second and third. Read their numbers knowing that: the results are real backtests, but their data source is not independently re-checkable from the stored row the way a September backtest is.

The trust score, factor by factor

Trust is 0-100, built from five factors. Here is each one with the formula and, in the last two columns, a worked example: Channel #117, the top-ranked channel in the current snapshot.

The weights encode four opinions, and they are arguable:

Win rate gets the most points (35) even though it is the least informative statistic. That is a deliberate concession to how people actually read a channel. It is bounded, though - a 100% win rate buys 35 points and no more, which is why the 92.9% channel in our sample does not automatically top the table.

Expectancy saturates at +0.3R (30 points). Anything above +0.3R per trade is exceptional and treated as equally exceptional; anything negative scores zero rather than going negative. A channel with a genuinely broken edge should score badly, not catastrophically, because the sample sizes are small enough that a catastrophic score would often be noise.

Sample size is worth only 10 points but gates everything. Below 10 completed trades a channel is not ranked at all. Above it, points grow logarithmically: 10 trades earns 5, 30 earns about 7.4, 100 earns 10. You cannot buy trust with volume.

Completion rate (5 points) is the quiet one. It is the share of a channel's signals that produced a testable outcome. A channel posting limit entries price never reaches scores badly here - correctly, because those are trades its subscribers never had.

Honesty

Honesty is a 0-100 score computed from a channel's stored message history, and it is the factor that has no equivalent anywhere else in this category:

honesty = 100 - (50 x edit rate) - (100 x delete rate)

floored at zero. A channel that edits 20% of its messages and deletes 5% scores 100 - 10 - 5 = 85.

The asymmetry is the point. A deletion costs twice what an edit costs, because the two behaviours are not equally explicable. Editing a signal post to add "TP1 hit" is ordinary housekeeping, and our system cannot distinguish it from editing the entry price after the fact - so we penalise edits lightly and tell you the raw rate. Deleting a signal has one obvious explanation and few innocent ones.

The spread across the backtested channels:

For context on what is normal: across 92 monitored channels with at least 20 stored messages (41,303 messages), the median channel edits 58.2% of its messages and deletes none. Sixty-eight of the 92 edit at least a fifth of their messages; thirteen delete at least 5%; eight delete at least 10%.

So Channel #59's 91.3% edit rate is high but not aberrant. Channel #111's 52.7% delete rate is in a different category entirely - 655 of its 1,243 messages are simply gone.

From trust to rank

Trust measures quality. Rank answers a different question: how much should I act on this? Two multipliers turn one into the other.

Confidence = 0.6 + 0.4 x min(1, completed / 30). A channel with 10 completed trades gets 0.733; with 30 or more, 1.00. The floor of 0.6 means a small sample is discounted, never dismissed.

Recency = 1.00 if the last signal was within 30 days, 0.85 within 90 days, 0.70 beyond. A channel that has stopped posting cannot be copied, however good its history.

The two channels at the top of the current ranking show exactly what this does:

Channel #99 is unambiguously the better channel and is ranked second. It has not posted a signal in almost eight months. The ranking is not a beauty contest between historical records; it is an answer to "what could I copy this week", and on that question a dormant channel loses.

This is also the mechanism that stops a channel with eleven lucky trades from outranking one with two hundred. Eleven trades caps the confidence multiplier at 0.747; two hundred trades reaches 1.00 and earns the full sample-size points as well.

The labels

We never publish a channel's name. Instead the system generates a label from the data itself, in the form Channel #<id> - <asset> <style>.

The asset comes from the dominant symbol if it accounts for at least half the channel's signals, otherwise "Multi-asset". The style comes from the median holding time of that channel's completed trades:

A "Gold scalper" label is therefore a measurement, not a self-description. Nothing a channel calls itself enters the label: if its median completed trade lasts 26 minutes, it is a scalper here, whatever the bio says.

The first ranking

And the channels that were backtested but are not ranked, with the reason - because a leaderboard that only shows what it wants to show is the problem, not the solution:

Across the whole population of 120 monitored channels, the reasons break down as: 107 never backtested, 8 eligible, 3 backtested with no completed trades, 2 below the 10-trade minimum.

What we think is wrong with this

Publishing a scoring formula without its flaws is just marketing with arithmetic in it. Four things we would change:

1. Ten completed trades is too low a bar. It is what makes the leaderboard populated rather than empty, which is an honest admission that the threshold is set by data availability rather than by statistics. Thirty would be defensible. At ten, a channel can rank on luck.
2. The edit penalty over-punishes providers who annotate their own posts. A disciplined provider who edits every signal to record the outcome - genuinely good behaviour - is scored the same as one who rewrites entries. We would rather compare message versions than count edits, which requires storing message history we do not currently keep.
3. No spread, commission, swap or slippage. Every expectancy figure is a ceiling. A channel at +0.05R per trade is realistically at or below zero once costs land, and we do not currently say so per-channel.
4. Rescoring is manual. Weekly automatic recomputation exists in the code and is off by default. Until it is on, "the current ranking" means "the ranking as of the last snapshot", which is why every figure we publish carries its date.

Reproduce it yourself

Below is the full query set behind every number on this page and on the results article, in the order the figures appear. They are read-only, they run against the same two tables the product uses, and if you run an equivalent set against your own stored backtests you should be able to rebuild a leaderboard of your own.

-- Population: observed, backtested, scored, ranked
select max(computed_at), count(*),
       count(*) filter (where analyzed_count > 0),
       count(*) filter (where completed_count > 0),
       count(*) filter (where eligible)
from leaderboard_entries;

-- Why a channel is not ranked
select coalesce(ineligible_reason, 'eligible'), count(*)
from leaderboard_entries group by 1 order by 2 desc;

-- Signals replayed, and the date range
select count(*), count(distinct br.channel_id),
       min(ps.signal_timestamp)::date, max(ps.signal_timestamp)::date
from backtest_results br join parsed_signals ps on ps.id = br.signal_id;

-- Outcome distribution
select outcome, count(*), round(100.0 * count(*) / sum(count(*)) over (), 1)
from backtest_results group by 1 order by 2 desc;

-- Completed trades: TP hit rates, R, partial wins
select count(*),
       count(*) filter (where hit_tp1), count(*) filter (where hit_tp2), count(*) filter (where hit_tp3),
       count(*) filter (where outcome = 'WIN'), count(*) filter (where outcome = 'PARTIAL_WIN'),
       count(*) filter (where outcome = 'LOSS'),
       round(avg(pnl_r)::numeric, 3), round(sum(pnl_r)::numeric, 2),
       round(100.0 * count(*) filter (where pnl_r > 0) / count(*), 1),
       round(avg(pnl_r) filter (where outcome = 'WIN')::numeric, 3),
       round(avg(pnl_r) filter (where outcome = 'PARTIAL_WIN')::numeric, 3),
       count(*) filter (where outcome = 'PARTIAL_WIN' and pnl_r > 0)
from backtest_results where outcome in ('WIN', 'PARTIAL_WIN', 'LOSS');

-- R distribution
select count(*) filter (where pnl_r >= 1), count(*) filter (where pnl_r > 0 and pnl_r < 1),
       count(*) filter (where pnl_r < 0 and pnl_r > -1), count(*) filter (where pnl_r <= -1),
       round(max(pnl_r)::numeric, 2), round(min(pnl_r)::numeric, 2)
from backtest_results where outcome in ('WIN', 'PARTIAL_WIN', 'LOSS');

-- Medians across scored channels (swap the filter for "where eligible" to get the ranked eight)
select count(*),
       percentile_cont(0.5) within group (order by win_rate),
       percentile_cont(0.5) within group (order by expectancy),
       count(*) filter (where expectancy > 0),
       percentile_cont(0.5) within group (order by honesty_score),
       percentile_cont(0.5) within group (order by trust_score)
from leaderboard_entries where completed_count > 0;

-- Still posting, and how many of those are profitable per trade
select count(*) filter (where recency_factor = 1 and completed_count > 0),
       count(*) filter (where recency_factor = 1 and completed_count > 0 and expectancy > 0),
       count(*) filter (where recency_factor = 1 and eligible),
       count(*) filter (where recency_factor = 1 and eligible and expectancy > 0)
from leaderboard_entries;

-- The ranking table
select label, eligible, completed_count, analyzed_count, win_rate, expectancy, avg_rr,
       honesty_score, trust_score, rank_score, confidence_factor, recency_factor,
       last_signal_at::date, breakdown
from leaderboard_entries order by rank_score desc nulls last;

-- Honesty per backtested channel
select le.label, count(rm.id),
       count(*) filter (where rm.is_edited), count(*) filter (where rm.is_deleted),
       round(le.honesty_score::numeric, 1)
from leaderboard_entries le
left join raw_messages rm on rm.channel_id = le.source_channel_id
where le.analyzed_count > 0 group by le.id, le.label, le.honesty_score;

-- Editing and deleting across every monitored channel with 20+ stored messages
with c as (select channel_id, count(*) n, avg(is_edited::int) e, avg(is_deleted::int) d
           from raw_messages group by channel_id having count(*) >= 20)
select count(*), sum(n),
       round((percentile_cont(0.5) within group (order by e))::numeric * 100, 1),
       round((percentile_cont(0.5) within group (order by d))::numeric * 100, 1),
       count(*) filter (where e >= 0.20), count(*) filter (where d >= 0.05), count(*) filter (where d >= 0.10)
from c;

-- Symbol mix
select upper(ps.symbol), count(*), round(100.0 * count(*) / sum(count(*)) over (), 1)
from backtest_results br join parsed_signals ps on ps.id = br.signal_id
group by 1 order by 2 desc;

-- Candle provenance
select coalesce(candle_data->>'source', '(none)'), count(*)
from backtest_results group by 1 order by 2 desc;

-- Median holding time by style
select le.style, count(*), percentile_cont(0.5) within group (order by br.duration_minutes)
from leaderboard_entries le join backtest_results br on br.channel_id = le.source_channel_id
where br.outcome in ('WIN', 'PARTIAL_WIN', 'LOSS') group by 1;

Outcome values are stored upper case (WIN, PARTIAL_WIN, LOSS, INCOMPLETE, INVALID, ENTRY_NOT_REACHED, INSUFFICIENT_DATA); a lower-case filter silently returns nothing.

Where to start

If you copy a Telegram channel and have never seen its real numbers, the first useful step is not a leaderboard - it is a backtest of the one channel you actually have money behind. That is included on the Pro plan (5 per week) and Advanced (20 per week). The anonymised leaderboard is in tester preview; the backtest that feeds it works today.

For the background on how the backtest itself works, see AI-powered channel analysis and channel forensics. For the results this method produced, see we backtested 13 Telegram signal channels. And if you have not chosen a copier yet, the best Telegram signal copiers roundup compares the field.

Snapshot 15 September 2026. Re-run monthly; this page is updated when the snapshot changes.

See pricing or start a free trial.

Frequently Asked Questions