The dataset, field by field
Every record in a Solarflare delivery carries the same five fields, in a stable documented schema. This page is the full reference — plus an illustrative sample file you can load before requesting real data.
How is the dataset delivered?
Recurring CSV or JSONL files through a secure download workflow — weekly delivery is the standard cadence, with custom cadence, format, and packaging available on Production plans. The schema is stable across refreshes, so a delivery loads into the same warehouse table, fraud platform, or SIEM pipeline every week. Each record is one observed proxy exit:
| Field | Format | Meaning |
|---|---|---|
| ip | IPv4 or IPv6 address | The observed proxy exit address — the join key against your logs, events, and warehouse tables. |
| first_seen | ISO-8601 date | When this address was first observed behaving as proxy infrastructure. Establishes how long the address has been part of the observed population. |
| last_seen | ISO-8601 date | The most recent observation. The field your rules should decay on: recent last_seen means current evidence, old last_seen means the signal is aging. |
| network_type | enumerated token | The category of network the exit operates on — see the value table below. Drives response policy: datacenter verdicts tolerate stricter defaults than mobile ones. |
| confidence | low | medium | high | How well-evidenced the classification is: observation count, recency, and behavioural match compressed into a threshold-ready level. |
What values can network_type take?
Network-type classification covers residential, mobile, datacenter, and VPN-style observations. The tokens are snake_case and stable:
| residential_proxy | Exits through home ISP addresses — consumer broadband devices relaying traffic, the category that defeats ownership-based checks. |
| mobile_proxy | Exits through carrier ranges, typically behind CGNAT where one address fronts many subscribers — highest false-positive cost when blocked. |
| datacenter_proxy | Exits on hosting and cloud ranges — the most distinguishable category and the cheapest for defenders to act on. |
| vpn_proxy | VPN-style anonymization exits — commercial VPN endpoints observed relaying traffic; same signal families, different tunneling technology. |
Why the categories warrant different blocking policy is covered in residential vs datacenter vs mobile proxies.
What does each confidence level mean?
Confidence reflects how many independent observations support the signal, how recent they are, and how cleanly the IP's behaviour matches proxy infrastructure patterns:
| Level | Evidence | Recommended use |
|---|---|---|
| high | Dense, recent, behaviourally clean observations | Ready for hard blocks |
| medium | Meaningful evidence, short of certainty | Combine with other signals; friction or review |
| low | Sparse or aging observations | Step-up verification, never a hard block |
The full semantics — and why evidence strength should drive response strength — are in what an IP confidence score actually means.
Download the illustrative sample
solarflare-sample.csv — ten rows in the exact schema above, built from IANA documentation address ranges. It contains no real observations; use it to wire up parsing, loading, and joins, then request a real sample to evaluate coverage against your own traffic.
Frequently asked questions
- Is the downloadable sample real data?
- No — it is an illustrative file using IANA documentation address ranges (203.0.113.x, 198.51.100.x, 192.0.2.x, 2001:db8::/32) so you can test parsing, loading, and joins without handling real observations. For a representative sample of real data, request one — the evaluation tier is free.
- Does the dataset include ASN or geolocation fields?
- No — those belong to a different data plane. ASN and geolocation are registry-derived attributes you can source freely and join on IP; Solarflare contributes the observed-behaviour plane. The reasoning is covered in geolocation databases vs proxy detection.
- Does any field reveal which proxy provider an IP came from?
- No, deliberately. The useful signal is whether an address has been observed behaving as proxy infrastructure — not naming the underlying source. Provider attribution is excluded from the schema by design, consistent with the pricing FAQ.
Want to test your IP data against Solarflare?
Start with a sample file or send us a list of IPs for a match report. You'll see the same fields, schema, and recency context available in recurring dataset deliveries. No commitment.