How PanelCompare ranks SMM panels

How the default list is ordered

One question sits above the score, and it is the only one that does: who is behind the listing, and what they have actually done to stand behind it. That gives the default list three tiers, in this order. Within each tier the order is the overall score, exactly as the formula above computes it.

1. 1.The owner proved the domain. A claim is a DNS record only the operator of the domain can publish, so it is the one signal on this site that cannot be produced by a panel talking about itself. It puts a named, reachable operator behind the listing: someone who can be held to a reply, who answers complaints on the record, and who loses something real if the panel misbehaves.
2. 2.The owner asked to be listed, and we accepted. This one is weaker, and it is not going to be dressed up as the one above it: nobody has proved control of anything, and it is not a verification. What it is evidence of is that somebody came forward — an operator who wrote to us at an address that worked, agreed to be measured, and cannot be surprised by the result — and, since the onboarding wizard replaced the old form, that they held a working API key and let us prove it against the panel’s own API. A panel we found while crawling the market agreed to nothing and may not know this site exists.
3. 3.Everyone else. Most of the index, and no reflection on them. Nothing has been held against a panel here. We simply have nobody on the other end of it, which is a fact about our contact with the panel rather than about the panel.

A high score says a panel is cheap and up. The two tiers above it say there is somebody there, and how much that somebody has actually put their name to. Those are different questions, and a buyer about to send money is entitled to have the second one answered first.

Both tiers are free, both are open to every panel in the index on identical terms, and there is no paid equivalent of either — now or ever. A panel cannot buy either position any more than it can buy a score. Verifying is one TXT record and about two minutes, from the panel’s own page; the second tier is what listing a panel earns once an editor accepts it.

The second tier is new, as of today. Until today there were two — verified, then everyone — and this page said so. That put a panel whose operator had written in, answered our questions and handed over a working API key in exactly the same place as one we had scraped off a forum, which understated what we knew about the first. Nobody had to do anything to get the new tier, and nobody was asked to: the column was backfilled from the submissions we had already accepted, so an operator who wrote in months ago has it today without lifting a finger. What it does not do is move anyone past a verified owner, and it does not turn into a verification by sitting next to one — proving the domain is the tier above, and it stays there.

The rule applies to the default ranking only. The cheapest, highest uptime, most services, newest and best rated sorts each promise one specific ordering and are left strictly on it — a list headed “cheapest first” that is not cheapest first would be worse than no sort at all. Filtering and every price table are untouched by it.

What goes into the overall score?

Five components, weighted. Price and trust carry 60% between them because those are the two questions a buyer is actually asking: can I afford it, and will it deliver. Support carries the least because a chat widget is easy to install and hard to verify. The weights below are read from the exported OVERALL_WEIGHTS constant at render time.

Source: OVERALL_WEIGHTS in src/lib/scoring.ts, read at build time. The headline score is rounded to one decimal place.

How is the trust score calculated?

Trust is an average over 5 components worth 85 points between them, plus up to 15 points of verification bonus, minus a penalty for published complaints. The weights answer one question: how much would it cost an adversary to fake this signal? Domain age and a completed test purchase are expensive to fake. A TLS certificate is free, so it is worth nothing here and is not a component at all.

It is an average over the components we measured, not over all of them. A component with no observation behind it — a panel we have not probed, one with no verified reviews yet — is dropped from both the points earned and the points available. It does not score zero, and it is not filled in at a neutral half either.

Source: component maxima read from computeTrust() in src/lib/scoring.ts at build time.

What does a published complaint cost a panel?

The penalty is applied after the component sum, so it can pull a panel below any score its other signals earned. Every complaint a moderator has published counts. A report leaves the count only when a moderator moves it to disputed or resolved, which is a judgement a person makes about a specific account.

An owner’s reply does not do it. A verified owner can answer any report on the record and the reply is published unedited beside it, but it moves no points on its own — because wiring the penalty to the reply field would make this the one place on the site where a panel edits its own score by typing into a box. Whether an answer is actually an answer is a call for a moderator, and disputed is where that call is recorded. This page previously said the opposite — that a report the owner had answered stopped counting — and that was never what the code did.

What does change the weight is evidence. A report a moderator saw proof for — an order ID, a transaction hash, a screenshot with a visible timestamp — counts in full; one they judged credible and specific but could not verify counts 0.4 of a report. Not zero, because the buyer with the strongest case is often the one left holding nothing but a login that stopped working. The curve is logarithmic and capped, because the tenth complaint tells you far less than the first.

Source: computeTrust() evaluated at each complaint count, with every report evidenced and with none of them. The deduction is capped at 35 points. Where a panel is carrying one, the exact figure and the reports behind it are itemised on that panel’s own trust page.

What happens when we have not measured something?

It leaves the average, and it lowers coverage instead — the share of the 85 weighted points we actually hold evidence for. Coverage is published next to every trust score on this site and returned by the API, because a 70 built on five components and a 70 built on two are different claims and only one number cannot say which you are looking at.

This replaced an earlier design that filled every gap with a neutral half-share. That sounds like the cautious choice and is not, for a reason worth stating plainly: the filler is the same constant for every panel, so the more of the scale it occupies, the harder every panel is pulled onto the same figure. At the point we noticed, 60 of the 100 points were the same for almost every panel in the index — uptime, reviews and verification were all unmeasured across the board — and four values covered nine listings in ten. The score had stopped describing panels and started describing our own coverage, while still printing as a confident number out of a hundred.

Renormalising has the opposite failure mode: with one component measured, that component becomes the whole score. So below 50% coverage the result is pulled back toward the midpoint in proportion to how far short it falls, and a panel whose single measured component happens to be full marks cannot present as a panel we have checked.

A second, lower floor decides something different: whether we will put a word on the score. Below 30% coverage no band name is awarded — the panel reads provisional, and the figure carries a dotted underline wherever it appears. “Established” is a claim about a panel, and one lucky observation does not entitle us to make it: the heaviest single component is worth 25 of 85, or 29%, so nothing on its own clears this floor.

These were one constant at 50% until today, and the page said so. That was wrong twice over. They answer different questions — “how sure are we of this number?” and “is there enough here to say a word out loud?” — and tying them together made the band floor unreachable: everything we can learn about a panel without an API key or a run of probes sums to 40 of 85, which is under half. So 128 of the 129 panels in the index were labelled provisional, the best of them scoring 72.5, and a caveat that applies to ninety-nine listings in a hundred carries no information about any of them. Between 30% and 50% a panel is now banded and still discounted, and the coverage figure that rides next to the band everywhere it appears is what tells you which of those you are reading.

What do the trust bands mean?

The bands are defined once, in trustBand(), and are the same everywhere they appear: 80 and above is high trust, 62–79 established, 42–61 limited history, below 42 unproven. A new panel is unproven by construction, and that is a statement about our evidence rather than about the panel.

How is the price score calculated?

For every service a panel actually sells, we take its price as a ratio of the market median for that same canonical service, then take the median of those ratios. A ratio of 0.5 (half the market) scores 10. A ratio of 1.0 scores 5. A ratio of 2.0 scores 0. The score is computed only where a panel competes, so a narrow catalogue is neither rewarded nor punished for the services it does not carry.

Source: computePriceScore() evaluated against a synthetic three-service catalogue at each ratio.

Why the median of ratios rather than a comparison of averages?

Because comparing average prices measures a catalogue’s composition rather than its pricing. A panel that lists only the two cheapest categories on the market (Instagram likes and TikTok views, both priced in fractions of a cent) has a low average price and tells you nothing about what its followers or watch hours cost. Taking each service as a ratio against that service’s own market median removes the composition entirely: every row is compared only with its like, and the median of those ratios is unmoved by one outlier row.

This matters more here than in most markets, because several of these markets are bimodal. YouTube subscribers have a bot tier at $0.02–$0.72 that describes itself as high-drop with no refill, and a real refill-guaranteed tier clearing near $14.40, with nothing meaningful in between (PanelCompare domain research, 6 September 2026). A mean across those two tiers describes nothing anyone can buy.

Two guards sit on the calculation. Ratios outside 0.02× and 20× are dropped as data errors or bespoke services rather than price signals: a service priced at a hundred times the market is usually a different product wearing the same name. And a panel with fewer than three comparable services scores a neutral 5 rather than a flattering 10, because three rows are not a price policy.

How are features, reliability and support scored?

Feature weights reflect what it costs a buyer when a capability is missing, not how impressive it sounds. A refill guarantee protects the purchase itself; an auto-subscription saves clicks. The weights below are measured by flipping one flag at a time against a zeroed input set and reading the difference, so they are the code’s weights rather than a description of them.

Source: computeFeatureScore() evaluated one flag at a time. The final score is clamped to 10, so a panel with every capability does not exceed the scale.

What does uptime score?

Uptime is squared before scaling, which makes the difference between 99% and 95% much larger than the difference between 80% and 76%, because at the top of the range availability is the product, and at the bottom the panel is already unusable. Response time is a tiebreaker worth 1.5 points at most: a panel that is up but slow still takes your order. Below five probes in 30 days we do not score the component at all.

Source: computeReliabilityScore() at 60 probes and an 800 ms average response.

What does support score?

Published channels set a floor, and buyer ratings override it. Where at least three of the approved reviews that make up a panel’s star rating have rated support directly, that evidence is worth 65% of the component and the presence of a chat widget only 35%, because a widget is a purchase and a response is a behaviour. The verified-buyer badge does not gate this: it gates the trust score’s review component, described above, and nothing else.

Source: computeSupportScore() at each combination.

What does the arithmetic look like on a real panel?

The example below is whichever panel currently ranks first, chosen by the ranking itself rather than by us, and every figure is read live from the index. Its five part scores go into the weighted sum; the result is the number shown on Smm resellers Hub’s page.

Panel

Smm resellers Hub

smmresellershub.com

Trust

89.2 / 100

High trust

Overall

8.7 / 10

Recomputed here: 8.7 · 100% evidence

Step 1: the itemised trust score

Source: the stored trust_breakdown for smmresellershub.com, written by the same computeTrust() whose maxima are tabulated above. Last updated Oct 22, 2026.

Step 2: the price score, and what an average would have said instead

Smm resellers Hub has 58 services we can compare against a market median. The median of its per-service ratios is 0.788×, which scores 6.7 out of 10.

Both rows use the same 556 comparable services. The mean panel price is $5.03 per 1,000 against a mean market median of $4.52, figures that a handful of expensive geo-targeted rows can move on their own, which is precisely the distortion the median removes.

Step 3: the weighted average, over what was measured

A component with no observation behind it is dropped from both sides of this average rather than entered at a neutral 5. The weights of the ones that remain are what the score is divided by, so the figure is an average of what we know instead of a blend of what we know and a constant.

The trust row is the one that needs a word of arithmetic. Smm resellers Hub’s published trust score is 89.2 out of 100, and it enters this table at 10.00 — divided by 8.5, not by 10. 85 rather than 100 is full marks on the 5 components trust is averaged over; the other 15 are the verification bonus, which sits outside that average and is clamped at the top of the scale here. Dividing by 10 would enter the trust midpoint of 42.5 at 4.25 against a scale whose neutral is 5, so every panel we knew nothing about would carry three quarters of a point of pessimism on 30% of its headline for no evidential reason at all. Rescaled this way, a panel with almost no trust evidence — whose trust score has been discounted all the way back to that midpoint — arrives here at 5.0, the same neutral every other component on this page sits at when we have not measured it.

Source: the stored component breakdown for smmresellershub.com, run back through computeOverall() on this page. The stored headline is 8.7; if these two numbers ever disagree, the index is stale and that is a bug worth reporting.

What happens to a panel we have not measured yet?

Missing data lowers confidence, not the score. Where we have no observation for a component, it leaves the average entirely — it is not scored zero, and it is not filled in at a neutral half — and the panel’s coverage figure falls instead. Punishing an unknown would make the ranking track how long we have been watching a panel rather than how good the panel is, which would quietly favour incumbents and disadvantage every new entrant.

Filling the gap in with a constant, which is what this site used to do, turns out to be the same mistake wearing the opposite coat. The filler is identical for every panel, so the more of the scale it covers the harder every panel is pulled onto one number — and a ranking in which nobody can be moved down is a ranking in which nobody can be moved up either.

One component used to deviate, and it was a mistake rather than a design. A panel we had never synced scored a hard zero out of 10 on catalogue freshness and stayed inside the denominator, on the reasoning that hand-entered prices are worth saying out loud in the score.

What that measured was our own key ring. When this was written we held API keys for 2 of the 129 panels in the index — it is 13 of 134 today — so almost every listing was being docked the full 10 points of an 85-point base — worth roughly ten points of trust once the average is renormalised — for a key we did not have. It was the largest single source of pessimism in the index, it was applied almost uniformly so it moved nobody relative to anybody, and it was precisely the rule this section says we do not follow: a component we have not measured, scored zero instead of dropped. Never-synced is now unmeasured. It costs coverage rather than points, and the row on the panel’s own page says in full that the prices there are hand-entered.

Staleness we can actually see still costs, and that branch is untouched: a catalogue that answered last month and does not answer today is an observation about the panel. The distinction is the same one we draw between a capability flag that is null and one that is false.

Thin samples are pulled toward neutral rather than treated as certainty. Three successful probes is not evidence of reliability, so the uptime component is Laplace-smoothed — one imaginary success and one imaginary failure added to the sample — and only scored at all above five probes in 30 days.

What does this score not measure?

Stating the gaps is part of the methodology, because a score that implies more than it measures is worse than no score. These are the things we do not currently know, and would have to build a measurement programme to learn.

• Whether refills are actually honoured. We score the advertised refill window, not observed honouring. Measuring the real thing needs a test-order programme or structured dispute intake, and until it exists the refill-window figures we publish are labelled as an industry estimate.
• Real drop rates and delivery times. Advertised start-time bands are averages a panel computes itself from recent orders, and they are frequently gamed. We record them as claims, not measurements.
• Delivered quality. No comparison site can inspect the accounts a panel sends. Quality tiers in our data are the panel’s own labels, normalised but not verified.
• Common ownership, in full. We can infer clone pairs from shared copy, assets, registrant data and payment endpoints, and we disclose what we find, but an operator who separates those signals properly will not be detected.

When does a score change?

When an observation changes. Scores are never edited by hand, and there is no override field in the schema for a human to reach for. What varies is how quickly a change reaches the page, which is set by each route’s revalidation window.

Source: the REVALIDATE constants in src/lib/site.config.ts.

Questions about the formula