# AI Proxy

## Overview

Data-center traffic is often blocked or rate-limited. AI Proxy gives AI agents unrestricted access to the open web at significantly lower prices than comparable mobile proxy services.


- [Quickstart for agents](proxy-quickstart.md) — QUICKSTART: How to open a paid AI Proxy gate.
- [Proxy Protocol](proxy-protocol.md) — SPEC: Wire protocol for client implementers, exit operators and integrators.
- [Billing and settlement](proxy-billing.md) — BILLING: Metering, prepaid balances and on-chain settlement.
- [Proxy revenue becomes PHASE demand](proxy-buyback.md) — BUYBACK: How proxy revenue is used to buy PHASE.
- [Security Considerations](proxy-security.md) — SECURITY: Egress policy, rate limits and the trust model of the billing layer.
- [Parameter Reference](proxy-reference.md) — REFERENCE: All protocol parameters in one table.

The same smartphone fleet that secures Phase powers a second network function: a mobile proxy layer for AI agents.

## The problem agents face

AI agents are the fastest-growing consumers of web traffic — and the most blocked. Traffic originating from datacenter IP ranges is routinely challenged, rate-limited, or refused outright. Agents need sessions that look like the users they act for: real traffic from real mobile networks. Mobile-origin sessions at scale are exactly what existing proxy providers sell — opaquely sourced, at \$2–9 per GB.

## How the Phase proxy layer works

Every Phase validator node can opt in as a proxy exit node — one flag and the address of a billing service, no extra hardware; the mobile build's defaults do not switch it on. An agent (or its infrastructure) runs a lightweight client that exposes a local SOCKS5 endpoint; traffic travels over the same iroh transport that carries consensus — with the same NAT traversal and relay fallback — to a validator phone, and exits to the internet from that phone's genuine mobile IP. The exit relays encrypted bytes; it never terminates TLS and never sees the content of the traffic.


## On-chain, prepaid, dispute-proof billing

Proxy usage is settled on-chain. An agent pre-funds a balance in a dollar-denominated stable asset; usage is metered per session and settled in idempotent batches — double-charging is impossible by construction, and the unspent balance is always withdrawable. Off chain, the billing service attributes every session to the specific exit node that carried it, and the validators whose phones carry the traffic earn their share of that revenue — proportional to the revenue their exits earned, settled daily, and paid in PHASE acquired on the open market ([Proxy revenue becomes PHASE demand](proxy-buyback.md)) — on top of their block rewards. The underlying demand comes from agents paying for real infrastructure, a source of network revenue that does not depend on a speculative cycle.

## Safe for the validator

The exit enforces strict egress protection: connections to loopback, private ranges, link-local, and cloud-metadata addresses are refused — including IPv6-mapped disguises — so the phone can never be used to reach its own node or internal networks. Limits on proxy work: [Security Considerations](proxy-security.md).

## Roadmap: agent nodes

Alongside validator nodes, Phase is developing a lightweight *agent node* — a minimal client that submits transactions and consumes network services without storing chain state or participating in consensus. It is the entry point for developers who want to plug agents into the mobile proxy layer and settle usage on-chain without operating a full node — turning Phase into agent-facing infrastructure: the chain as the settlement layer for agent commitments, and the mobile fleet as the utility those agents consume.

## The Proxy Layer

Each Phase validator holds an asset that cannot be provisioned in a datacenter: a genuine mobile-carrier IP address, the class of traffic origin least likely to be blocked or challenged on the public internet. Simultaneously, AI agents—among the fastest-growing consumers of web traffic—are systematically refused when originating from datacenter ranges. The Phase proxy layer connects the two: a validator phone can opt in as a *metered egress node*, and agents route traffic through it, exiting to the internet from the phone's mobile IP. Usage is metered per session and settled on-chain against a prepaid balance. The wire-level specification is published separately as the *Phase Proxy Protocol* technical specification; this section summarizes the design commitments relevant to the protocol as a whole.

**Same transport, second service.** The proxy is not a parallel product with separate infrastructure; it is a second service of the same node over the same iroh transport ([Networking](networking.md)), on a second endpoint under its own identity and ALPN. A client runs a local SOCKS5 listener; tunneled traffic traverses QUIC—with the same NAT traversal and relay fallback as consensus traffic—to the exit and leaves from the exit's own connection. Enabling the service is a node configuration flag.

**Three design commitments.** First, *billing is mandatory*: an exit refuses to serve without a configured billing service, and no connection is relayed unmetered. Second, *discovery is registry-only*: clients obtain exits from a registry of live, heartbeating participants (currently a 15 s heartbeat with 45 s expiry) rather than dialing arbitrary endpoints, so every reachable exit is a metered one. Every listed exit registered or sent a heartbeat within the last 45 s. Third, *the exit never terminates TLS*: application-level encryption runs end-to-end between the agent's software and the target; the exit observes target addresses and byte counts—which it must, to meter and to enforce egress policy—but relays opaque bytes and cannot read or modify payload content.

**Prepaid, watermark-idempotent settlement.** Accounts pre-fund an on-chain balance in the protocol's billing token: a six-decimal, dollar-denominated ERC-20 fixed at a genesis address, hard-coded by both the settlement contract and the billing service, and the unit in which every price, deposit, charge and withdrawal is quoted. On mainnet the token is `Bridged PHASE USDT` (symbol `USDT.e`) and is backed 1:1 by USDT: units minted by the inbound bridge are backed by the USDT the bridge received at its deposit address on the source chains, and the 10,000 USDT.e genesis supply, allocated to the treasury, is backed by a USDT reserve held by Phase Labs. The bridge contract is the token's only minter and mints only against a confirmed source-chain deposit, within a per-deposit cap of 1,000 USDT and a 24-hour cap of 10,000 USDT; the upgrade multisig (`0x…93`, [Execution Layer](execution-layer.md)) administers the token and can reassign the minter. The bridge is one-way for now: USDT moves to Phase, but USDT.e cannot yet be withdrawn back to a source chain. Exits report cumulative per-session usage; billing folds reports into charges; and a settlement process periodically submits, per account, the *cumulative* charge total to the on-chain settlement contract. The contract debits only the difference between the submitted target and a monotone per-account watermark. Resubmitting a batch, or two billing services settling overlapping charges, debits zero the second time: double-charging is structurally impossible rather than operationally avoided. The unspent remainder of a balance is withdrawable on two paths: the settler approves pending withdrawals in the normal course, and failing that the account holder may claim the remainder directly once a fixed dispute window has elapsed since the request. The second path is what makes the first non-custodial — settlement may charge the account right up until the claim, and the payout is clamped to whatever deposit survives, so the escape releases only what settlement has already left behind. Until a network's billing contract is upgraded to include it, releasing a remainder depends on the settler acting.

**Egress protection.** The exit enforces a normative egress policy on every connection: refusals cover loopback, RFC-1918 private ranges, link-local and cloud-metadata addresses, carrier-grade NAT space, multicast, and their IPv6 counterparts—including IPv4 addresses embedded in IPv6 forms (mapped, NAT64, 6to4), which are unwrapped and re-checked against the IPv4 rules. Name resolution happens exactly once, and the connection is made to the already-verified address, eliminating DNS-rebinding time-of-check/time-of-use attacks. The validator's phone can therefore not be used to reach its own node, its local network, or its cloud environment.

**Attribution and economics.** The exit runs on a second iroh endpoint with its own identity, derived from the same master key as the validator's but distinct from it and not bound on chain; every session is attributed on the billing ledger to that exit identity, so each metered byte is attributable to a specific device, though not through the validator registry of [Execution Layer](execution-layer.md). Proxy fees are designed to flow to the validators whose devices carry the traffic alongside block rewards ([Reward Mechanism](reward-mechanism.md)). Usage is priced, charged and collected in the billing token, so the *volume* of proxy revenue is set by demand for mobile egress rather than by token-market conditions. What reaches a validator is not insulated in the same way: the implemented payout accounting does not forward the billing token—it uses each exit's share of collected revenue as the weight for dividing a separately purchased pot of PHASE, transferred outside the protocol—and the liability that accounting tracks is denominated in PHASE. At launch the Foundation's stated operating policy is to commit the whole of collected proxy revenue to open-market PHASE purchases and to distribute the purchased PHASE daily in proportion to each exit's revenue share—the weighting the implemented accounting already computes. No contract enforces that policy; moving its execution on-chain is a roadmap item, and the payout denomination is therefore a policy commitment rather than a settled property of the protocol.

**Coordination trust.** See [Security Considerations](proxy-security.md).