Check H3 · provenance family · automatic · one of the 18 Hugging Face checks
The question this check asks: do this repository's downloads and likes outrun how thin its own provenance actually is? A brand-new author, a brand-new repository, and six-figure downloads in the same week is not a pattern that happens by accident at scale — it's the shape of traction that's been bought or gamed rather than earned.
H3 is the Hugging Face analogue of C3, RepoGates' star-velocity check for GitHub — the same underlying idea, applied to download and like counters instead of stars. The scoring table names it directly:
"downloads outrunning provenance — the bought-traction pattern"
Traction is the thing a casual visitor actually looks at before trusting a repository — far more than an account's creation date. That makes it the signal most worth manufacturing, and the one this check exists to catch by comparing it against the provenance signals H1 and H2 already gathered rather than trusting it in isolation.
H3 is HIGH severity, costing 20 points when it fires — the single largest weight among H1 through H5. The verdict engine shared across all 18 Hugging Face checks and the 22 GitHub checks starts the score at 100 and subtracts every fired penalty, floored at zero; any CRITICAL finding instead drops the score straight to 0 and BLOCK. 80 and above is PASS, 50–79 is REVIEW, under 50 (or any CRIT) is BLOCK. A lone H3 finding, with nothing else fired, leaves the score at exactly 80 — still the green PASS band by the letter of the ≥80 rule, which is a deliberate design choice: a single mismatch signal warns loudly in the findings list without unilaterally blocking a repository on one number. H3 also feeds the Clone dimension verdict alongside H1, H2, H4, H5, and H12.
H3 fired zero times in the 12 September 2026 measurement of the 100 most-downloaded models on the Hub, on the malicious-models intelligence page — the only checks that produced REVIEW findings in that run were H7 (Hub pickle-import scan, 4 times) and H8 (pickle-only weights, 14 times). That null result is worth reading carefully rather than skimming past: the top 100 by downloads are, definitionally, extreme on the traction axis, which is exactly the condition this check watches. It still didn't fire once, because on the top 100 that traction pairs with long-established provenance — old accounts, old repositories — not the thin provenance H3 is actually built to flag. High traction with real history behind it is not a mismatch.
H3 needs traction to exist before it can flag a mismatch — a repository with a malicious payload and only a handful of downloads before takedown gives this check nothing to compare, whatever damage those few downloads did. It also can't distinguish organic early popularity (a genuinely good, genuinely new tool that spreads fast) from manufactured traction; both look identical in raw counters, and the decision page's job is to show you the numbers, not make the call for you. And like every check in this roster, it says nothing about the file contents themselves — a repository can pass H3 cleanly and still carry a payload that H6 through H13 are the ones built to catch. RepoGates as a whole also gates browser-initiated downloads only — it doesn't see git clone, pip install, a Python from_pretrained() call, or fetches made by an AI agent outside the browser, and it never exposes this verdict as a JavaScript global a page's own script could read.
No API call is required for this one — the Hub's own model, dataset, and space pages show download and like counts directly on the page. Read them against the repository's creation date (see H1, via https://huggingface.co/api/models/{org}/{name} for the createdAt field) and the author account's own history (see H2). A repository a few weeks old, from an author with no other public activity, already sitting on downloads that would take an established name months to earn, is the pattern worth pausing on.
What counts as a traction mismatch? Downloads or likes that are disproportionately high given how thin the repository's own provenance is — a young repository, a young author account, or both, already gathering the kind of traction that normally takes an established name years to earn. It's the same bought-traction pattern GitHub's C3 looks for in star velocity, applied to the Hub's download and like counters.
Why is this the highest-weighted of the first five checks? Because inflated traction is what makes a repository with thin provenance look trustworthy at a glance — it's the signal an attacker has the most incentive to fake, and faking it (bot downloads, coordinated likes) costs real effort even on a platform without a public star-purchase economy like GitHub's. At 20 points HIGH, it's the largest single weight among H1–H5.
Does RepoGates stop pip install or a from_pretrained() call? No. RepoGates gates browser-initiated downloads on huggingface.co only. It doesn't see pip install, a Python from_pretrained() call, git clone, or fetches made by an AI agent outside the browser.
H1 Repository age — one of the two provenance inputs this check compares traction against · H2 Author account age — the other, when the namespace is a personal account rather than an organisation · C3 Star velocity and traction — the same reasoning on GitHub, applied to stars instead of downloads.
Add RepoGates to Chrome Pricing
Numbers on this page: malicious-models measurement of 12 September 2026 (top 100 most-downloaded models on the Hub); weights from the product's scoring table.