Transparency, not trust

In May 2015, security researcher Vectra Networks proved that Hola VPN — a free consumer VPN with 47 million users — had quietly turned every one of those users into the supply side of a B2B residential proxy network called Luminati. Users had clicked through a vague Terms of Service, downloaded a free VPN, and unknowingly become exit nodes for a scraping operation that, in at least one documented case, was used to launch a denial-of-service attack against the imageboard 8chan. The scandal redefined how the industry **talks** about consent. It did not change how the industry **operates**. Bright Data (the rebranded Luminati Networks, now spun out from Hola) is a $300-million-a-year business. Honeygain, Pawns, IPRoyal, EarnApp, PacketStream — all run essentially the same model: provider downloads software, Terms of Service includes a clause about bandwidth sharing, customers buy bytes, provider gets paid. The transparency layer that Hola's scandal called for in 2015 never materialized in the eleven years since. Why? Because **transparency is expensive for everyone who is not already transparent**. The economics of retrofitting daylight onto an opaque network undercut every revenue stream the opacity supports. ## What the incumbents would have to do to match us To match iogrid's transparency promise, an existing residential-proxy network would have to do four things, each of which costs them a revenue stream: **1. Show every customer's identity to every provider.** Their B2B customers — who pay $10–$20 per gigabyte for opacity — would revolt. Most enterprise scraping operations explicitly do not want the provider knowing who is scraping what. This is a feature for the customer and a bug for the provider, and the incumbents have priced it accordingly: opacity is the product. **2. Categorize traffic at the gateway.** Their existing architecture mostly TLS-terminates the customer's request and forwards it. Adding per-request classification — "this is an e-commerce price check, this is an SEO rank lookup, this is an ad-verification request" — means rebuilding the data plane around a streaming classifier. The classifier itself is not technically hard. The hard part is making it accurate enough that providers trust the labels, which requires customer-declared purpose at API-key issuance time plus destination-ASN cross-checks plus URL-pattern heuristics. We do this. The incumbents do not. **3. Let providers block customers.** A provider blocking your enterprise customer can break that customer's workflow mid-run. Bright Data sells SLAs that assume uniform pool access; provider-level granularity makes those SLAs un-deliverable. We accept the SLA cost because we believe provider control is non-negotiable. **4. Publish provider statistics honestly.** Real provider counts, real bandwidth distributions, real geographic breakdowns. Several incumbents inflate their stated provider count by factors of two to ten. Showing the truth means showing how thin the pool actually is in some regions and during some hours. We publish quarterly, starting Phase 1. None of these are insurmountable engineering problems. They are business problems: each one undercuts a revenue stream the incumbents already collect. A new entrant who starts with transparency baked in does not have those revenue streams to defend, which is exactly why we built iogrid this way. ## What iogrid publishes, in detail The opposite assumption from the incumbents: the network is **producer-owned**. Providers should know everything that happens on their hardware. Customers can negotiate for selective opacity (we offer a customer-name redaction tier at a $0.20-per-gigabyte premium), but the default is full daylight. The audit feed each provider sees, updated in real time: - **Category.** E-commerce price monitoring, SEO check, ad verification, AI training data, lead generation, brand protection, threat intel, social-media intelligence, travel aggregation, or "other". Pre-classified at the gateway via destination ASN, URL pattern, and customer-declared purpose at API-key issuance time. Mislabeling is detectable cryptographically (next section). - **Destination.** The target domain. Not the full URL, not the payload, not the response — just where the request went. - **Customer.** The business name. (Customers who opt into the redaction tier display an alias.) - **Bytes.** How much data transited. - **Timestamp.** When, to the second. Providers can block any category, any customer, any destination — at any time, with one click. The next request to a blocked target routes to a different provider whose policy allows it. Customers do not notice the re-routing because the pool dynamics handle it automatically. The customer's audit log shows the mirror image: per-request, the chosen provider's country and ASN class, the bytes-out and bytes-in, the category they declared, and the response code. The customer can prove their own usage to compliance auditors. ## The cryptographic part Categorization happens at our gateway. Providers might reasonably wonder: how do they know the labels are honest? What if we told the customer "this was e-commerce" while telling the provider "this was something else"? The answer is **cryptographic audit-log replication**. Every byte the gateway labels is signed under the gateway's signing key and appended to two logs simultaneously: the provider's local audit log and the customer's invoice audit log. The two logs are content-addressed. If the gateway told one party "this was e-commerce" and the other "this was SEO," the discrepancy would be a single-bit difference between the two signed records, visible to anyone running the audit-verifier tool we ship open-source under AGPL. In Phase 2 we plan to add Merkle-tree anchoring to a public chain (Solana via OP_RETURN-equivalent on-chain commitments) so the audit log itself has tamper-evident provenance. That is not in the day-one launch — but the architecture is built around it. If iogrid ever rewrote a historic audit record, the chain anchors would prove it; if we ever turned off the anchoring, the gap in the chain would be the alarm bell. For the security model that makes this verifiable end-to-end, see [docs/ARCHITECTURE.md](https://github.com/iogrid/iogrid/blob/main/docs/ARCHITECTURE.md) — particularly the security-model section that walks through the three threat scenarios (malicious customer, malicious provider, IP-reputation collateral damage) and the mitigations for each. ## Why this is a moat Bright Data cannot claim transparency credibly because they are literally Hola's lineage — the same company, renamed, with most of the original infrastructure intact. Honeygain and Pawns built their data planes on opaque-by-default infrastructure and would have to rebuild to match our categorization granularity. Salad has transparency on the compute side but no residential-bandwidth product. Mysterium has the architectural ingredients for transparency but stayed crypto-niche and never built the customer-side audit verifier or the quarterly transparency report. The window to define what "transparent mesh network" means is open right now. Once a generation of providers has been conditioned on the iogrid dashboard's level of disclosure, they will not accept anything less. Our bet is that the incumbents will spend the next three years arguing about whether to retrofit transparency, by which time the new provider supply will already be on us. ## What we will publish, quarterly Starting Phase 1, in a transparency report published on the public blog: - Real provider count by country (no inflation, no rounding-up) - Real bandwidth by category, as percentages and absolute bytes - Anti-abuse hit rates: how often the pre-flight filter catches an attempted CSAM hash, a phishing destination, a sanctioned ASN, a port-restricted protocol - Customer concentration: top-10 customers as percentage of revenue - Provider earnings distribution: median, 25th, 75th, and 95th percentiles - Number of customer accounts terminated for policy violations and the categories of the violations In Phase 2, the daemon itself becomes open-source under AGPL. Any provider can audit what their machine is actually running, byte-for-byte, against the source we ship. The build is reproducible. ## The trust contract We do not ask you to trust us. We give you the receipts. The receipts are cryptographically signed, content-addressed, dual-replicated to provider and customer, anchored to a public chain in Phase 2, and audited by an independent third party annually. Every claim in this post is verifiable, today, by running the audit-verifier tool against your own iogrid account's logs. That is the whole product. We sell transparent infrastructure to people who are tired of being asked to trust the un-trustworthy. The market for that is large enough. For the technical architecture that makes the transparency promise enforceable, see [Why Rust for the edge](/blog/why-rust-for-the-edge). For why a mesh network can do this and a data center cannot, see [Why a mesh, not a data center](/blog/why-mesh-not-datacenter). For the network's launch and tokenomics playbook, see [iogrid from day one to TGE](/blog/gridfish-from-day-one-to-tge).