SPACE OS — A Personal AI Network

White paper · v0 DRAFT May 2026

Status: v0 working draft. Architecture, protocol, and product sections are based on shipped code in the SPACE OS monorepo (May 2026). Sections marked TBA need founder input before publication. Sections marked PROPOSED are positions or numbers we believe are right; they need validation by the team. Comparative analysis (§20) and threat models (§18) are deliberately scoped for v1.

Abstract

SPACE OS is a vertically integrated network for personal AI. It combines an open node protocol, a decentralised GPU inference mesh, a personal agent runtime that lives on the user's devices, and a dual-layer blockchain (Antelope-based native chain plus an embedded EVM at chain ID 800000) that handles staking, governance, payments, and on-chain DeFi. Inference is routed through SpaceRouter, an OpenAI-compatible gateway that selects from a network of staked GPU providers; the agent ("Aether") runs the reasoning loop, memory, and tool dispatch on the user's hardware. The same architecture deploys air-gapped for sovereign customers with no protocol changes.

This paper specifies the protocol, describes the system architecture, defines the SPACE token and its economics, and lays out the implementation phases. It is intended for prospective node operators, application developers, institutional partners, and investors.

1. Introduction

1.1 The platform shift

Cloud chatbots are an early form factor for AI. The destination — the agent that knows you, runs across your devices, and acts on your behalf — has different architectural requirements: persistent memory under the user's control, multi-device presence, low-latency local execution, and access to specialised tools and sensors. Centralised hyperscaler-served chat is a bad fit for all four.

Three forces compound:

1. Open models are catching up. Llama 3.1, DeepSeek V3, Qwen 2.5, Mixtral 8x22B and others now operate within useful distance of frontier closed models. The reason to pay for closed-API tokens is shrinking.
2. GPU supply is fragmented. The largest pool of underused GPU capacity is in homes, small offices, and labs — not data centres. A protocol that monetises this capacity addresses the supply imbalance directly.
3. Sovereignty is non-optional. Governments, militaries, family offices, and regulated industries cannot run AI on third-party clouds. They need an open protocol they can audit and operate themselves.

SPACE OS is the platform for those three forces.

1.2 Design goals

1. Local-first agent. Memory, reasoning, and tool dispatch run on the user's hardware. Only inference (GPU-bound matrix multiplies) is routed.
2. Open protocol. Every message format, capability, and economic action is specified in NODE_PROTOCOL.md and audit-able. No vendor lock-in.
3. Same protocol, every deployment. Consumer install, enterprise on-prem, and air-gapped sovereign deployments use the same code paths.
4. Cryptoeconomic alignment. Providers stake to serve; users pay per use; the protocol takes a fee; bad actors are slashed.
5. No bridge trust assumptions inside our network. The EVM runs deterministically inside Antelope consensus rather than as a separate chain.

2. System architecture

2.1 Five layers

┌─────────────────────────────────────────────────────────────────────┐
│  APPS                                                               │
│  Aether (desktop / mobile / web) · Web portal · Marketing           │
├─────────────────────────────────────────────────────────────────────┤
│  BACKEND SERVICES                                                   │
│  app-api · fiat-service · KIS (key custody)                         │
├─────────────────────────────────────────────────────────────────────┤
│  NETWORK & COORDINATION                                             │
│  Aether coordinator · SpaceRouter · WireGuard relay · hostd         │
├─────────────────────────────────────────────────────────────────────┤
│  BLOCKCHAIN                                                         │
│  Antelope/Spring native chain · embedded EVM (800000) · explorers   │
├─────────────────────────────────────────────────────────────────────┤
│  SMART CONTRACTS                                                    │
│  System contracts (token, staking, DAO, GPU, bridge, EVM runtime)   │
│  Solidity (vault, insurance, RWA, identity, faucet, bridge tokens)  │
└─────────────────────────────────────────────────────────────────────┘

2.2 Topology in one paragraph

A user device pairs with the network by signing a wallet challenge. Once paired, the device's local Aether agent runtime composes prompts from the user's signed-op memory log, calls SpaceRouter for inference, which discovers eligible GPU providers from the chain (filtered by VRAM, dropped if heartbeat is stale) and routes the request through a WireGuard tunnel subnet (10.100.0.0/24) to the chosen provider's :8080. Tokens stream back; settlement charges the user's proxy wallet on the EVM side; rewards split per the formula in §9.

2.3 Repository layout

The implementation lives across 22 active repositories. The most load-bearing are listed below; full inventory in the source tree.

3. The Node Protocol

NODE_PROTOCOL.md (in space-os-aether-app/docs/) is the source-of-truth specification. This section summarises it.

3.1 Roles

A network participant declares one or more roles:

3.2 Capability manifest

Every node, on join, declares its capabilities:

{
  "node_id": "phone-abc123",
  "wallet_addr": "0x...",
  "platform": "android|ios|desktop|web|headless",
  "roles": ["client", "storage"],
  "tier": "runtime|special|shizuku|device_owner|root",
  "capabilities": { "infer.small": {...}, "user.fetch": {...} },
  "limits": { "max_concurrent_tools": 3, "max_blob_size_mb": 10 }
}

The coordinator advertises a capability only if at least one reachable node supports it.

3.3 Tier ladder

Capabilities are gated by an OS-level tier. Most users live at runtime. Sideloaded Android, desktop, and dedicated hardware can reach higher tiers.

3.4 Capability scopes

Tools declare a scope so the coordinator can route to a node best-suited to execute them. This is how cross-device tool calls work (search from your laptop using your phone's residential IP).

3.5 State levels

Turn routing prefers foreground then foreground_service, falling back to wake-up paths.

3.6 Wire protocol

The transport is WebSocket (Aether) and OpenAI-compatible HTTP (SpaceRouter). Message types include node_join, heartbeat, user_turn / dispatch_turn / token / turn_complete, presence_claim / presence_subscribe / presence_state, tool_request / tool_result, job_start / job_progress / job_needs_input / job_complete, memory_delta / memory_sync / memory_catchup, wake, and ping / pong. Full grammar in NODE_PROTOCOL.md.

3.7 Peer-RPC

Devices can call each other without going through the LLM. Control plane: health, describe_self, describe_tools, describe_topics. Data plane: agent_query, topic_get, topic_subscribe, tool_invoke. tool_invoke is gated by an explicit per-tool, per-peer allowlist.

4. Aether — the agent

Aether is the runtime that turns a paired set of devices into a single agent. The user has one agent, one identity, one memory — instantiated wherever they need it.

4.1 ReAct loop

The runtime is a TypeScript ReAct loop shared across desktop, mobile, and web. On each user turn it: composes a prompt slice from memory, awareness, and personality; dispatches to a model via SpaceRouter; streams tokens; invokes any tools the model requests; loops until the turn completes; commits the result to the signed-op memory log.

4.2 Memory

Memory is an append-only log of signed operations — conversations, facts, attachments, preferences, entities, tasks, jobs. Each op is signed by the device that produced it. Scopes give the user control:

• synced — replicated to the user's other devices.
• local — node-only, never leaves the machine.
• session — ephemeral, not persisted.
• subagent:{job_id} — visible only to a sub-agent.
• private — encrypted client-side before reaching the coordinator.

The private scope cipher and key management are TBA — current implementation uses symmetric encryption with a device-held key; spec needs to call out the algorithm and the key-rotation story.

Per-turn slice = pinned facts + embedding retrieval + entity expansion + recent turns. Stores: better-sqlite3 on desktop, expo-sqlite on mobile, IndexedDB on web.

4.3 Awareness

A second graph runs alongside memory: Awareness. Where memory is a chronological op log, awareness is a structured entity graph — people, projects, places, topics, things — built in the background by a follow-along watcher that tags mentions in conversations and proposes new entities. Each entity has INDEX.md (frontmatter + summary), notes.md (timestamped observations), and attached media.

Awareness is local-first; per-entity opt-in to sync. Tools: awareness.relevant(), awareness.get(id), awareness.search(), awareness.create(), awareness.attach(). Settings expose a storage panel with auto-clean policies.

4.4 Personality

A structured persona controls how the model responds. Per-trait sliders (0–100) plus a 1000-char "Soul" free-text identity field plus voice character plus six preset templates. The system prompt is composed at turn time, not pinned statically. Personality syncs across the user's devices as a pref.set op.

Trait set: warmth, verbosity, humor, assertiveness, creativity, formality, proactivity, emotional IQ.

4.5 Tools

50+ tools across families: fetch & browse, messaging, sensors, personal info, filesystem, storage plane, compute, cross-app automation, networking, identity, memory convenience. Tools route via capability scope to the node best able to run them.

4.6 Service mode

The desktop runs the agent as a background daemon (systemd-user / Windows SCM / launchd). Closing the UI does not stop the agent. The Task Bus tracks recurring work with an annual cost projection and auto-pauses on overrun. The Event Bus (~50k-event ring) records "things that happened that the user might care about." agent.askOneShot exposes one-shot RPC for headless workloads (news brief, polling, automated research).

4.7 Voice

Voice is opt-in and routed by user preference. Three voice sources:

• Device — on-device Whisper STT and on-device TTS (XTTS-v2 fallback). Voice never leaves the machine.
• Hub — cloud STT + TTS (PROPOSED defaults: Deepgram Nova-2 + ElevenLabs streaming) for low-latency consumer use.
• Off — voice suppressed.

For sovereign deployments, only the Device path is permitted. The hub path is documented but never the default for private / government / military customers.

5. Inference network

5.1 SpaceRouter

spacerouter.ai is an OpenAI-compatible inference gateway built on LiteLLM. Endpoints: /v1/chat/completions, /v1/completions, /v1/embeddings. Authentication: API key. Same SDKs as OpenAI — only the base URL changes.

from openai import OpenAI
client = OpenAI(
    base_url="https://spacerouter.ai/v1",
    api_key=os.environ["SPACEROUTER_API_KEY"],
)

5.2 Provider discovery

SpaceRouter polls the chain every 60 seconds (SPACEOS_REFRESH_INTERVAL) for active providers in the gpuresource table on eosio. Providers whose heartbeat is stale (SPACEOS_HEARTBEAT_TIMEOUT = 600s) are dropped. The router maintains per-provider VRAM and model-support metadata; on each request it filters to providers that can serve the requested model and picks one by routing strategy (default: cheapest, with fallback chain).

5.3 Routing strategies

Strategies are exposed to advanced users in the Settings → Developer panel.

5.4 Provider tiers

Free tier serves immediately and earns from inference fees. Basic tier earns a 1.25× multiplier and APY on the staked SPACE. Pro tier earns 1.5× and is preferred for premium users. Enterprise tier earns the maximum 2.0×, votes in the DAO, and gets early access to new model deployments. Each registered GPU also posts a small per-device bond to SpaceProviderBond (slashable for bad uptime, returned on deregistration); the bond is independent of the wallet stake and only the bond is at risk for device-level issues.

5.5 Provider economics — illustrative

PROPOSED earnings, indicative monthly at the Free tier assuming 80%+ uptime:

These figures need empirical validation against testnet traffic and demand mix. TBA: posted benchmark from a sample-month report once mainnet traffic stabilises.

5.6 Models

Currently routed through SpaceRouter (testnet, May 2026):

• Llama 3.1 8B / 70B / 405B
• Mistral 7B, Mixtral 8x7B, Mixtral 8x22B
• DeepSeek V3, DeepSeek-Coder V2 16B
• Qwen 2.5 72B
• Gemma 2 27B
• Phi-3 Mini 3.8B
• CodeLlama 34B
• LLaVA 1.6 34B (vision)
• BGE Large (embeddings)

Models are added by request and on demand. The router exposes GET /api/router/models for a live list.

6. Native chain

6.1 Spring fork

The native chain is a fork of Spring v1.2.2 — the modernised Antelope consensus engine maintained by the EOS Network Foundation. SPACE OS uses standard Antelope tooling (nodeos, cleos, keosd) with 22/22 protocol features activated, including BLS, WebAuthn, and runtime-configurable blockchain parameters.

• SPACE token: 4-decimal native, max supply 1,000,000,000.0000, initial issue 100M to eosio.
• Block time: ~0.5 s.
• Genesis: single-producer testnet bootstrap. Mainnet producer set: TBA.

6.2 GPU heartbeat

Providers run spaceos-node (Docker'd nodeos plus a heartbeat loop). Every five minutes the loop calls gpuheartbeat on the system contract, registering the provider's GPU specs (model, VRAM, CUDA cores, TFLOPS) and asserting liveness. Stake-tier reward distribution and inflation minting (gpudistrib, gpuminflate) happen on-chain in the same contract.

6.3 System contracts

system-contracts/ deploys 18+ contracts to the native chain. The most load-bearing for a reader of this paper:

7. Embedded EVM

7.1 Design

SPACE OS runs an EVM inside an Antelope WASM contract rather than as a separate chain. The interpreter is a fork of Silkworm compiled to WASM and deployed as eosio.evm. Every EVM transaction is wrapped in an Antelope action (pushtx) by the tx-wrapper service, atomically settled, and replayed by space-os-evm-node (a second Silkworm build that consumes Antelope state via the SHiP protocol and exposes Ethereum JSON-RPC on :8545).

The benefit: full EVM semantics with Antelope's consensus and finality, no light-client bridge between two chains, no separate validator set.

7.2 Network details

Transactions are legacy (type 0) only — EIP-1559 is not supported (PUSH0 disabled, Shanghai EVM). Solidity ≤ 0.8.19.

7.3 EVM-side contracts (selected)

8. Bridges

8.1 Native ↔ EVM

SPACE token native → EVM:

1. Transfer SPACE to eosio.evm with memo 0xEVMAddress.
2. SPACE credited as native gas token on EVM (×10^14 decimal conversion: 4 → 18).

Stablecoin native → EVM:

1. User transfers USD to spaceos.brdg with memo 0xEVMAddress.
2. spaceos.brdg locks tokens, calls eosio.evm::call.
3. BridgeTokenFactory.mint(token, to, amount) on EVM.
4. User receives USD.s ERC-20.

EVM → native:

1. User calls BridgeTokenFactory.bridgeToNative(token, amount, nativeAccount).
2. Factory burns the .s tokens, sends bridgeMsgV0 to a reserved address.
3. eosio.evm::onbridgemsg delivers to spaceos.brdg.
4. spaceos.brdg releases native tokens.

Decimal conversion at the boundary: 4 ↔ 18 for SPACE / USD, 4 ↔ 6 for legacy USDT/USDC bridged tokens.

8.2 Fiat ↔ stablecoin (USD.s, EUR.s, GBP.s)

space-os-fiat-service is the operations service. Every fiat stablecoin in circulation is backed 1:1 by real fiat in a bank account.

Reconciliation cron runs every 6 hours: compares on-chain totalSupply() against bank balances. Surplus (bank − supply) must be ≥ 0. Auto-pauses minting if deficit exceeds 1%. Mint and burn operations are written to an immutable MintBurnLog collection. Withdrawals require admin review for amounts above a configurable threshold.

Treasury security limits: $500 max single transaction, $5,000 daily outflow, idempotency guard on every transfer.

8.3 External chain bridges

The current design supports EVM → SPACE OS (lock-and-mint of USDT and USDC into USDT.s and USDC.s). A native BTC bridge and broader external-EVM bridge support are roadmapped per documents/planning-specifications/bridges.md. TBA: timeline and security model for the BTC bridge.

9. SPACE token economics

Status: §9 needs the most expansion before publication. The numbers below are from documents/planning-specifications/tokenomics.md — they form a coherent v0 model but lack an emission curve, multi-year unlock schedule, and explicit on-chain enforcement diagrams. Expansion items marked TBA.

9.1 Utility

SPACE is the utility token of the network. Holders use it for:

1. Inference payment. Per-token charges (or subscription credits) settle in USD.s on the EVM, with SPACE as an alternative.
2. Provider staking. Basic / Pro / Enterprise tiers require a minimum wallet-level SPACE stake (1,000 / 10,000 / 100,000) for the earnings multiplier; in addition each registered GPU posts a small per-device bond to SpaceProviderBond for slashing collateral.
3. Governance. Voting weight in DAO proposals (quadratic — see §15).
4. Resource access. Native chain CPU / NET allocation under standard Antelope mechanics.

9.2 Supply

• Total supply: 1,000,000,000 SPACE.
• Inflation: 2% per year, minted to the rewards pool.
• Deflation: 20% of all protocol fees burned.
• TBA: annual emission curve through year 10; reserve schedule for the rewards pool; on-chain enforcement of caps.

9.3 Distribution

TBA: detailed unlock cadence (monthly tranches, cliff dates, who controls the multisig that releases each); a published vesting smart contract address; the token generation event date.

9.4 Staking yield

yield = base_apr + (inferences * 0.001 / stake)

PROPOSED parameters: base_apr = 5%, usage component awards 0.001 SPACE per inference served, normalised per unit of stake. The result is a yield floor of 5% with upside for high-utilisation providers. Tier multipliers (Staked 1.5×, Pro 2.0×) compose on top.

9.5 Reward split

Per inference fee, before burns:

20% of the treasury share is burned; the remainder accrues to the DAO-controlled treasury wallet for grants, audits, and operations.

9.6 Slashing

TBA: the witness mechanism (who attests to downtime — heartbeat oracles per oracle-spec.md); the dispute path beyond the 24h DAO vote; the on-chain action that executes the slash.

9.7 Protocol fee

1% on compute. PROPOSED interpretation: the 1% is additive to the per-token model price posted on /pricing. Subscription tiers pre-pay the protocol fee inside the bundle. Worth confirming with the team before publication.

10. DeFi primitives on the EVM

10.1 SpaceVault — self-collateralised lending

The vault is a no-liquidation lending primitive. Users deposit a stablecoin and borrow against it in the same asset.

The mechanism is straightforward: because the deposit and the debt are denominated in the same stable asset, no oracle is needed and no price-shock liquidation can occur. The vault charges a 0.5% origination fee on borrows. The product is intended for users who want utility from idle stablecoin deposits without taking liquidation risk.

PROPOSED: the same-asset constraint is the differentiator and should be the headline of any vault marketing. Cross-asset vault designs are explicitly out of scope to keep the no-liquidation property.

10.2 SpaceInsurance — vault protection

Optional insurance product for vault depositors and other beneficiary-style use cases.

The dead-man-switch design is intended for estate planning and family-office use cases (private segment).

10.3 RWA — real-world assets

SpaceRWAFactory deploys compliant tokenised real-world assets. Jurisdiction: BVI / Cayman.

KYC verification is performed by SpaceIdentityRegistry. A token's transfer hook checks the registry on every move; non-verified addresses are rejected.

11. Identity & key custody

11.1 Authentication

Authentication is wallet signature only — no passwords. Standard EIP-191 nonce challenge:

1. GET /api/auth/nonce?address=0x... → message.
2. User signs the message with their wallet.
3. POST /api/auth/verify → JWT (7-day expiry).

First device pairs by wallet signature. Subsequent devices pair with a 6-digit code generated by an existing paired device. Recovery is wallet re-import.

Each authenticated user receives three wallets:

• Connected wallet — external EOA (MetaMask, Coinbase, Phantom, Exodus, Trust, Rainbow).
• Proxy wallet — server-managed EVM wallet on SPACE OS chain. Used for protocol payments and held tokens.
• Native account — Antelope account for staking, voting, and governance.

11.2 KIS — Key Issuing Service

Proxy and native private keys are held by a separate-trust-domain custody service in Rust (space-os-kis). KIS uses ChaCha20-Poly1305 AEAD for envelope encryption with a master key wrapped via scrypt. App-api never decrypts; signing happens inside KIS in a closure that holds the key for milliseconds, then returns raw_signed_tx.

The signing flow in production:

[User JWT] → app-api → [HMAC + mTLS] → KIS → [signs in sealed closure] → raw_signed_tx

KIS exposes /sign-evm, /rotate (sweep + key swap for both native and ERC-20), and /admin/import (gated, for migrations). Audit log is structured JSON to stdout, kept in a different namespace from app-api. Postgres-backed encrypted keystore with a 5 GiB PVC; HSM backend planned in a future phase.

KIS is shipped on testnet. Production hardening — Vault-Agent secret provisioning, mTLS termination, multisig lockdown, hardened export ceremony, HSM swap-in — is roadmapped against the standard custody pre-launch checklist. TBA: production launch audit report and security disclosure path.

11.3 KYC and identity registry

SpaceIdentityRegistry is the on-chain KYC registry. It records four levels: Retail, Accredited, Institutional, Exempt. RWA contracts and other compliance-gated products check the registry on transfer. KYC providers are integrated off-chain by app-api; verified status is written on-chain by the verifier role. TBA: the list of active KYC providers and the evidence-storage policy.

12. Governance

spaceos.dao is the on-chain governance contract. The framework is set out in dao-constitution.md.

12.1 Voting power

• Token holders vote with quadratic voting (1 SPACE = 1 vote, square-rooted at tally time).
• Three councils elected quarterly: Provider, Developer, User.
• Treasury control: 3-of-5 council multisig + 10% token-holder quorum.

12.2 Proposal types

12.3 Phases

• v1 (today): parameter changes only — fee rates, slashing thresholds, tier minimums.
• v2: full treasury control + upgrades.

Anti-capture mechanisms: timelocks on every executable; delegation caps preventing concentration; emergency-pause requires only 1% quorum to stop the network in a security incident, but cannot be used to change anything — only to halt.

TBA: the precise list of parameters mutable in v1, the on-chain action propose / vote / execute ABI, and the contract address once finalised.

13. Privacy

13.1 Today

• Memory ops are signed by the producing device.
• The private memory scope is encrypted client-side before reaching the coordinator. Cipher: TBA — must specify algorithm (AES-GCM 256 proposed), key derivation, and key-rotation policy before publication.
• App-api and KIS run in separate trust domains.
• Sovereign deployments operate the coordinator on-prem; no traffic leaves the customer's perimeter.

13.2 Roadmap — ZK + FHE (phase 3)

zk-fhe-privacy.md sketches the Phase 3 design:

Encrypted input → FHE enclave compute → ZK proof → Verified output

The user encrypts inputs with FHE; the GPU provider computes inside an enclave on the encrypted input; a ZK proof attests to correct execution without revealing inputs or outputs.

TBA: concrete FHE scheme (CKKS / TFHE / BFV?), proof system (Groth16 / Halo2 / Plonk?), enclave hardware (TEE: SGX / TDX / Nitro?), end-to-end latency budget, cost model (FHE inference is currently 100–1000× slower than plaintext — needs explicit guidance on which workloads it applies to).

13.3 AI safety

Pre- and post-inference filters for toxicity and jailbreak attempts. DAO-managed blacklists. Oracle-monitored model behaviour. TBA: filter implementation, false-positive rate target, appeal path.

14. Oracles

spaceos.oracle is a Chainlink-style decentralised oracle network for hardware proofs, uptime SLA, IPFS pin status, and pricing. Oracle nodes stake SPACE; bad data is slashed at 50%. Aggregation: median + threshold sigs + ZK proofs. Honest threshold: 51%. Dispute window: 24 h via DAO vote.

Oracle reward: 5% APY + share of inference fees. TBA: the on-chain oracle contract address, the proof-submission ABI, and the bootstrap set of oracle operators.

15. Storage

Content-addressed storage with replication. Tools: storage.put / .get / .has / .pin / .unpin. TBA: chosen back-end (IPFS-leaning per the planning docs but not finalised), replication factor, pinning incentive structure, and storage-provider role economics. The protocol surface is defined; the operational layer is not.

16. Hardware

16.1 SPACE OS-ready devices

The Store sells three reference hardware tiers:

Plus companion hardware (Aether Orb voice surface, Companion Display) and merch using the AetherMark icon set. The Store is currently in pre-launch with email capture; checkout opens with mainnet.

16.2 Sovereign hardware

For private / government / military deployments, hardware is bespoke and air-gapped: a Workstation-class node with the on-prem coordinator, no cloud dependency, only the Device voice path enabled. TBA: named hardware partners and reference-architecture documents.

17. Deployment models

The same architecture deploys across four customer profiles with no protocol changes — only configuration.

The capability scopes (§3.4) make jurisdictional routing a first-class concern, not an afterthought.

18. Threat model

TBA: §18 is deliberately scoped for v1. Each customer profile in §17 has a different threat model and needs a separate sub-section. Below is the structural skeleton.

For each profile we should specify:

1. Adversary model. Who is attacking, what are their capabilities.
2. Trust boundaries. What components must be trusted, what can be compromised without breaking the property.
3. Properties preserved. Confidentiality, integrity, availability, billing-correctness, governance-soundness.
4. Mitigations and residual risk.

PROPOSED first-pass: consumer profile assumes a curious provider and a curious coordinator; private profile assumes a compromised coordinator (mitigated by on-prem); sovereign profile assumes a nation-state adversary with network and supply-chain capabilities (mitigated by air-gap, hardware attestation, and protocol audit).

19. Implementation status

Per implementation-plan.md, a 36-week phased plan with security gates (audit ≥ 80/100 per phase, ≥ 95/100 final). Indicative budget $240K through mainnet.

Mainnet KPI targets: TVL $10M+, 1M inferences/day, 10k providers, churn <5%, p95 latency <100 ms.

TBA: dated mainnet target, audit firm and report dates, and the post-mainnet roadmap.

20. Comparative analysis

TBA: §20 is reserved for v1. A real comparative section needs careful claims and is the section most likely to attract scrutiny — not worth shipping in a hurry.

The intended structure:

Each row needs a paragraph of commentary citing public sources. PROPOSED: the differentiator we lead with is the personal agent + on-prem deployment + open protocol combination — none of the comparators cover all three. Validate this claim against current state of Bittensor TAO subnets and Akash before publication.

21. Conclusion

SPACE OS is operating on a thesis: that personal AI is the next platform shift, that decentralised inference is the right supply structure, and that an open protocol with sovereign-deployable architecture is the right shape for the next decade of regulated and security-sensitive AI use. The thesis is implemented across 22 active repositories with shipped testnet and a phased plan to mainnet.

For consumers: Aether is your AI agent on your devices. For developers: SpaceRouter is OpenAI-compatible inference at lower cost. For providers: earn SPACE with your idle GPU. For private, government, and military operators: the architecture deploys air-gapped without protocol changes.

The remaining work is well-scoped: tokenomics depth, ZK/FHE specifics, comparative analysis, threat models per segment, and the production-mainnet audit gate. None of those is a research problem; all are documentation and operations work against a mature codebase.

Appendix A — Glossary

• Aether — the personal AI agent runtime that lives on user devices.
• Aether coordinator — the cloud (or on-prem) service space-os-aether that handles presence, memory sync, turn routing.
• Antelope / Spring — the consensus engine of the native chain (fork of Spring v1.2.2).
• Capability manifest — JSON declaration each node submits on join.
• Capability scope — annotation on a tool that lets the coordinator route execution to the right node.
• Embedded EVM — the Silkworm-based EVM running inside an Antelope WASM contract (eosio.evm).
• KIS — Key Issuing Service. Rust custody service, separate trust domain.
• Nodelet — a sandboxed local runtime (Python or Node) supervised by hostd.
• Peer-RPC — typed device-to-device messaging that bypasses the LLM.
• SpaceRouter — the OpenAI-compatible inference gateway.
• Service mode — the desktop agent running as a background daemon.
• Tier (operator) — Free (0) / Basic (1k SPACE) / Pro (10k SPACE) / Enterprise (100k SPACE) — provider routing priority and earnings multiplier (1.0× / 1.25× / 1.5× / 2.0×). Separate from the per-device bond posted to SpaceProviderBond.
• Tier (capability) — runtime / special / shizuku / device_owner / root — OS-level permission ceiling.
• USD.s, EUR.s, GBP.s — fiat-backed stablecoins on the EVM, 1:1 bank-backed.
• USDT.s, USDC.s — bridged stablecoins, locked-token-backed.

Appendix B — Endpoints (testnet)

Appendix C — Open questions for v1

1. Tokenomics: emission curve, multi-year unlock cadence, on-chain enforcement.
2. Privacy: explicit cipher for private memory scope; ZK/FHE phase 3 scheme + proof system + TEE.
3. Slashing: witness mechanism, dispute path beyond DAO vote.
4. Bridges: BTC bridge timeline and security model.
5. Storage: chosen backend, replication, pinning incentives.
6. Threat models per customer segment.
7. Comparative analysis vs Bittensor, Akash, io.net, OpenRouter.
8. Mainnet date, audit firm, post-launch roadmap.
9. Voice path policy for sovereign deployments (default Device-only — confirm).
10. KIS production audit and disclosure path.

Appendix D — References

• Source code: gitlab.64b.net/SPACE_OS/*
• Open Node Protocol: space-os-aether-app/docs/NODE_PROTOCOL.md
• Planning specifications: documents/planning-specifications/*.md
• EVM integration: documents/planning-specifications/evm-integration.md
• Tokenomics: documents/planning-specifications/tokenomics.md
• DAO Constitution: documents/planning-specifications/dao-constitution.md
• Implementation plan: documents/planning-specifications/implementation-plan.md
• Fiat stablecoin plan: documents/fiat-stablecoin-plan.md
• Earlier reviews: website/docs/aether-app-review.md, aether-desktop-review.md, spaceos-fullstack-review.md

End of v0 draft. v1 to follow after founder review of TBA / PROPOSED items.