Open data

Where seven IP reputation sources agree, and where they don't

Rolling aggregate counts from live IPOK lookups: per-source coverage, flag rate, pairwise disagreement, and leave-one-out agreement — each source measured against its peers rather than against a verdict that already contains its own vote. We report datacenter and residential IPs separately, because the consensus rule uses a different threshold for each. Counts only, no IPs, with JSON and CSV downloads.

Generated 2026-10-13T00:43:24.822Z · cached for 30 minutes · we hide a rate when its denominator is below 30.

Coverage, flag rate, agreement

Coverage is the share of queries in which a source returned a verdict. Flag rate is the share of its own verdicts that carried a risk flag. The last column asks something narrower: how often the source's flag pointed the same way as the score IPOK published (risk ≥ 50). That score is a blend that already contains the source's own vote, which is why the column is labelled self-referential — a source with near-total coverage is partly being scored on its agreement with itself.

The three columns before it remove that loop. For each source we take its peers on the same lookup — every other source that returned a verdict, minus ip-api, whose proxy booleans are derived rather than measured and never count as an independent vote here. Corroborated: of the lookups this source flagged, how many its peers also flagged (at least one of them). Caught by peers: of the lookups where at least 2 peers flagged and this source did rule, how many it flagged too. Leave-one-out agreement: of the lookups it ruled on, how often it matched the plain label "at least 2 peers flagged this". The source being measured is never part of its own reference. This does not make any of them accuracy scores — peers can be wrong together, and a source that is only called on part of our traffic gets a smaller, differently composed denominator.

Pairwise disagreement

For every pair of sources, this counts only the queries where both returned a verdict, then asks how often exactly one of them raised a flag. A high number means the two look at different evidence. It says nothing about which one is right, and it explains why a single-source score reads differently depending on which vendor a site uses.

How many dedicated sources called it proxy or VPN

The consensus rule counts votes from dedicated sources only (everything except ip-api, whose booleans are derived rather than measured). A datacenter IP needs 2 such votes before IPOK treats it as a proxy; a residential IP needs 1. The bars below show the observed distribution of that vote count, so you can see how much of the traffic sits at the threshold instead of taking our word for it.

Download

Both files carry the same numbers as this page. The CSV holds the raw daily signature counts rather than the computed rates, so you can recompute every percentage above without trusting our arithmetic.

Licensed CC BY 4.0. If you cite these numbers, please credit IPOK and link back to this page.

How to cite

The version number tracks the method, not the numbers. It moves when a state definition, a bucket rule or a reporting threshold changes — not when the figures shift, which they do every day as the window rolls. Two pulls carrying the same version are comparable; record the date you took yours.

IPOK. (2026). IPOK IP Reputation Source Agreement Dataset (Version 1.3) [Data set]. Retrieved 2026-10-13, from https://ipok.io/en/data/sources

@misc{ipok-source-agreement,
  title   = {IPOK IP Reputation Source Agreement Dataset},
  author  = {{IPOK}},
  year    = {2026},
  version = {1.3},
  url     = {https://ipok.io/en/data/sources},
  urldate = {2026-10-13},
  note    = {Data set. Licensed CC BY 4.0}
}

How it is counted

• ·We compress each counted lookup into one 16-bit signature: eight sources, two bits each, for absent, no flag, reported proxy/vpn, or reported Tor and abuse history without proxy/vpn. The row holds a UTC date, the datacenter or residential bucket, the final verdict as 0 or 1, that signature, and a count.
• ·We split datacenter from residential on "at least one source flagged hosting", the same expression the consensus rule uses when it picks the 2-vote or 1-vote threshold. That differs from the IP-type label shown on a result page, which goes through extra reconciliation.
• ·The final verdict is 1 when the published risk score reaches 50, the boundary between the clean and caution bands we use elsewhere on the site.
• ·We keep rows for 60 days, then delete them lazily. There is no per-query record to delete, because we never write one.
• ·Below 30 observations we print a dash instead of a rate. A percentage drawn from a handful of queries is noise.

The evidence tier column is annotation, not arithmetic. We mixed data of very different provenance into one table and let it all vote the same way: a list the operator of a network publishes about its own exits, a list built by probing addresses one at a time, and a list painted across a provider's whole ASN. On 2026-09-22 that cost us something concrete — all 105,727 iCloud Private Relay egress IPs Apple publishes turned out to sit inside X4BNet's VPN ranges, so every Safari user with Private Relay on was earning a dedicated VPN vote until we let Apple's own list override ours. Labelling the tiers is the first half of the fix; the second half would be letting them carry different weight, and we have not done that. Weights, hard-signal floors and the vote thresholds are byte-identical with and without this column. Whether a first-party statement should outweigh three inferred ones is a question for the calibration loop, and it needs readings we will not have before 2026-10-06.

The scoring rules these numbers describe are documented on the methodology page. For a hand-checked snapshot of specific, reproducible IPs rather than traffic aggregates, see the source-vote study.

What these numbers cannot tell you

• ·This is not site traffic. We reject requests that claim to be a browser while carrying header combinations a browser never sends, first at the edge and again in the API route, both upstream of the counter. Whatever that filter gets wrong, in either direction, lands in the sample.
• ·We drop lookups served while the third-party upstream pool was full. In that state four commercial sources read cache only by design, so counting them would report our own quota policy as a coverage failure of theirs.
• ·A source answering from a stale cache entry still counts as having returned a verdict. Coverage measures whether an answer came back, not how fresh it was.
• ·We call two of the sources on a subset of queries only: Scamalytics when a person looks up a specific address, ipapi.is when a cheap signal already suggests something worth checking. Their coverage figures describe that routing, not the vendor.
• ·IPQS has no API key configured and stays dormant. Its row is here for continuity and reads zero.
• ·Agreement with the final verdict does not measure who is correct. IPOK has no ground truth for whether an address was running a proxy at query time, so do not read either table as a vendor accuracy ranking.
• ·The leave-one-out columns remove a source from its own reference, not from reality. Sources that ingest overlapping blocklists can be wrong in the same direction, and the quorum of 2 is a threshold we picked, not a measurement.
• ·Those columns also reward tracking the crowd rather than contributing to it: a source that echoes what the others already said scores well while adding nothing to the decision. ip-api sits slightly apart here — it is excluded from every peer set, so it has no vote of its own to remove and is measured against one more source than everyone else.
• ·Traffic decides which addresses get measured. The mix is whatever people looked up, which skews toward addresses someone already suspected.

Source names, in signature bit order: ip-api, IPQS, Scamalytics, proxycheck, AbuseIPDB, ipapi.is, StopForumSpam, IPOK-DB, IPHub, vpnapi.io.