SparkProxy vs Massive: IP Sourcing and Compliance

Security questionnaires for proxy vendors converge on the same short list. Where do the addresses come from. What did the person on the other end agree to. What does the client software read. What audits exist and can I see the report. How long is data kept. What happens when a customer abuses the network. Which law governs the contract.

These two vendors do not face the same version of that list, and missing it is the most common mistake in a comparison like this. Massive's docs describe "more than 1,000,000 residential computers and devices" enrolled through an SDK, so its provenance question is about disclosure, consent and audit, and a buyer cannot check the answer independently. SparkProxy's homepage describes "Over a million premium datacenter IPs, refreshed continuously to stay unblocked and anonymous." Nobody's household sits in that path, so provenance becomes a registry question: which ASN announces the range, who holds the allocation, and does the exit address's WHOIS record match what you were sold.

That one you can answer yourself, and you don't have to ask either vendor:

# Pull an exit address through the proxy, then check that address in public registries
IP=$(curl -s --proxy http://USER:PASS@gateway.sparkproxy.io:11000 https://api.ipify.org)
whois "$IP" | grep -Ei 'netname|orgname|country|descr'
# reverse the octets to ask Team Cymru which ASN announces that exact address
dig +short TXT "$(echo "$IP" | awk -F. '{print $4"."$3"."$2"."$1}').origin.asn.cymru.com"

Run that across a few hundred exits and you have verified what kind of address you are buying. There's no equivalent test for consent, which is a paper and process question, and that's exactly why the vendor publishing more paper holds a real advantage. Background: where residential proxy IPs come from and BGP and RIR allocations as a signal of IP origin.

Massive states its position in direct language and repeats it across the site. The docs say the network "includes more than 1,000,000 residential computers and devices in more than 195 countries around the world. 100% of these computers and devices have been explicitly opted in by users through the Massive SDK for app developers." The startup page adds a supply-chain argument: "Most proxy providers buy IP capacity from aggregators and can be cut off without warning. Massive owns its supply through opt-in volunteer devices on the Massive SDK."

Pool numbers need care, because Massive publishes three that disagree. The docs give "more than 1,000,000" enrolled devices. The knowledge base gives a dated, smaller operational set: "As of August 2025, our network consists of: Over 750,000 Daily Active Users / 400,000+ concurrent IP addresses." For capacity planning, 400,000+ concurrent is the honest figure, and it is Massive's own.

Massive's "No sub-pool restrictions" deserves credit; plenty of residential vendors meter a premium sub-pool separately, and Massive publishes that it does not. One caveat covers both columns: every figure above is vendor self-report, because nobody in this market publishes an audited pool census, which is why pool size claims move around.

Massive's /consent page sets out four commitments to the people whose bandwidth it resells, and paraphrasing would weaken them. On disclosure: "The request appears at install, on its own screen, before anything is running and not as a clause inside a license agreement. Nothing is ticked on your behalf, and the installer will not continue until you tick it yourself." On reversibility: "The sharing has an on/off switch in the app's own settings." On removal: "Uninstalling the app removes the sharing with it. No separate uninstaller, no leftover service." And on the trade itself: "Bandwidth, not data."

Two further statements on that page matter more to a reviewer than the pillars do. First, enforcement: "Every partner app reaches the network through our SDK, and every one of them can be switched off from our side." A commitment with a kill switch behind it is a different object from one without. Second, a device-safety guarantee: "Your home network, your loopback interface and cloud-metadata endpoints are unreachable from a customer session." That is server-side SSRF containment for the participating household, and it is the most important technical control in a peer network.

Now the tension, stated neutrally because that is all the evidence supports. The consumer-facing /consent page says the request "appears at install, on its own screen, before anything is running." The partner-facing /getpaid page tells app developers: "You control when and how the consent prompt appears." Massive's standards document bridges the two by recommending that operators require host apps to "present the full consent flow unmodified" and "review each integration against these requirements before launch." All three are Massive's own current pages. Whether prompt timing is contractually enforced or configurable per partner is not published, and it is the first question we would put to Massive.

SparkProxy publishes nothing comparable, and pretending otherwise would be useless to you. There's no consent page, because the pool described on its site is datacenter infrastructure rather than peer devices, so there is no household to disclose anything to. That removes the question rather than answering it, and it is the reason the sourcing rows in the questionnaire below read "Not applicable" rather than "Not published": we sell datacenter capacity, so there is no peer supply chain of ours to disclose. If you buy residential capacity from any vendor, put these same questions in writing and keep the reply.

The SDK is the whole mechanism, so its published behaviour is the heart of the diligence. Massive tells partners it "Collects zero personally identifiable information", "Samples only anonymous network telemetry", is "Idle-only, pauses when device is in active use", and ships a "Drop-in consent UI with full audit trail".

Platform coverage is published twice with different lists. The partner page says "Supported on Android, SmartTV, Fire TV, Windows"; the docs say "The Massive SDK is available on Android, FireOS, iOS, Tizen, and WebOS" plus Windows. The docs list is broader and explains the supply shape, which is why device-type targeting exposes a tv value at all.

The SDK privacy policy is the most specific document either vendor publishes, and it enumerates both sides of the line.

The same page lists its practices as "100% opt-in: users must explicitly consent", "All code runs in a sandboxed environment", "Data is never sold to third parties" and "No tracking of browsing habits or online activity". Participants can "[o]pt out at any time through application settings", and on Android or Fire OS with a foreground service, "Opt out via the notification interface."

Partner economics are published in aggregate only: "$2M+ Paid to SDK partners in 2025", monthly payouts by PayPal or wire, and a case study citing roughly a 38% opt-in rate at the prompt for a 250,000-DAU SmartTV app. The revenue-share percentage appears nowhere, so you cannot check how much of the money reaches the person whose line you are using. Fair to ask about, bad to assume about.

Massive's homepage compliance strip reads, verbatim: "SOC 2 Type 1 audited", "GDPR + CCPA compliant", "AppEsteem certified", "AMTSO member", "99.9% uptime SLA", "Engineers who answer engineers", "Verified consent", "KYC on every client".

Two points of precision here, both of which most competing articles get wrong.

First, Massive's own live pages name two different report types on the same day. "SOC 2 Type 1 audited" appears in the compliance strip on the homepage, /web-access, /isp-proxies, /web-render and /web-search. "SOC 2 Type II" appears on /massive-for-startups. The difference is material: a Type 1 report opines on the design of controls at a point in time, a Type 2 on their operating effectiveness across a period, and a reviewer who accepts a Type 2 will not accept a Type 1. This is not evidence of anything except inconsistent web copy. The useful action is to ask which report is current and request it under NDA. Massive publishes no trust portal, no report-request page and no audit-period dates, and no ISO 27001 claim appears on its site.

Second, retention. Massive publishes no retention period for participant data or for customer request logs. A keyword scan of /privacy and /monetization-sdk-privacy-policy for retain, retention, delete and any day or month window returns nothing; the only retention-adjacent commitment is "IP address (used for network routing only, not stored)". The widely repeated 60-day figure comes from Massive's /best-practices document, which recommends a "Retention cap. Participant-side data purged on a short fixed schedule (60 days is an achievable industry benchmark)". That document is subtitled "Recommendations for Policymakers and Standards Bodies", is written throughout in the recommendation voice, and is addressed to policymakers. It is not a statement of Massive's own practice, and quoting it as one is wrong.

It is still the most substantial published position of its kind in this market, built on four pillars: consumer consent and disclosure, consumer data protection, device-level technical safeguards, and customer vetting. Its recommendations include affirmative opt-in with "No pre-checked boxes", "Accept and decline options presented with equal visual weight", disclosure of "what device resources are used (bandwidth, CPU, electricity)", one-click opt-out, re-consent on material change, "Server-side enforcement as the floor" for private-range egress blocking because "deployed client software updates slowly", and KYC with "sanctions screening (OFAC, EU, UK, UN)".

Read that table honestly and Massive wins this section outright. If your purchase has to clear a security questionnaire before it clears finance, that gap is worth more than a per-GB rate.

This section is the one most likely to decide your purchase, which is why it's here and not after the price list.

Massive's "Blocked Destination Categories" policy, last updated 16 July 2026, states: "Massive blocks requests to the following categories of destination at the network layer. Category lists are sourced from third-party, industry-standard blocklist providers and are refreshed automatically on the provider's release cycle." The list covers malicious infrastructure, traffic manipulation, adult content, gambling, weapons, extremist content and remote access, plus two that matter commercially: "Financial services and digital currency. Banks, credit unions, payment processors, card networks, and cryptocurrency exchanges, wallets, and mining pools" and "Streaming media and live chat. Audio and video streaming platforms, live chat services."

Read those two again if your workload touches them. Bank and fintech rate collection, card-network research, crypto market data, and streaming catalogue or price work are blocked by default at the network layer, and no per-GB rate rescues a brief that cannot reach its targets. See our guides to proxies for bank and fintech rate data and proxies for streaming catalog research.

The waiver path is published and bounded, which beats the usual silence. Blocks are "the default posture applied to every customer at onboarding", and "[c]ategory-level exceptions may be granted to a specific customer where a legitimate business need is established and verified through Massive's customer due diligence process", naming threat intelligence, OSINT, security research, brand protection and fraud investigation as recognised use cases. Exceptions are per customer and per category, "re-reviewed against every list refresh", and withdrawn "if the use case changes". Enabling one means a help-desk request, KYC and approval. One carve-out is absolute: child sexual abuse material "is never subject to exception or waiver, under any circumstance, for any customer, for any stated purpose. There is no review path and no approval path."

Prohibited regardless of destination: DDoS, malware, CSAM, activity targeting minors, spam, credential stuffing, unauthorized scanning, filter circumvention, warez. Sanctions posture covers OFAC, EU, UK and UN programmes and names Cuba, Iran, North Korea, Syria, and Crimea, Donetsk, Luhansk, Kherson and Zaporizhzhia.

SparkProxy publishes no equivalent document at the URLs we probed, and its privacy policy lists no prohibited uses. That cuts both ways: no published category block to design around, and no published policy to hold anyone to. Ask for the acceptable-use terms in writing before you buy. Our explainers on proxy acceptable use policies and why providers require KYC cover what a reasonable answer looks like.

Massive's Network License Agreement, last updated 12 November 2025, answers several questions the marketing pages do not. Invoices are in US dollars, issued within four business days of month end for the monthly minimum plus "overage Use Fees for each GB of that overage", and payable within five. Rollover is one month only: "Any unused GB from the month prior will be rolled over as a credit and redeemable for the following month." Taxes sit with the buyer, so treat the card prices as tax-exclusive, though Massive never uses the phrase ex-VAT and we will not put it in their mouth. The jurisdiction question is answered outright in section 15: the agreement is "governed by and construed in accordance with the laws of the State of Delaware", venue is "exclusively in the state and federal courts within the city of Miami, Florida", and an optional mediation step sits in front of litigation with its costs split equally. The notice block names the counterparty as Massive Computing, Inc. at a Miami, FL address.

Two clauses deserve a reviewer's attention. Minimum commitment is not published at all: "Any minimum purchase commitments will be included in the Statement of Work or online sign up portal", and those terms "supercede the standard Fees in this Agreement." Self-serve card prices can therefore be overridden by contract, in either direction. Separately, the fee clause is triggered "[u]pon the successful completion of the Service trial described in the first paragraph of Article 3", but Article 3 of the published agreement is titled "Service Activation and Deactivation" and its first paragraph describes billing periods, not a trial. The published contract contains no definition of the trial it conditions billing on. A question to ask, not a defect to allege.

Then there is the clause that quietly undercuts every pool number in this post, ours included. Subscriber shall not "map, enumerate, fingerprint, probe, scan, or otherwise discover or disclose the topology, composition, addressing, routing, or operational characteristics of Massive's network or infrastructure (including IP layout, ASNs, internal hostnames, and Network Topology Data)". Normal use of the documented asn parameter is unaffected, but a census of what you are renting is contractually off the table, which is worth knowing before you promise your own auditors that you verified the supply. See how to read a proxy provider SLA for the general shape of these commitments.

SparkProxy's side is short. The legal entity appears as "SparkProxy", the contact is support@sparkproxy.io, the privacy policy was last updated 1 May 2026, no governing-law clause is stated in it, and we found no terms page at /terms, /terms-of-service, /legal or /tos. Plans sell as 30-day packs rather than under a published master agreement.

Unverifiable means we could not confirm it from a published page on 9 October 2026, not that the vendor lacks the control. For a longer version of this grid to take into a vendor call, use our enterprise proxy procurement checklist.

The two vendors have swapped which axis is free. Massive bills the byte and gives you unlimited concurrency. SparkProxy bills the plan and the concurrent thread count, and gives you unlimited bandwidth. Neither is generically cheaper, and anyone who says otherwise hasn't looked at your logs.

Massive's canonical pricing is not at /pricing, which 301-redirects to /web-access. The real section sits on the homepage under "Choose Your Plan", reachable through the #pricing-residential-* nav anchors. The four Developer prices multiply out exactly, which both confirms they were read correctly and tells you what the product is: $80/10 GB is $8.00, $225/30 is $7.50, $385/70 is $5.50, $490/100 is $4.90. These are prepaid bandwidth packs, not subscriptions with an allowance. Residential Enterprise is gated: the tab publishes tier names and bandwidth only (Startup 250 GB, Growth 600 GB, Scale 1 TB, plus a Custom tier), no monthly price for any of them exists in the page source, and only the "From $3.2/GB" floor is published next to "Talk to Sales". Get a quote; do not infer a number, and do not trust a blog that prints one.

Two gaps in the Massive column. The "$1.8/IP" ISP floor states no billing period, and per-IP-per-month is only the category convention. And the Render and Search APIs run on prepaid credits (1 for Search, 5 for AI, 1 for Browser, 10 per minute for Browser CDP, times difficulty and speed multipliers) whose dollar value is published nowhere, while the nav never defines CPM. The real cost of a render cannot be computed from published sources, so ask in writing.

Here is the part worth taking to your own engineering review. Massive's agreement defines the billable unit as "each GB of request headers and payload and response headers and payload processed by the Service." Headers count, in both directions. So do the bytes you never wanted: challenge interstitials, 403 bodies, redirect chains, retries, and the 900 KB of rendered HTML you pulled to extract one price. A per-GB meter charges you most precisely when your scraper is doing worst, which is the opposite of how most people model it in a spreadsheet. The logic cuts the other way too, and the honesty matters: a lean, high-concurrency crawl of JSON endpoints moves very few bytes and can be genuinely cheap on Massive.

Settle it from your own logs instead of arguing about it. SparkProxy's Scraping API returns a measurable envelope when you ask for one, and json_response=true is the only flag that does it:

import base64, requests

API  = "https://scrape.sparkproxy.io/api/v1"
HEAD = {"X-API-Key": "YOUR_KEY"}

def measure(url, render=False):
    r = requests.post(API, headers=HEAD, timeout=120, json={
        "url": url,
        "render_js": render,        # default is true (5 credits); false is 1 credit, ~3x faster
        "proxy_type": "premium",
        "json_response": True,      # the ONLY flag that returns the envelope
    })
    env  = r.json()
    html = base64.b64decode(env["body"])        # body is base64; decode before any matching
    return {"status": env["status_code"], "ms": env["duration_ms"],
            "credits": env["credits_used"], "bytes": len(html)}

urls  = open("targets.txt").read().split()
rows  = [measure(u, render=False) for u in urls]   # swap to render=True for the second pass
total = sum(r["bytes"] for r in rows)
print(f"{len(rows)} pages, {total/1e6:.1f} MB, mean {total/len(rows)/1024:.0f} KB/page")
print(f"at $8.00/GB -> ${total/1e9*8.00:.2f}   at $4.90/GB -> ${total/1e9*4.90:.2f}")

Run it twice, once with render_js=False and once with render_js=True; the ratio between the two byte totals is the real decision. Multiply your monthly page count by the mean, compare against a flat plan, and add margin for headers, retries and challenge pages, because the meter counts those and your extractor does not. Forecasting bandwidth needs and per-IP versus per-GB pricing carry the arithmetic further.

Free entry differs in shape, not just size. Massive's documented trial is 2 GB with "No credit card required", but gated: "Fill out Free Trial form / Partnership manager activates your trial", so a human switches it on even though the pricing buttons say "Sign up free". Massive for Startups is separate, screened and far larger: "1TB/month of free residential proxy bandwidth" for 3 months, "No equity, no contract, no credit card", "Approved in 2 business days", "No feature gating during the program". SparkProxy runs a 24-hour trial, 250 threads, no card.

Targeting is where Massive's documentation is simply deeper, and it is worth being precise about how much deeper.

Massive's targeting syntax rides on the proxy username, which keeps it usable from any client that can set credentials:

# Massive's documented username syntax (docs.joinmassive.com)
{PROXY_USERNAME}-country-US-zipcode-10001:{API_KEY}
{PROXY_USERNAME}-country-US-asn-7018:{API_KEY}
{PROXY_USERNAME}-type-mobile,tv-country-US:{API_KEY}

Massive's own caveat is that country and city targeting hold up better than ZIP-level targeting, which matches what we see and is more candid than most vendors manage. City-targeted and ASN-targeted proxies cover which workloads genuinely need that depth.

Three documented restrictions rule out whole classes of work and are easy to miss: "UDP communication isn't allowed"; "Ports other than the standard 80 and 443 are blocked", so a request to port 8080 is rejected; blocked content returns "452 Disallowed Content" and a blocked port returns "453 Port Forbidden". Port 25 cannot be opened, though 587 or 465 can be requested, and the same rules apply to the ISP network. If your targets live on non-standard ports, that's a hard stop regardless of price. One more for the vendor call: the docs and KB say "Massive ISP proxy networks use AT&T infrastructure", while /isp-proxies says "Frontier-backed ISP infrastructure built for speed". Both are Massive's own live pages, so ask which is current.

On performance, Massive publishes "Real-time (Under 600ms)", "99.8% success" and a "99.9% uptime SLA" on its own pages, plus a third-party result on /book-a-call it did not run: 99.84% success from a "Proxyway independent benchmark: 1,200,000 connection requests, residential global gateway", top 6 of 19 providers tested. That figure belongs to Proxyway as cited by Massive; we neither read Proxyway's report nor ran a head-to-head test here. SparkProxy publishes 99.9% uptime and 99%+ success. Two self-reported numbers from two methods are not a comparison, so run your own provider trial on your own targets.

Send it to Massive when the brief needs the long tail of countries. Massive publishes more than 195 against SparkProxy's 80+, so for global ad verification, worldwide availability monitoring or any brief naming markets outside the top 80, this is not a close call.

Send it to Massive for sub-country precision. Subdivision, city and postal-code targeting, partial codes included, does something SparkProxy does not document at all. Localized pricing checks, store inventory, ZIP-level SERPs: Massive, every time. Same for ASN targeting when you need to reach a site from one carrier's network, and for device-type targeting, where tv opens connected-TV ad verification on Tizen, WebOS and Fire OS that SparkProxy cannot address with a documented switch.

Send it to Massive for long-lived, session-bound workflows. A 15-minute default TTL configurable to 24 hours, with strict, flex and norotate error semantics, plus ISP sessions that never expire, beats 5-minute rotation for anything multi-step and logged in: cart and checkout flows, account dashboards, long paginated crawls. Massive's /web-access page understates this, offering "up to 12 minutes" where the docs document 1440. Believe the docs.

Send it to Massive for short, massively parallel bursts. Unlimited concurrency plus a byte meter means a job that fans out to thousands of simultaneous requests for an hour and then stops pays only for what it moved, with no concurrency tier to buy. A plan-and-thread model penalises exactly that shape.

Send it to Massive if you resell. Its docs cover a reseller API with subaccounts, per-account traffic allocation, daily usage endpoints and per-account domain blocklists. If you invoice your own customers by the gigabyte you need a consumption signal to bill on, and an unlimited-bandwidth plan gives you none. Whitelabel and reseller networks covers the rest of that stack.

Send it to Massive on three more counts, each of which honestly costs us the sale. Eligible startups get a terabyte a month free for three months with no card, no contract, no equity and no feature gating, which beats any paid plan from anyone, ours included. Buyers whose security questionnaire needs paper get a named entity, a dated abuse policy, a published AUP with sanctions screening, documented KYC, a standards document and SOC 2, AppEsteem and AMTSO claims. And teams that want the browser farm and SERP parsing to be someone else's problem get the Web Render API, Web Search API and an MCP server for Claude and Cursor, a real managed offer separate from the raw proxy question.

Send it to SparkProxy when the brief is byte-heavy and the targets are reachable. Browser-rendered crawls of hostile targets, image-heavy catalogue pages, high-retry work behind interstitials: that is where a per-GB meter surprises people and a flat plan does not move. The pool is datacenter, which is also the cheaper and faster answer for targets that do not need a residential exit, and when to upgrade from datacenter to ISP shows where that line sits.

Send it to SparkProxy when your workload touches a category Massive blocks. Fintech, card networks, crypto exchanges and wallets, streaming platforms and live chat are off by default and need a per-category waiver with KYC. If that is the job, start somewhere without the gate.

Send it to SparkProxy when the bill has to be predictable, because finance approves a flat $240 more readily than a meter and a flat plan cannot be blown up by a scraper looping on a 2 MB challenge page at 3am. Pick it when you want a trial running in the next ten minutes, since 24 hours and 250 threads needs no card and no activation call. And pick it when provenance has to be independently verifiable by your own auditors, because a datacenter pool's origin is a WHOIS and ASN question you can answer yourself.

Copy these into an email. The gaps exist because nobody publishes the answers, not because the answers are bad.

1. Which SOC 2 report is current, Type 1 or Type 2, what period does it cover, and can we read it under NDA?
2. What is your retention period for customer request logs, and for participant-side data where applicable? State it in days.
3. Is the consent prompt's timing and placement contractually enforced on partner apps, or configurable by the partner? What happens on a breach?
4. What share of revenue reaches the participant, and how is it disclosed to them at the prompt?
5. What is the minimum purchase commitment on the plan we are quoted, and does a Statement of Work override the published card price?
6. What is one Render or Search credit worth in dollars, and what exactly does CPM count?
7. Which categories are blocked for our account today, and what is the waiver timeline for our specific use case?
8. Does the per-GB meter count request and response headers, redirect bodies, and failed or challenged responses? Confirm in writing.
9. Which upstream carrier backs the ISP product today?
10. Which legal entity are we contracting with, and does any Statement of Work change the governing law or venue in the published agreement?

Then run the test. One target list, two accounts, one afternoon. Measure bytes per useful record and requests per minute at your real concurrency, not a vendor's, and price both outcomes against the ladders above. If the byte total surprises you, that's the answer.