HOW AN AUTONOMOUS AI-NATIVE PEER NETWORK WORKS

1. THE CLAIM

An AI agent holding nothing but a crypto wallet can discover a price sheet (HTTP 402), pay USDC on Base or Solana, and receive a working mobile-proxy credential in seconds. The supply behind that credential registered itself through open SDKs, was health-graded by autonomous probes that tunnel through it like a real customer, was listed for sale by a cron that runs every minute, and is metered and capped by the same billing pipeline human resellers use. The network's own AI observes, diagnoses, fixes, and deploys improvements to all of it.

No human is in the purchase loop. Humans sit at exactly the gates where they should: money movement, authentication changes, mass deletion, infrastructure.

That is the whole thesis. The rest of this page is how each stage actually works, with the real endpoints, the real failure modes we hit, and the constraints we have not solved yet. Everything here is verifiable against the live API - see section 10.

The loop, end to end

1. SUPPLY      a phone, desktop, or modem registers itself        POST /v1/peer/register
2. TRANSPORT   relays mesh it to the nearest region               WSS + WireGuard, server-steered
3. GRADING     a probe tunnels through it like a real customer    CONNECT + TLS + throughput
4. LISTING     an every-minute cron lists healthy peers,          listedForSale flips itself
               delists broken ones
5. SALE        an AI agent pays USDC against an HTTP 402          GET/POST /v1/x402/pool
6. METERING    every byte is counted in 5-second flushes;         credential suspends itself at cap
7. SETTLEMENT  suppliers accrue per-GB earnings at                rates are live data, not constants
               admin-set rates
8. UPKEEP      the network's own AI maintains the loop,           human-gated, kill-switchable
               under hard guardrails

2. ARCHITECTURE: DEVICES -> RELAYS -> GATEWAY -> SELECTION

Four hops separate a customer request from an exit device. Each hop is owned by a different subsystem with a single responsibility.

 [Android / Node / Go / Windows peers]      [standalone modem farms]
        |                                            |
        | WSS, JWT in Sec-WebSocket-Protocol         | HTTP (per-modem ports)
        v                                            |
 +----------------+                                  |
 |  Relay  EU     |                                  |
 |  Relay  US     |<--- WireGuard mesh --+           |
 +----------------+     (private net)    |           |
        ^                                v           v
        |  binary tunnels        +---------------------------+
        |                        |   Pool Gateway            |
   peers dial the                |   gw.proxies.sx:7000 HTTP |
   NEAREST relay;                |   :7001 SOCKS5            |
   the relay can move            +---------------------------+
   them at runtime                       ^          |
   (relay_redirect)                      |          v
                                 +-----------------------+
 +----------------+   probes,    |  Redis endpoint pool  |
 |  Backend API   |   rollups,   |  atomic Lua selection |
 |  api.proxies.sx|------------->|  per-endpoint caps    |
 +----------------+   auto-list  +-----------------------+

The hops

The username DSL: routing as data

The proxy username itself is the routing request. It is lowercased and split on -, so no token value may contain a hyphen:

psx_<account>-<pool>-<country>[-sid-<8-64 a-z0-9_>][-rot-<mode>][-carrier-..][-city-..]

# pool:    mbl (production modems) | peer (community devices)
# rot:     sticky | hard | auto5 | auto10 | auto20 | auto60 | ondemand
# example: psx_x402pool-mbl-us-sid-myjob123-rot-sticky

Two honest sharp edges, by design: (1) sticky pins the MODEM, not the IP - mobile carriers re-issue NAT egress IPs on their own schedule, so a perfectly pinned modem can still surface different exit IPs. For a held IP you want a residential peer or a dedicated modem. (2) stickiness requires a -sid- - without a session id, every connection is a fresh pick. We publish both caveats inside the API responses themselves, because an agent that learns them from an error is an agent we lied to.

Full token reference: /skill.md. Live per-country inventory (counts only, never IPs): GET https://api.proxies.sx/v1/gateway/pool/stock.

3. SUPPLY REGISTERS ITSELF

Nobody provisions a peer. A device running any of the SDKs calls POST /v1/peer/register (or the agent path POST /v1/peer/agents/register) and appears in inventory. As of June 2026 roughly 42,000 devices have registered across 82 countries.

Registration is where the first trust decision happens, and it is made server-side:

Registration is rate-limited per IP, devices are capped per supplier key, JWTs expire in 1 hour with revocation generations, wallet changes carry a 7-day cooling period, and withdrawals only ever pay the registered wallet. Supply that onboards itself has to be supply that cannot cheaply lie about itself.

4. THE SELF-HEALING LOOP

A network of self-registered consumer devices is a network where most things are broken most of the time. That is not a flaw to hide; it is the design constraint the whole quality system is built around. The loop has four mechanisms.

4.1 Probe v2: grade the path the customer actually takes

The first probe generation tested peers with simple HTTP forwards - and passed devices that failed every real customer request, because real traffic is CONNECT-tunneled TLS, and a common SDK failure mode dies exactly at the TLS handshake inside the tunnel. The lesson is now doctrine: measure the signal the customer experiences, not a proxy for it.

Probe v2 opens a raw TCP connection to the relay, issues a CONNECT through the peer, performs a TLS handshake over the tunnel, then fetches a real body and measures throughput. Each probe records:

probeMode:        connect_v2
tlsHandshakeMs:   where broken SDKs die
throughputKBps:   body bytes / time (only when the body is large enough to be meaningful)
speedTier:        fast | medium | slow | unknown
failureReason:    stable codes, e.g. tls_dropped_*, probe_overall_timeout, no_exit_ip

Speed tiers translate directly into capacity caps in the Redis pool, so a slow peer physically cannot be oversubscribed:

4.2 Recovery without permanent exile

The subtle failure of quality gates is not letting bad peers in - it is never letting recovered peers back. Two real bugs taught us that:

• The deadlock: demotion set a review flag that promotion required to be absent. Flagged peers could never return, no matter how healthy. Thousands of working devices sat dark until the gate was rewritten.
• The poisoned average: recovery once required a lifetime success rate above 0.6. A peer that failed ten probes while its owner's wifi was down, then came back perfect, carried a ~0.09 lifetime rate - stranded forever by its own history.

The current gate uses consecutive recent successes: two clean passes in a row readmit a peer, regardless of history. Demotion stays fast (three consecutive failures delist), readmission is history-free, and both directions are pure code - no human backfills.

4.3 The every-minute economy of listing

An auto-list cron runs every minute: verified, healthy, fast-enough peers get listedForSale = true; degraded ones get pulled. When a live customer tunnel fails mid-stream, the gateway reports it and a debounced single-peer re-probe fires within seconds - a data-plane circuit breaker pauses a peer that accepts tunnels but drops bytes. Fault-to-delisting convergence is under 60 seconds, down from the ~30 minutes a fixed probe cycle gave us.

4.4 One source of truth, plus a watchdog that distrusts itself

Every dashboard, admin page, and ops query reads the same materialized rollup, which is itself derived from the gateway's live Redis state - the thing that actually routes customers. We adopted this after discovering the same metric computed four different ways in four surfaces, all disagreeing. Now disagreement is impossible by construction.

Above it all sits a fleet watchdog that runs synthetic probes - it buys and routes like a real customer on a schedule. Two design choices make it trustworthy:

• It classifies self vs fleet: if its own test account is broken, it says "watchdog impaired", not "network down".
• It never auto-restarts infrastructure. It escalates with remediation guidance attached. Restarting things is a human decision, and that boundary is deliberate.

5. THE AUTONOMOUS ECONOMY: x402 USDC, METERING, CAPS

This is the newest piece and the point of the whole system: the network is bought by machines, without accounts. Two products share the machinery: a dedicated port (/v1/x402/proxy) and, since June 2026, full Pool Gateway access (/v1/x402/pool) - one USDC payment buys one credential that reaches every country in its tier through the username DSL.

5.1 The purchase: the 402 IS the catalog

agent wallet                          api.proxies.sx                    chain (Base / Solana)
     |                                      |                                  |
     |  GET /v1/x402/pool?traffic=1         |                                  |
     |------------------------------------->|                                  |
     |  HTTP 402: payTo, USDC asset,        |                                  |
     |  exact micro-USDC amount, tiers,     |                                  |
     |  live country enum                   |                                  |
     |<-------------------------------------|                                  |
     |  transfer USDC on-chain              |                                  |
     |--------------------------------------------------------------------->  |
     |  retry + Payment-Signature: <txHash> |                                  |
     |------------------------------------->|  verify the tx ON-CHAIN:         |
     |                                      |  recipient pinned, asset pinned,  |
     |                                      |  amount in integer micro-units    |
     |  proxy credentials + sessionToken    |                                  |
     |<-------------------------------------|                                  |

There is no API key step, no signup step, no human step. The 402 response is machine-readable and self-describing: an agent that has never seen Proxies.sx can go from discovery to working credential in two HTTP requests and one on-chain transfer (~2s on Base, ~400ms on Solana).

5.2 Payment verification: the paranoid parts

5.3 The mechanism: connect two finished halves

The Pool Gateway purchase contains almost no new billing code, and that is its most important property. A verified USDC payment mints a capped pool access key under a dedicated house account inside the existing reseller pipeline. The key's GB cap IS the USDC envelope. From that moment the agent's credential is metered, capped, audited, suspended, and topped up by the exact machinery that already serves human resellers in production:

verified USDC tx
   -> mint pak_ key, cap = purchased GB, expiry = session expiry
   -> credential: psx_x402pool-mbl-<country>-sid-..-rot-..  @  gw.proxies.sx:7000
   -> every connection metered in 5s flushes (atomic counters)
   -> at cap: key suspends itself (enabled=false) within ~5-35s, audit-logged
   -> topup: more USDC -> more GB, replay-guarded, re-enables a suspended key

Token = X-Session-Token: x402s_<hex>. x402 = Payment-Signature: <tx_hash>. The sessionToken is the only recovery handle - agents should persist it.

5.4 Quality is enforced at routing time, not promised

v1 sells one tier: mbl at $4/GB - production modems. The minted key carries a quality contract that the gateway enforces at routing time: any attempt to route it toward the community peer pool is silently rewritten back to production modems. The agent cannot opt into the worse pool by editing its username, which means a first-purchase agent cannot have a bad first experience because of community-tier variance. Community peer tiers will be sold only when the same per-request enforcement exists for IP-type targeting - until then they are feature-flagged off.

v1 honesty box: HTTP on :7000 only. Per-GB metered, duration is free (default 30 days, max 90). Minimum purchase 0.1 GB. No refunds of unused GB. Cap suspension lands ~5-35 seconds after the cap (metering flushes every 5 seconds). Sticky pins the modem, not the IP.

6. SUPPLIERS GET PAID

The demand side is machine-native; the supply side is a marketplace of humans and their devices. Every byte a peer or modem serves accrues earnings to its owner.

One honest note on maturity: the modem-farmer settlement ledger is the production-hardened path. The SDK-peer settlement pipeline (rolling per-device accruals into the same auditable ledger and payout flow) is the active engineering frontier - accrual is live, the consolidated ledger is being built deliberately rather than quickly, because it moves money.

7. THE AI OPS BRAIN

The network is not just sold to AI agents - it is substantially operated by them. This is the part most platforms claim and few constrain. Ours is constrained first, capable second.

The components

The autonomy boundary, in one sentence

Autonomous actions must be read-only, or reversible and capped. Everything else - moving money, changing authentication, mass deletion, touching infrastructure - goes to a human approval queue.

That sentence is enforced in code, not policy:

8. THE FULL CIRCLE

Put the stages together and you get something genuinely new: an AI agent buys access to a network that an AI maintains, built from supply that enrolled itself, and the proceeds pay human and machine suppliers - with cryptographic verification at the money boundary and human judgment at the risk boundary.

        +------------------------------------------------------------+
        |                                                            |
        v                                                            |
  device enrolls -----> probes grade it -----> cron lists it         |
  (open SDKs,           (CONNECT+TLS,          (every minute,        |
   ASN-classified)       speed tiers)           self-recovering)     |
                                                       |             |
                                                       v             |
  supplier paid <----- bytes metered <----- AI agent pays USDC       |
  (per-GB, live         (5s flushes,         (HTTP 402 catalog,      |
   rates, wallet)        cap = envelope)      no account)            |
        ^                                                            |
        |             the network's own AI observes,                 |
        +------------ diagnoses, fixes, deploys ---------------------+
                      (human-gated, kill-switchable)

Why the architecture made this cheap

The autonomous sale - the headline feature - required almost no new code, and that is the deepest point in this document. The on-chain payment verifier already existed (the dedicated-port x402 product). The metered, capped, audited credential pipeline already existed (the reseller platform). Shipping "an AI agent buys the network" meant writing the glue: a quote function, an idempotent mint, and an attach guard. Both halves were already production-hardened, so the new product inherited years of invariants - replay protection, atomic accounting, audit trails - on day one.

That is the repeatable thesis for AI-native infrastructure: do not build an autonomous economy; make your existing economy legible to machines. The 402 response is just a price sheet a machine can read. The username DSL is just routing a machine can write. The pak cap is just a prepaid balance a machine can spend. Every piece works identically for a human with a dashboard - the machine path is the same path with the human steps deleted.

9. HONEST CURRENT STATE AND CONSTRAINTS

A thesis you cannot falsify is marketing. Here is what is true right now, including the parts that do not flatter us.

What we will not claim

• We will not claim the peer pool is production-grade today. It is the emerging tier, priced and gated accordingly.
• We will not claim sticky sessions hold an IP. They hold a device.
• We will not claim full autonomy. The system proposes; humans approve money, auth, deletion, and infrastructure - on purpose, permanently.
• We will not publish peer exit IPs to prove inventory. Counts only.

10. VERIFY IT YOURSELF

Every load-bearing claim on this page is checkable from a terminal, unauthenticated, right now:

# 1. The catalog an agent discovers (200, tier list, networks, DSL)
curl -s https://api.proxies.sx/v1/x402/pool/pricing

# 2. The 402 IS the price sheet (no payment -> machine-readable catalog
#    with the pinned recipient and exact micro-USDC amount)
curl -s "https://api.proxies.sx/v1/x402/pool?tier=mbl&country=us&traffic=0.1"

# 3. Live inventory, counts-only, per country (no IPs - by design)
curl -s https://api.proxies.sx/v1/gateway/pool/stock

# 4. The machine-readable version of this entire platform
curl -s https://agents.proxies.sx/skill.md
curl -s https://agents.proxies.sx/llms.txt
curl -s https://agents.proxies.sx/.well-known/x402.json

To watch the full circle close: pay the 402 with USDC on Base or Solana, retry with Payment-Signature: <tx_hash>, and route a request through gw.proxies.sx:7000 with the credential you get back. Then call /v1/x402/manage/pool/credit with your session token and watch the bytes you just used decrement the cap your payment minted.

Further reading