Every proxy provider routes your traffic through someone else's IP address. The question that matters is whose, and how they got it. Our answer: we physically own and operate the modems our carrier IPs run on, and peer supply beyond that comes from partners who sign our agreement and pass checks we run on our own servers. Below is what we require, what we check, and what we do not yet verify.
Two supply sources. Owned hardware on real mobile carriers, plus peer supply from partners who must have the informed consent of device owners, sign an agreement in their legal name and declare where their supply comes from.
The core of our network is physical modems we own on real mobile carriers. We bought the hardware, we installed the SIM cards, we run the racks. When your request exits through one of these IPs, it exits through a device we control end to end - your traffic enters at gw.proxies.sx and leaves on a carrier connection we can point to on a shelf.
That means there is no mystery middle layer: no aggregator we license IPs from, no upstream reseller whose sourcing practices we have to take on faith. If you want to see how requests are routed across the fleet, thepool gatewaypage explains the mechanics.
Beyond our owned modems, partners can connect Android phones, Linux or Windows devices to the network. That supply is governed by a published contract (agents.proxies.sx/peer/skill.md).
What we do not claim: submitted declarations are not independently verified KYC or proof of consent. Identity and business verification is being prepared separately. We do not publish the peer fleet's size or exit IPs.
To see exactly what the software does on a supplier's device, read what runs on my device. To supply bandwidth yourself, start at /earn.
Much of the residential proxy market works differently. Large pools aggregate IPs they do not control - bought from third-party suppliers, harvested through bundled SDKs, or resold through chains of brokers. Some of those IPs were obtained cleanly; some were abused or enrolled without meaningful consent. The operator often cannot tell you which is which, and neither can you. That is not a performance problem - it is a provenance problem, and it lands on the customer whose traffic was routed through it.
| Aggregated pool of unknown provenance | PROXIES.SX supply | |
|---|---|---|
| Who controls the exit device | Unknown - often a broker chain | Us (owned modems) or a supplier under a signed agreement |
| How the IP was obtained | Bought / bundled / resold - varies per IP | Hardware we purchased, or a declared supply source |
| IP type check | Often self-reported | Server-side ASN classification; datacenter rejected |
| Whose consent backs the supply | Often unverifiable | Ours (we own it), or device owners' informed consent required by contract |
| Independent KYC of suppliers | Varies | Being prepared; declarations are not yet independently verified |
In July 2026, the FBI seized the domains of a major residential proxy provider after its supply was tied to a ~2-million-device botnet, as reported by Krebs on Security and The Register. We take no pleasure in that - it was a bad week for a lot of teams who did nothing wrong except trust a supplier.
The lasting lesson is not about one company. It is that every customer of an opaque pool inherited a provenance question overnight: where was my traffic actually routed, and would I be able to prove it was clean? Verifiable sourcing is the only answer that survives that question, which is why we publish what we require and what we check.
Our honest limit: our owned modems do not cover every country, so peer supply extends coverage, and supplier declarations are not yet independently verified. On raw IP volume and enterprise compliance certifications, a giant like Bright Data or Oxylabs is still bigger - if that is what you need, they are the closer fit and we will say so. What we offer is owned hardware plus published supply requirements - and if a supplier outage broke your pipeline, our Data Works team can rebuild and run it for you while you regroup.
The same IPs are available self-serve from $4/GB, down to $2.40/GB at volume. Endpoints, rotation and support are free - you pay only for the GB you use, and GB never expire. If you would rather have the pipeline built and run for you, scope a Data Works project instead.
Pricing verified July 2026.
We physically own and operate the modems our carrier IPs run on, all on real mobile carriers. A typical residential pool aggregates IPs it does not control, often bought from third-party suppliers or SDK bundles, so the operator cannot see how each IP was obtained.
Suppliers may share bandwidth only from devices whose owners have given informed consent. They sign the partner agreement in their own legal name, connect with their own account-linked API key, and declare where their supply comes from: device owners or upstream suppliers, apps and installation channels, country and network mix, and how permission is obtained and withdrawn.
IP type is classified on our servers by ASN; the type a device reports about itself is ignored. Datacenter IPs are rejected for listing. Listed devices are re-verified hourly and unlisted after an hour offline.
Not yet. Submitted declarations are not independently verified KYC or proof of consent. Identity and business verification is being prepared separately. We would rather say that plainly than overstate it.
In July 2026, the FBI seized the domains of a major residential proxy provider after its supply was tied to a ~2-million-device botnet, as reported by Krebs on Security and The Register. Every customer of a pool with opaque sourcing inherits that kind of provenance and compliance question.
Owned modems on real carriers, plus peer supply under published requirements and server-side checks. If provenance matters to your compliance team, bring them to the call.