Why a Distributed Proxy Network Matters

AI agents, researchers, and automation pipelines need raw internet data at scale. Single-datacenter proxies get rate-limited, fingerprinted, and blocked within hours. Residential and distributed networks solve this by spreading requests across many endpoints, but they usually hide how routing works, who is paying for it, and whether the operator can read the traffic. Crypto iGroup’s proxy network is a first-principles answer: an encrypted tunnel, a wallet-bound identity per endpoint, transparent per-proxy accounting, and a selection policy that any observer can audit.

Core Launch: The Share-Bandwidth Model

This is the core launch of the network. The single most important capability shipping today is share-the-bandwidth: an external operator can register an endpoint, publish it to the platform, and have that endpoint serve real traffic to real clients without writing any routing logic themselves. The tunnel is symmetric — either side can be the one terminating it — so a residential machine, a VPS, or a dedicated SOCKS5 box all plug into the same system with the same authentication flow and the same accounting.

Monetization is not in this release. There is no payment rail, no payout schedule, no token emission for bandwidth yet. What ships today is the plumbing that makes those later episodes a policy change rather than a rewrite: identity, accounting, selection, and telemetry, all wired end-to-end and auditable on-chain via the operator’s wallet.

Encrypted Tunnels and SOCKS5 Compatibility

Every connection between the client and the endpoint is wrapped in a ChaCha20-Poly1305 AEAD tunnel (RFC 8439) over TCP. The framing is a fixed 2-byte length prefix, a 12-byte monotonic nonce counter, and the AEAD ciphertext with its Poly1305 tag. Nonces are strictly monotonic per direction, so reordering, replay, and truncation are rejected before any decrypt work is attempted — a replayed frame fails the counter check, and a tampered frame fails the tag check. Both outcomes close the connection.

Inside the tunnel, the payload is standard SOCKS5 (RFC 1928) with optional RFC 1929 username/password authentication. The client binary binds 127.0.0.1:1080 and is the only process the browser needs to know about; it performs no SOCKS5 parsing and no DNS resolution — both happen server-side, inside the tunnel, over DNS-over-TLS (RFC 7858). The practical effect for a browser using the network is that an observer between the client and the endpoint sees only an opaque encrypted stream. Destination hostnames, credentials, and HTTP payloads are not on the wire.

Source and full protocol notes: github.com/cryptoishere/socks5-tunnel-pub.

Wallet-Based Identity and Transparent Accounting

Every endpoint in the network is identified by a Solana-style base58 wallet address (for example SaYtzz7xvaAoCAE6wm68xUEgCA4PBR4DkX). The address is the primary identity: it binds the endpoint to the operator’s wallet, it is what the client uses to authenticate to the tunnel, and it is what the platform uses to attribute traffic. Upload and download counters are per-proxy and updated atomically in the database, so concurrent clients of the same endpoint never race each other’s accounting. When monetization does arrive, those counters are the substrate the payout logic will read from — no new instrumentation is required.

Because identity is a wallet, the same primitive that will later settle payments is the one authenticating connections today. That is the whole point of getting the core launch right before adding money to the system: the identity layer, the transport layer, and the accounting layer all have to line up before a single cent moves.

Built-In Bot Protection for Clearnet Access

The network is explicitly designed to reach the clearnet — the ordinary web — without pretending to be a Tor replacement. Every endpoint carries a built-in admission-control layer that runs before authentication: a per-IP token-bucket rate limit, a per-IP concurrent-connection quota, and a strict tunnel handshake. A client that has not presented the shared secret is dropped at the first byte; there is no plaintext SOCKS5 path exposed to unauthenticated scanners. On top of that, the round-robin selection layer penalizes endpoints that fail or time out, so a client receiving a bad endpoint is statistically likely to be routed to a healthy one on the next attempt. This is the closest thing to bot protection that belongs at the proxy layer — anything stronger belongs in the client, and anything weaker is security theatre.

What Comes Next: Monetization and Reputation

The next episodes will layer two things on top of this core: monetization (payouts for endpoints that serve traffic, priced in USDT and settled on-chain) and reputation (a penalty and reward score that lets the network prefer fast, reliable endpoints without centralizing selection). Neither requires a protocol change. The tunnel and the accounting are stable; monetization adds a payment instruction, and reputation adds a scoring instruction. That is why shipping the core now matters: it is the last release where the moving parts are allowed to change shape.

Get Started

The proxy network is live under the Web Data section: crypto-ig.com/web-data/proxy. Connect your wallet, register an endpoint if you want to share bandwidth, or use the platform-listed endpoints if you are a client. The endpoint list, the traffic counters, and the per-proxy status are all visible in the interface — no hidden state, no proprietary dashboard, no API key to fetch before you can see what you are routing through.