Methodology
Each ranking and counting surface on this site follows a printed rule, stated where the number appears. This page collects those rules in one place - what each surface measures, how it is counted, and what it cannot prove - so a skeptical reader can check the site against its own claims. If the site's behaviour and this page ever disagree, one of them is wrong - tell us and we will fix it and say so.
The ranked block: "Most opened - last 7 days"
The ranked block at the top of the homepage orders listings by counted opens of each listing's outbound link. A counted open is a qualifying request to the signed outbound link on a listing's profile, recorded on our servers at the moment of the hop. The exclusions below are a counting rule: they remove the automated and self-inflicted traffic we can recognise, and they are not proof that a person viewed the destination. A request counts only when all of the following hold:
- At most one per visitor, per listing, per UTC day. The visitor is a one-way daily-rotating code derived from the connecting address with a key that changes every UTC day, so the same person opening the same listing five times in a day is one counted open, and visitors cannot be linked across days. No address, browser identification string, or referrer URL is stored on the event.
- Signed links only. The outbound link on each profile carries a signature our server issued. A hop on a link without a valid signature is recorded and disclosed, but never counted.
- Graded before counting. Requests with an empty or crawler-shaped user agent, our own operator traffic, test links, link prefetches, and non-GET requests are excluded before anything is counted, and the exclusion reason is stored on the event itself (the full vocabulary is in the click receipt below).
- Organic origin only. Every click event carries its origin on the row.
A click that arrived through a paid placement is stamped
sponsoredat the moment it is recorded, and the ranked block's query filters toorganic- so paid clicks are recorded separately and can never move this order. The separation is carried on each event row, not just in the interface.
The window is the last 7 UTC dates - today and the six before it. A listing appears in the ranked block only after it clears the printed floor: at least 3 counted opens spread over at least 2 of those UTC days. Below the floor, a catalogue listing stays in the daily rotation; a listing accepted after the catalogue was last built appears there once it is rebuilt. Ties are ordered by case-insensitive listing name, then by the listing's address on this site; given the per-listing counts - each listing's receipt publishes its own - the printed rule determines the exact order. The number is computed from the stored events at read time - there is no stored total anyone could quietly edit.
The daily rotation
Listings that have not cleared the ranking floor are reordered once per UTC day. Each row's place is a deterministic function of exactly two inputs: the UTC date, which the server prints on the page, and the row's own link. That means:
- Every visitor sees the same order all day - the order does not react to visits, clicks, or anything about you.
- Anyone can recompute the order: each row's key is FNV-1a (32-bit) over the printed
UTC date, a
|, and the row's own link, sorted ascending, ties by link. - A listing that moves up into the ranked block does not reshuffle the rows that stay, because each row's place depends only on its own link and the date.
- Without JavaScript, the order is alphabetical.
The rotation is pure display. Nothing about the visitor is read or recorded to produce it.
Paid placement
Paid placement is a separate, labelled surface: a fixed set of sponsor seats at fixed
public prices, the same for everyone, printed on the offer. A sponsored
seat is labelled as sponsored everywhere it appears, and sponsored links carry
rel="sponsored noopener noreferrer". A seat can only be bought for a listing
whose domain the buyer has proved they control.
Paid spend is never an input to any organic order. What a sponsor buys is the labelled placement and a public receipt of the clicks counted during its term - never a position in the ranked block, and never a promised quantity of clicks. Money can buy exposure; money cannot buy truth.
Every placement currently live is published in the machine-readable disclosure feed at
/api/placements: which seat, for which listing,
the term, and the published price. A seat given away without payment is disclosed there as
complimentary - it is still a labelled placement, but calling it sold would be untrue.
The click receipt
Every published listing has a public receipt of the traffic this site sent it:
/api/clicks/<listing>, and the same truth in a versioned envelope at
/api/v1/clicks/<listing>
(a live example). Every event is graded when it is
recorded, and the grade vocabulary is closed:
counted- a signed open that survived every exclusion below. The grade is stored per event, raw; deduplication to one per visitor, per listing, per UTC day happens when the totals are computed, so the per-grade event table can read higher than the deduped totals - both are published. Paid and unpaid counted clicks are reported as separate totals, never pooled.excluded_bot- the user agent was empty or matched known crawler patterns.excluded_operator- the request came from our own addresses.excluded_test- the link was marked as a test link.excluded_prefetch- a browser prefetch, preview, or prerender fetch, not a person following the link.excluded_method- not a plain GET request.excluded_unsigned- the link carried no valid server-issued signature. Recorded and disclosed, never counted.
Deduplication is the same everywhere: at most one counted click per visitor, per listing, per UTC day. Each paid term on a receipt reports the clicks counted inside that term's own start and end - a link minted for a seat keeps working after the seat ends, and those later clicks are real, but they are not what the buyer paid for and are not attributed to the term. The versioned receipt publishes the full grade-by-origin table with explicit zeroes, so "no such traffic" and "not reported" can never be confused.
The proof layer: hourly roots
The click ledger is append-only, but that is a promise about our own behaviour, and this
product exists because operator promises about traffic numbers are worthless. So each closed
UTC hour gets a Merkle root over that hour's aggregate counts, published at
/api/v1/roots. Roots are frozen lazily: a read of
the roots API computes every closed hour after the last stored root, oldest first, in bounded
batches - and once a root is stored, it is never updated. A root deleted from the middle is
not silently recomputed; the verifier's gap check is what exposes it.
The leaf, in one sentence: one leaf per (hour, listing, grade, origin, signed-flag)
combination with its event count, serialized as
hour|entity_id|grade|placement_origin|signed|count. Leaves are sorted by the
UTF-8 byte sequence of that string and hashed with SHA-256; pairs of digests are concatenated
and hashed up the tree; an odd node is promoted unchanged; an hour with no events has the
SHA-256 of the empty string as its root. The tree covers aggregate counts only - no
pseudonyms, no timestamps finer than the hour, nothing about any visitor. Excluded traffic is
in the tree as firmly as counted traffic, so reclassifying an event's exclusion reason after
the fact moves two leaf counts and changes the root.
To check an hour, read /api/v1/roots/<hour>: it returns the frozen root
beside the current leaf aggregates, which is enough to recompute the root from the response
alone. If a change since the freeze alters that hour's aggregate counts - an event edited
into a different grade or origin, inserted, or deleted - recomputation yields a different
value, and the mismatch is visible to anyone holding the published root. The tree commits to
those aggregates only, not to every field of every event: a rewrite that leaves every leaf
count intact is outside what a root can catch. We also maintain a standalone verifier - plain
Python, standard library only - that recomputes every stored hour written under the published
algorithm (a row claiming a different algorithm is reported, not judged) directly from a database
export and additionally checks that every event carries a well-formed hour, that no event
predates the first rooted hour, and that no hour between the first and last stored root is
missing a root.
What this does not prove yet, stated plainly: the roots are stored in the same database, by the same operator, as the events they cover. Until roots are anchored somewhere outside our own infrastructure, a reader who records a published root can prove any later rewrite, but a reader who only ever trusts our stored copy is trusting us not to rewrite the roots together with the events. In other words: today the proof layer defends the numbers against everyone except the database operator. External anchoring is tracked as planned hardening and is not built yet - if you want the stronger property now, record the roots you read.
Destination screening
Every published listing's registrable destination domain is screened against the URLhaus active hostfile - a public list of hosts currently distributing malware. Checks run when the operator reads or forces the screening state - there is no scheduler - in batches of up to 15: never-checked listings first, then listings whose domain changed since their last check, then oldest first. A listing becomes due again once its last check is older than 24 hours; due means eligible for the next batch, not checked at that instant. A domain is flagged when it is listed itself or when any listed host sits under it; the match never runs the wider way.
- Scope limit, stated up front: URLhaus's published policy excludes hosts on the Tranco Top-1M list of popular domains, so a mainstream domain will not appear in it, and the screening inherits the feed's coverage as it stands on the day of the check. This measures malware-distribution listings only - it is not a rating of every kind of bad destination, and a clean verdict is not an endorsement.
- An error is never clean. If the hostfile cannot be fetched, arrives truncated, or parses empty, every listing in that batch records an error verdict. A failed checker is a fact about the checker and must not look like a clean domain.
- Unchecked is not zero. A listing that has never been checked is reported as unchecked, never folded into the clean count. A listing whose domain changed since its last check counts as unchecked again - though a non-clean verdict on the old domain stays visible rather than vanishing with the edit.
- Flags are decided by a human. A flagged destination is surfaced for a person to act on. Nothing is unpublished automatically.
The numbers described here are also printed where they are made: each listing's profile shows its own counted opens beside the signed outbound link, and the homepage states the ranked block's rule above the block itself. Questions, corrections, or a claim you think this page overstates: use the report page - an accepted notice gets a reference number and an answer-by date, and decisions on it are made by a person.