The Proxies.sx thesis / Updated 29 September 2026
INFRASTRUCTURE FOR AGENTS.
BUILT ON PEERS.
01 / THE IDEA
Make infrastructure programmable.
An agent should be able to inspect a service contract, check availability, obtain access within an approved budget and verify what it received. The supplier should be able to see the work performed and the money settled.
Proxies.sx brings proxy access, opt-in peer supply and managed compute into that workflow. APIs and readable documentation make the pieces discoverable. Reliable execution still needs authorization, measured capacity and explicit failure handling.
02 / CHOOSE AN ENTRY POINT
Use the contract for your task.
Account + API key For teams and applications.
Use the customer account to purchase bandwidth and configure access. Integrate through REST, MCP or a proxy credential in an existing tool.
USDC x402 For supported wallet flows.
Read the current product quote and payment requirements before authorizing a transaction. Persist the returned access and management credentials.
Supply For device operators.
Enroll consented devices under your supplier agreement. Registration, connection, verification and customer routing are different stages.
Compute For inference workloads.
Check current machine availability, supported models and request limits before making an explicit rental purchase.
03 / THE SYSTEM
A loop with checkable boundaries.
Supply → Qualification → Access → Usage → Settlement
| Stage | What must be established | Public contract |
|---|---|---|
| Supply | Device identity, consent and agreement. | Peer SDK |
| Qualification | A usable connection and current routing quality, beyond a registration count. | Supplier guide |
| Access | Authorized credentials, country/network constraints and session policy. | Pool Gateway |
| Usage | Product-specific metering and remaining allowance. | Gateway operations |
| Settlement | Agreed supplier rates, accrued earnings and completed payout records. | Supplier terms |
04 / USEFUL SUPPLY
Registered is the beginning.
A large device list is not a capacity guarantee. A device can be registered but disconnected, connected but unqualified, or qualified for a region that does not fit a customer's request. Inventory and routing checks need to preserve these distinctions.
For SDK providers, follow the Go installation guide or the relevant platform integration. Keep each device's identity and state persistent. Scale an installation only after its connection and useful traffic are verified.
05 / RELIABILITY
Measure the work, not just the heartbeat.
Monitoring, health probes and exclusion rules help the network recover. A successful heartbeat alone does not prove a proxy can complete a target connection. A completed tunnel is also different from a customer's application achieving its goal.
Country, carrier, pinned-device and rotation preferences constrain which replacements are acceptable. A retry must respect those preferences. An established connection cannot be silently replayed without changing the application's behavior.
The operating aim is reliable service with observable failures. This thesis is not a published uptime guarantee, benchmark or promise that every registered device is routable.
06 / PAYMENTS
Price the service before buying it.
Proxy accounts purchase metered bandwidth. The supported x402 path describes USDC payment requirements for a specific purchase. Compute uses the documented account-balance and rental flow. Read the relevant quote and contract instead of assuming one payment mechanism applies to every product.
# Read-only discovery. These requests do not buy a service.
curl -fsS https://api.proxies.sx/v1/x402/pool/pricing
curl -fsS https://api.proxies.sx/v1/gateway/pool/stock
curl -fsS https://agents.proxies.sx/compute/facts.jsonLive stock changes. A dated release fact is not a reservation. Keep payment authorization separate from a document or page that an agent happens to read.
07 / SUPPLIER RECORDS
Accrued, settled and paid are different.
A supplier's agreed terms govern its earnings. Usage evidence, adjustments and completed transfers need their own records. Dashboard totals should reconcile with those records; a payment receipt should identify what was settled.
A prospective incentive must not be represented as traffic that never occurred. A future token reward would need an explicit, voluntary choice without erasing existing earnings.
08 / THE PROPOSED $SX LAYER
Give the token a useful job.
$SX is the Proxies.sx meme token on Solana today. Its proposed utility connects to the same network: optional supplier rewards, defined service benefits, quoted conversions into workload balance and funded contributions.
Those ideas are in development. There is no announced $SX checkout, reward API, vault launch or staking yield. Current products retain their own billing and supplier terms.
The design principle Work before reward.
First establish the useful service and the amount earned. Then, if a funded token option is introduced, provide a quote, consent and a completed transfer record.
Read the token reference Identity. Status. Boundaries.
Check the full mint and distinguish proposals from available integrations. Holding $SX does not grant company equity, revenue or service credit.
Source: the main $SX page. No utility launch date or investment return is promised.
09 / AGENT OPERATIONS
Automate within an explicit scope.
Agents can read contracts, configure integrations and assist operations. Access scopes, spending limits, human approvals where required and verifiable action receipts determine what they may do. Documentation is an interface to the system, not permission to spend money or change production.
10 / THE FEEDBACK LOOP
Useful service earns another workload.
Reliable connections and clear billing support repeat use. Repeat use creates measurable supplier work. Reconciled supplier records make that work understandable. The proposed $SX layer should strengthen this loop only where its implementation can be verified.
11 / WHAT THIS PAGE ESTABLISHES
Architecture is not an acceptance test.
The linked guides describe supported products and the intended operating model. They do not certify a fixed stock count, universal performance, automatic recovery time or current availability for a particular workload. Verify those at the relevant boundary.
12 / VERIFY IT YOURSELF
Start from evidence.
- Live pool inventory — counts, timestamps and pool distinctions.
- Current x402 pool pricing — product quote and purchase requirements.
- Service status — current published component status.
- Dated compute release facts — check live availability separately.
- $SX facts for agents — identity and integration boundaries.