Intelligence is infrastructure.
TOS makes it transactable.

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 gross creation over approximately seven years. Genesis is provisionally limited to 101,000 TOS for validator bootstrap and system-contract reserves; nearly all remaining TOS is created for finalized blocks and distributed through the Elector to active validators. Outages are not backfilled, and governance must taper and stop creation near the published target.

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.

Not necessarily. TOS Core's own settlement is native-TOS-denominated, but the atos.im managed-mode gateway is designed to also quote and settle in approved stablecoins, so an agent can pay without first acquiring TOS. Verified and Native trust modes still anchor final authorization and evidence to TOS-backed checkpoints.

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. Accepting protocols like x402 is planned as a gateway-level capability of atos.im's managed mode, not a change to 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.