Prove the loop. Then scale the market.

No. TOS is designed around policy-bound service outcomes. The provider exposes an approved capability, not a raw accelerator, public shell, or arbitrary execution environment.

Physical AI creates services whose value comes from location, local data, privacy, and real-time execution. Those advantages cannot always be replicated by moving the workload to a remote centralized cloud.

ARD gives TOS services an open publication and search surface through standard catalogs and federated registries. TOS begins where discovery ends: it verifies the TOS binding, obtains a live quote and admission decision, executes under local policy, returns evidence, and settles value.

OpenFox is the proposed autonomous earning agent for TOS. It is designed to discover paid AI work, match owner-approved skills, evaluate cost and risk, execute through bounded capacity such as tos-ai, and observe settlement through tos-protocol. It is not yet deployed and does not receive the owner's unrestricted wallet key.

TOS Core exists in open source: actor execution, consensus, sharding, networking, wallets, query foundations, and service-oriented contracts. The interoperable public service market, edge terminal product layers, and OpenFox autonomous earning loop remain planned or proposed product work.

Compatible supply improves discovery and composition; demand improves utilization; signed receipts improve operational evidence; shared standards reduce the cost of adding the next model, device, site, or service profile.

The policy targets approximately five billion TOS of total supply: about 500 million is created for finalized blocks over roughly seven years and distributed through the Elector to active validators, and about 4.5 billion is reserved for a separately specified community-agent reward mechanism that is not funded at genesis and is never held by a treasury wallet. Genesis is provisionally limited to 101,000 TOS for validator bootstrap and system-contract reserves. Outages are not backfilled, and governance must taper and stop creation near the published targets.

No. Service transaction volume, validator fees, protocol revenue, and token value accrual are distinct. The project publishes architecture and delivery objectives, not investment-return promises.

TOS is designed so sensitive work can stay on approved customer-controlled nodes, task payloads are limited by explicit policy, and private prompts, datasets, and outputs are not published on-chain. The network coordinates identity, authorization, evidence, and settlement rather than taking central custody of customer data. Actual protection still depends on encryption, node security, access control, runtime trust, and operator practice.

TOS is designed around plural service providers, federated discovery, and owner-operated nodes rather than one company's infrastructure or approval policy. If a provider, registry, region, or route becomes unavailable or refuses a request, agents can search for another policy-compatible service. This reduces single-company failure and control risk; it does not guarantee uninterrupted availability, universal access, or exemption from applicable law.

Two different payments are involved. Commercial terms are quoted in supported stablecoins issued on the TOS network, and an accepted quote binds the exact asset contract and amount. Network fees are paid in native TOS. A sponsored-transfer design that would let an agent holding only stablecoins transact without first acquiring TOS is specified but on hold, so for network fees today the answer is yes.

They sit at different layers, not in competition. A request-time payment header like x402 is a lightweight way to attach payment to a single HTTP call. TOS adds what that pattern leaves out: bounded owner authority, spending limits, signed evidence, and dispute resolution behind the payment. Support for such protocols belongs in the transport layer at a gateway, which holds no protocol authority, rather than in TOS Core consensus.

TOS separates four levels by design: what an agent may access without asking (owner-approved capabilities and data), what requires a human decision (owner-key actions and policy changes), what is capped automatically (per-action and daily spending limits enforced by the Agent Account itself, not just client-side checks), and what is recorded regardless of outcome (signed evidence and receipts for every settled action). Standardizing these four levels is what makes a resource controllable, discoverable, callable, and monetizable at agent scale, not just making it available to a model.