Methodology

1. Weighted average of sources

Every source that returns a numeric risk score is blended by the weights below. Dormant, failed, or non-numeric sources are excluded from the average. The internal aggregate uses a base of 10 when no numeric score is returned, then takes the maximum of that base and triggered floors, rounded and clamped to 0–100. This internal value is not automatically a displayable conclusion. Missing current evidence, or stale / undated risk contributions in the aggregate, show “Insufficient evidence” with no total score. Historical observations remain visible without implying current safety or a current hit.

Artifact built 2026-10-23. Per-source successful fetch dates and address-family coverage are shown below; a build date does not refresh a failed source.

2. Hard-signal floors

Once a signal is hit, the final score cannot fall below its floor, no matter how low the weighted average is (final = max of weighted average and all triggered floors). This stops a datacenter IP from being mislabeled "low observed risk" just because most sources score it low.

Three boundary rules apply: any explicit trusted-allowlist signal suppresses only the hosting contextual floor; when the same source marks both allowlisted and abusive, that source's contradictory abuse vote is ignored without overriding independent abuse evidence from other sources; and a /24 filled by one broad-CIDR blanket receives no extra neighborhood floor, avoiding duplicate use of the same block-level evidence. Other direct signals still apply. One more rule covers relays: when an IP falls in Apple's published iCloud Private Relay egress ranges, we stop applying the hosting floor and our own offline database stops casting a VPN vote (those ranges are 100% covered by third-party VPN lists, so without this every Private Relay user would be counted as a VPN exit). **If external sources still call it a proxy or VPN, the 65 floor stands** — the score retains those IP-level proxy labels without predicting whether a particular platform will accept the exit. Our answer is to label it clearly as iCloud Private Relay, not to overrule those vendors.

For four real addresses worked through weights, floors and bands, see IP fraud score, explained.

Evidence tiers (labelled, not scored)

The weight table above puts every source on one scale, but the evidence behind them does not come from the same kind of place: some lists are published by the operator of a network about its own exits, some contain third-party reports or block-list labels, and some are painted across a provider's entire ASN. We sort every source — and every table inside our own offline database — into the three tiers below, and label each row of the source table on /data/sources with its tier.

• First-partyFirst-party self-declaration: a list of egress addresses published by the party that actually operates the network or service. For the question “does this address belong to them”, nobody is closer to the fact.
• ReportedReported: third-party observations, community reports, block-list labels or explicit vendor verdicts. These may concern one IP or a whole range. They do not mean IPOK tested connectivity live, and do not establish independence between sources or current accuracy.
• InferredInferred: derived from the block, the ASN, or the usage class the address sits in — VPN tables painted across an entire provider, “non-residential” hosting / datacenter classifications, proxy booleans synthesized out of other fields. The block-level statement may well be true while the statement about this one address is not.

The six reputation/relay tables in IPOK-DB

The offline artifact contains six reputation/relay tables and seven cloud-provider range feeds: 13 inputs, not thirteen independent risk sources. Cloud feeds provide network-ownership context only; overlapping lists do not establish independent observations.

Tiers are labelling and disclosure only. Weights, hard-signal floors and vote thresholds are not adjusted by tier, and the verdicts are byte-identical with and without this whole section. Whether one first-party statement should outweigh three inferred ones needs readings from the calibration loop described above; until those exist, tuning weights by tier would mean setting the tiers and the weights from the same data with no ground truth in it.

3. Spam / abuse blocklists (DNSBL)

IPOK plans five mail / abuse blocklist queries over Cloudflare DoH: SpamCop, UCEPROTECT, Barracuda, S5H, and Anonmails; the result reports how many actually completed. Partial failures are warned, and an all-failed run produces no blocklist verdict—neither is treated as clean. Any hit among completed checks triggers the blocklist floor. IPv4 only.

4. Risk bands

5. Registration and geolocation consistency

RIR/RDAP describes registration; geolocation databases estimate location. Matching country fields do not prove a native, residential or unforwarded connection, and a mismatch alone does not prove broadcast routing or proxy use. Anycast can announce one address in multiple places, so a coordinate cannot establish a physical exit. Missing information remains unknown and does not predict platform access.