Execution credibility
The blockchain and networking foundation exists in open source today. The service protocol and terminal product layers are intentionally separated and explicitly identified as the next delivery surface.
.tos registration with verified ARD gateway bindingsOpen-weight models in the 8-14B range now run directly on a Mac mini, a gaming PC, a home NAS, or a Jetson-class box, capable enough for tool calling, coding, and retrieval, not just chat. That turns a growing population of ordinary owner-operated devices into potential agent nodes, not just endpoints.
Escalates outward only when the nearer tier can't meet the request's capability, latency, privacy, or evidence bar.
Phones, wearables, IoT. Voice, control loops, sensor interpretation.
Mac mini, MacBook, gaming PC, NAS, Jetson-class boxes. Agents, coding, RAG, tool calling.
Enterprise and aggregation-tier servers. Knowledge bases, complex reasoning.
Data-center deployments. Frontier research, large-scale training.
A Mac mini fits the compute role above, with enough unified memory to run an 8-14B model at home. A Raspberry Pi fits a lighter, always-on role: holding and sharing storage rather than heavy inference.
Unified memory and low idle power make it one of the more approachable machines for running an open-weight model at home.
Low power draw and an attached disk make it a natural fit for always-on storage capacity rather than model inference.
Photos: Chiru-2, SimonWaldherr, Wikimedia Commons, CC BY-SA 4.0.
Home and site relays remain planned work, and a storage service profile is scoped for a later roadmap phase. Buying either device does not connect it to TOS today. It identifies the class of owner-operated hardware this architecture is designed to admit once that work ships.
TOS coordinates independently operated model services while sensitive workloads can remain on customer-controlled local, private, or on-premise nodes. The network settles evidence and value; it does not require central custody of proprietary datasets.
Sensitive tasks can be restricted to approved local, private, or edge nodes. Routing moves outward only when customer policy permits it.
Service descriptors expose capabilities and terms, not unrestricted access. Task policy limits payloads, tools, endpoints, budgets, and retention.
Private prompts, datasets, and outputs stay off-chain. Signed receipts, hashes, and evidence references provide accountability without publishing the underlying content.
Plural providers, registries, and owner-operated nodes reduce dependence on one company, region, or platform policy. If one route fails or refuses service, agents can discover policy-compatible alternatives.
Security still depends on node hardening, encryption, access control, trusted runtimes, and operator practice. Highly sensitive workloads should remain on explicitly approved customer-controlled nodes.
TOS does not train models and is not trying to be preferred over any foundation-model provider or inference stack. It is neutral to which model a node runs. Its job is the identity, discovery, quoting, evidence, and settlement that let that node be found, trusted, and paid at whichever tier the request lands on.
Coordination, settlement, and trust sit between independently owned supply and global demand.
A terminal beside a camera, robot, vehicle, or production line can execute where remote clouds face latency, bandwidth, privacy, connectivity, or safety constraints.
TOS treats these devices as site-bound service terminals, not miniature GPU clouds. Local real-time work and independent safety controls always outrank external network tasks.
Read the Physical AI architectureApproved local workloads continue offline with bounded authority and idempotent reconciliation after reconnect.
Safety interlocks, control deadlines, and local perception pre-empt external services and background jobs.
Signed artifacts, compatibility gates, staged rollout rings, health checks, and known-good rollback protect fleets.
No public shell, raw actuator, Docker socket, or unrestricted host access. Every queue and resource has a bound.
Owner-directed. Policy-bound. Built to hunt for productive work, not unrestricted access.
The autonomous earning layer
OpenFox is the proposed autonomous earning agent for TOS. It discovers candidate paid tasks, matches them to owner-approved skills, evaluates cost and risk, executes through bounded AI capacity, and follows the result through evidence and settlement.
The model may plan and recommend. Deterministic policy decides whether
OpenFox may accept, spend, sign, use a tool, or dispatch a task. The
owner key stays outside both OpenFox and tos-ai-worker.
Establishes the trusted market: identity, discovery, tasks, authorization, quotes, payments, receipts, and settlement.
Supplies bounded production capacity: approved models, local admission, runtime adapters, resource control, and safe cleanup.
Lets those capabilities seek compatible work, act within an owner mandate, and pursue revenue through accountable execution.
Watch bounded, provenance-preserving sources for paid tasks that match approved skills.
Recheck identity, escrow, terms, cost, margin, risk, deadlines, and delegated authority.
Reserve capacity and run only approved plans, models, tools, and network destinations.
Submit evidence, observe payout or dispute, and update bounded accounting and performance history.
OpenFox is a proposed product, not a deployed earnings service. Revenue is never guaranteed, discovered content is untrusted, and owner policy, spending limits, terminal admission, and chain state remain authoritative.