Where Residential Proxy IPs Come From, and How to Audit a Provider

AhnLab's ASEC has documented malware droppers that silently install the command-line build of IPRoyal's Pawns client on victim machines, so the attacker collects the bandwidth payout while a stranger's router carries the traffic. The client itself is ordinary, legitimately built software, which is exactly why it works as a payload. It is also the clearest illustration of why "ethically sourced" on a vendor homepage buys you nothing. The phrase describes an intention. What you can audit is a mechanism: which piece of software enrolled a consumer device into the network, and what the device owner saw on screen before their connection started carrying someone else's requests.

This guide is the conversation an engineering or procurement team should have before signing a proxy network contract. It covers how peer-to-peer pools get assembled, what separates a real opt-in flow from a clause buried in a EULA, why buyer-side identity checks tell you something about the seller, and which documents to request by name. It also covers the failure mode nobody advertises, which is that the same IP addresses turn up in several vendors' pools at once.

If you are still deciding whether you need raw IP access at all, choosing a web scraping tool covers the category-level decision first. This page assumes you have already concluded that you do.

The four ways a residential pool gets built

A residential proxy is only interesting because the IP belongs to a consumer ISP subscriber rather than a hosting provider. That property cannot be manufactured. It has to be borrowed from someone, and there are a limited number of ways to borrow it.

Monetisation SDKs. A library that an app developer embeds in their own product. When an end user opts in, their device joins the proxy network and the developer is paid per opted-in user. This is the dominant model at the top of the market. Bright Data runs an SDK partner programme with published acceptance criteria, Infatica operates a separate SDK site and privacy policy for the same purpose, and Massive is built almost entirely on this model. Massive's own documentation set is oriented around SDK integration for Android, Fire OS and iOS developers rather than around proxy configuration, which tells you where the network's supply comes from.

Standalone rewards clients. Software a person downloads on purpose because they want to be paid for spare bandwidth. IPRoyal sources its residential pool through Pawns.app, which its own support documentation states plainly: members join or leave through the Pawns platform at any time. PacketStream runs the equivalent Packeter programme, and its explainer pages describe a per-gigabyte payout to contributors. The consent story here is cleaner in principle, because the user's entire reason for installing the software is the bandwidth deal.

Static ISP allocations. Not peer-sourced at all. The provider leases IP ranges that are registered to a consumer ISP but hosted in a datacentre. These get sold as "ISP" or "static residential" proxies. They carry none of the consent questions of a peer pool, and none of the diversity either, since the whole range is traceable to one buyer. SOAX, Evomi, NodeMaven and IPRoyal all sell ISP proxies alongside peer-sourced residential.

Upstream resale. The provider buys capacity from another provider's pool and marks it up. This is common, rarely advertised, and the single most important thing to ask about, because every consent question you asked your vendor now applies to a company you have never heard of.

Most vendors run more than one of these at once, which is fine. What matters is whether the vendor will tell you the split.

What a real opt-in flow looks like

Every vendor claims consent, so the claim carries no information. The test worth applying is whether a vendor publishes conditions specific enough that a partner developer could visibly fail them. Bright Data's trust centre is the fullest published statement of that kind I have seen from a proxy network, and it sets conditions on the apps that carry its SDK. The conditions below are as the company has published them; I was not able to re-open the page on 27 July 2026, so check the current wording against the vendor before you rely on it in a contract. The app has to be downloadable safely and must not be classified as a potentially unwanted application by major antivirus vendors. It has to have a clear native user interface with a settings menu, so opting out is reachable from inside the app rather than by uninstalling it. Bright Data requires that only users who opt in become nodes, that the opt-in happens through its own consent screen rather than the developer's, and that the developer's terms of service and privacy policy state the arrangement independently. It also requires the app to deliver a benefit to every user who opts in, which is the clause that rules out enrolment with nothing offered in return.

Read that list again as a checklist and it becomes a template you can apply to any vendor, including ones that publish nothing:

• Is the consent screen owned by the proxy network or by the app developer? Vendor-owned screens are auditable across the whole partner estate. Developer-owned screens are not.
• Is participation opt-in, or opt-out from a default-on state?
• Can a user find and reverse the decision without uninstalling the host app?
• Is there a benefit that a user could articulate, or is the benefit "the app is free"?
• Does the host app's own privacy policy mention it, so the disclosure survives the user forgetting the consent screen?

Infatica's trust centre makes a similar commitment in narrower terms, stating that participation requires a clear opt-in and that devices are never enrolled unknowingly. Its SDK privacy policy goes further on the data question, stating that the SDK collects no personal data, uses no permanent device identifiers, and does not track across apps. Evomi's site, read on 27 July 2026, frames the same idea in softer language, describing a marketplace serving both the businesses buying proxies and "the people who choose to share their IPs," and saying its network is regulated as part of the EWDCI. The same page lists ISO 27001 as certified, EWDCI membership as certified, and SOC 2 Type II as in progress rather than complete. Carry that last distinction into your notes exactly as the vendor states it, because "SOC 2" on a slide and "SOC 2 Type II in progress" on a vendor's own site are not the same claim.

None of these documents is a substitute for the consent screen itself. Ask for a screenshot. A vendor that runs a vendor-owned consent screen can produce one in an afternoon.

The buried-consent failure mode

Set that checklist against the alternative, which is a clause somewhere in twelve screens of terms saying the app may "use idle network resources". The user saw no consent screen, got nothing they could name in return, and has no toggle anywhere to reverse it.

The gap between those two flows is not only a question of taste, and the Pawns dropper this guide opened with is one instance of a wider pattern. AhnLab has reported on proxyware being planted on victim machines repeatedly, including a 2025 case tracking clients pushed through a YouTube download site. None of that implies misconduct by any vendor. It does mean a widely distributed, legitimately built proxy client makes an attractive payload, and the only thing standing between a vendor's pool and that traffic is the vendor's own detection and removal process.

So ask about it directly. What happens when a device in your pool is reported as enrolled without the owner's knowledge? Who can report it, how fast is it removed, and is there a public route for someone who is not a customer to reach you? Bright Data publishes a dedicated abuse mailbox and a reporting flow. A vendor without one has no mechanism to learn about the problem at all.

KYC on the buyer side tells you about the seller

How much friction a vendor puts in front of a buyer tends to track how carefully it polices the supply side. Bright Data's documentation is explicit that residential access requires KYC, that a compliance team reviews the business and the use case before traffic is routed, and that there is no automatic or instant approval. Oxylabs publishes a Know Your Customer policy stating that every customer answers a KYC questionnaire and that it reserves the right to refuse service. SOAX publishes both a KYC/KYB policy and a set of ethical guidelines that commit to verifying the identity of every client and to a defined list of permitted use cases. Infatica publishes a KYC compliance page describing vetting for every customer.

It is worth being honest about the trade. KYC is friction. It costs you days, it usually requires a business email and sometimes a call, and for a small team running a short project it can be the deciding factor against a vendor. Several mid-market providers compete explicitly on not having it.

But the logic runs in one direction. A network whose supply is real people's home connections and whose demand is anonymous card payments has no way to keep the two apart. If you are buying residential access for a use case you would happily describe in writing, the KYC questionnaire costs you an hour and buys you a vendor that is filtering the traffic your neighbours' routers carry. If you would rather not describe your use case in writing, that is worth knowing about yourself before you sign anything.

Overlap: the same IPs turn up in several pools

Consent audits do not touch the next problem, and two facts sit underneath it. The first is that resale is routine and rarely advertised, which the vendors themselves half-say out loud. Evomi's site, read on 27 July 2026, commits to holding "ourselves and every upstream partner to the highest industry standards." Read that as a compliance promise and it is reassuring. Read it as a disclosure and it says the pool includes capacity Evomi did not source.

The second is that peer pools are volatile and are drawn from the same consumer networks. IPinfo's Daniel Quandt, in a post on residential proxies flagged in customer traffic that I read on 27 July 2026, reports that 60% of residential proxy IPs are only observed once in a 90-day window, that the average time an IP lasts in a pool is 4.5 days, and that there are ASNs where the share of IP space associated with residential proxy infrastructure over a 30-day period reaches 15-20%. Those are IPinfo's measurements of the ecosystem, not of any one vendor, and not ours. But a market where a fifth of some consumer ASNs is proxy infrastructure and individual addresses cycle through pools in under a week is not a market where two vendors' pools stay neatly separate.

Two consequences follow, and both outrank most feature comparisons.

First, redundancy is often an illusion. Teams buy a second proxy network so that when the first one starts failing against a target, they can fail over. If both vendors resell from overlapping supply, the failover lands on the same addresses that a target's anti-bot system has already scored. Your two vendors are one vendor with two invoices.

Second, your consent audit only reaches as far as your direct supplier. If a vendor resells upstream capacity, every question in this guide needs asking again one level up, and you will usually be told the upstream is commercially confidential.

You can test overlap yourself before you commit, and you should, because no vendor will hand you the answer. The method is simple and does not require anyone's proprietary dataset. Pull a large sample of exit IPs from each vendor's trial or entry tier under identical targeting, in the same country, over the same window, using a rotating proxy endpoint that gives you a fresh address per request. Record the exit IP each request lands on by hitting an IP echo service. Then compute the set intersection between vendors, and separately compute the ASN distribution of each pool. Two things are worth looking for: identical addresses appearing in both samples, and pools whose ASN mix is suspiciously similar even where the addresses differ. Run it per country, because overlap is uneven by geography. Do not treat a small sample as a measurement of pool size; treat it as a yes-or-no signal on whether two vendors are drawing from the same well.

What each provider publishes

The table below records what each vendor publishes about sourcing as of July 2026, and where the vendor is a poor fit. Nothing here is an allegation about any provider's conduct. It is a record of what is and is not in public.

Disclosure tracks size and sales friction, not pool quality. The vendors that publish the most also make you work hardest to buy from them, and that is the trade you are really making.

Where GDPR bites

This is a question for your counsel, not for a directory, but it is worth knowing where the pressure points are before the call.

The relevant starting point is the Court of Justice of the European Union's decision in Breyer, Case C-582/14, handed down on 19 October 2016, which held that a dynamic IP address can constitute personal data where the party holding it has legal means to identify the person behind it, typically through the subscriber's ISP. Commentary at the time from Covington and from A&L Goodbody read it as confirming the direction set in Scarlet Extended.

Applied to a residential proxy contract, that reading touches both ends of the arrangement. The peer whose home connection carries your traffic is a person, and their IP address is being processed by the network operator. Separately, the target site logs that IP as your visitor. If your crawl collects personal data, you have a second and much more familiar set of obligations that a data provider relationship or a web scraping API does not remove.

The practical procurement consequence is narrow. Ask for the data processing agreement and read who is controller and who is processor for the peer-side data, which is often left vague. Ask for a current subprocessor list, and check it against the upstream resale question you already asked. Ask what lawful basis the vendor relies on for peer participation and how withdrawal is honoured operationally, not just contractually. If the vendor's answer to any of these is that the SDK collects no personal data at all, that is a meaningful claim and it should be in writing, because Infatica for one has put it in writing already.

The procurement pack

Send this as a single request rather than drip-feeding questions. A serious vendor answers it in a week.

1. Pool composition disclosure. What percentage of the residential pool comes from your own SDK, your own rewards client, leased ISP allocations, and upstream resale? Break it down by the countries we will target.
2. The consent screen. A screenshot of the screen an end user sees, and confirmation of whether it is your screen or the host app developer's.
3. The end-user-facing policies. The SDK or rewards-app privacy policy and terms, as published to end users, not the customer-facing versions.
4. Sourcing policy. Your published conditions on partner apps, and what happens to a partner that breaches them.
5. Opt-out and takedown. How a device owner removes their device, how long removal takes, and the public route for a non-customer to report an enrolment.
6. Upstream list. Which providers you resell from, if any.
7. DPA and subprocessors. Current versions, with the controller and processor roles specified for peer-side processing.
8. KYC and acceptable use. Your customer vetting process and the use cases you refuse.
9. Certifications. ISO, SOC 2 and any industry membership, with the distinction between certified and in progress stated explicitly.

Score the responses on specificity, not on tone. "We take user consent extremely seriously" is a non-answer. "Only opt-in users become nodes, through our consent screen, and partner apps must expose an opt-out in a settings menu" is an answer, because a partner app could visibly fail it.

Choosing on this basis

If your compliance review is real and you will be asked to defend the pool's provenance, the cost of that defence is a slower purchase. Bright Data publishes the most and gates access behind human review; Infatica and Evomi publish enough to work from and are easier to reach. All three make sense for a team that expects the question to come up.

If you are running a short project, testing whether a target is even worth collecting, and nobody is going to ask, PacketStream's no-minimum model or a trial tier gets you an answer for the price of an afternoon. Just do not let a project bought on those terms quietly become the production pipeline, because the documentation gap does not close on its own.

And if you are running two vendors for redundancy, test the overlap before you rely on it. The Bright Data and Oxylabs comparison covers where the two largest networks diverge on everything else, and the 2026 scraping stack puts the proxy layer in the context of the rest of the pipeline. But the overlap question sits underneath both, and it is the one that decides whether your failover is real.