Inside the verdict engine: rules, confidence and what we deliberately do not do
A technical walkthrough of how an IP becomes a verdict: which signals are used, how confidence is assigned, and the limits we accept.
The pipeline
- Load the address. Normalise it; reject reserved and private ranges.
- Geolocation. City, region, country, coordinates, timezone, network range.
- ASN. Number, operator name, and the ASN metadata (type, brand).
- Security flags. Hosting, CDN, proxy, VPN, Tor, blacklist level.
- Verdict. One label per IP, plus confidence and the evidence behind it.
- Advice. Use it, warm it up, or avoid.
How the verdict is chosen
The order matters, because stronger signals should win over weaker ones:
Tor → 95% confidence
VPN provider → 88%
Hosting ASN → 82%
CDN edge → 60%
Mobile → 65%
Native ISP → 70%
Other ISP → 55%The number is confidence in the label, not a probability that a platform will ban you. A 70% residential verdict means "the ASN looks like a consumer ISP and nothing suspicious matched" — not "this is safe".
The risk score is separate
The 0–100 score is a heuristic that combines the flags with weights. It is deliberately not a model output: every point comes from a rule you can inspect, which is why two different tools can disagree without either being broken.
What we do not do
- No residential-proxy database. We do not license commercial data that claims to know which household IP is rented out. Detecting that requires either a commercial feed or live behavioural data.
- No ML black box. Rules are auditable; a model that says 0.83 without a reason helps nobody in a dispute.
- No promise. Platform risk systems use device, payment and behaviour signals we never see.
Reading the output correctly
Treat the verdict as a screen: it removes the obvious mistakes (hosting ranges, Tor exits, CDN edges) before you spend money. Then keep the IP stable, check it again before registration, and do not assume one clean check is permanent.