# SPACE OS — Una red de IA personal

**Libro blanco · v0 BORRADOR**
*Mayo de 2026*

> **Estado:** borrador de trabajo v0. Las secciones de arquitectura, protocolo y producto se basan en el código publicado del monorepo de SPACE OS (mayo de 2026). Las secciones marcadas como **TBA** requieren la aportación del fundador antes de su publicación. Las secciones marcadas como **PROPOSED** son posiciones o cifras que creemos correctas; necesitan validación por parte del equipo. El análisis comparativo (§20) y los modelos de amenazas (§18) están deliberadamente delimitados para v1.

---

## Abstract

SPACE OS es una red verticalmente integrada para IA personal. Combina un protocolo abierto de nodos, una malla descentralizada de inferencia GPU, un runtime de agente personal que vive en los dispositivos del usuario y una blockchain de doble capa (cadena nativa basada en Antelope más una EVM embebida con chain ID 800000) que gestiona staking, gobernanza, pagos y DeFi on-chain. La inferencia se enruta a través de **SpaceRouter**, una pasarela compatible con OpenAI que selecciona entre una red de proveedores GPU con stake; el agente ("Aether") ejecuta el bucle de razonamiento, la memoria y el dispatch de herramientas en el hardware del usuario. La misma arquitectura se despliega air-gapped para clientes soberanos sin cambios en el protocolo.

Este documento especifica el protocolo, describe la arquitectura del sistema, define el token SPACE y su economía, y expone las fases de implementación. Está dirigido a posibles operadores de nodos, desarrolladores de aplicaciones, socios institucionales e inversores.

---

## 1. Introducción

### 1.1 El cambio de plataforma

Los chatbots en la nube son una forma temprana de la IA. El destino —el agente que te conoce, se ejecuta en todos tus dispositivos y actúa en tu nombre— tiene requisitos arquitectónicos distintos: memoria persistente bajo el control del usuario, presencia multidispositivo, ejecución local de baja latencia y acceso a herramientas y sensores especializados. El chat centralizado servido por hyperscalers encaja mal en los cuatro aspectos.

Tres fuerzas se combinan:

1. **Los modelos abiertos están alcanzando.** Llama 3.1, DeepSeek V3, Qwen 2.5, Mixtral 8x22B y otros operan ya a una distancia útil de los modelos cerrados de frontera. La razón para pagar tokens de API cerradas se está reduciendo.
2. **El suministro de GPU está fragmentado.** El mayor pool de capacidad GPU infrautilizada está en hogares, pequeñas oficinas y laboratorios —no en centros de datos. Un protocolo que monetiza esta capacidad aborda directamente el desequilibrio de oferta.
3. **La soberanía no es opcional.** Los gobiernos, los ejércitos, los family offices y las industrias reguladas no pueden ejecutar IA en nubes de terceros. Necesitan un protocolo abierto que puedan auditar y operar por sí mismos.

SPACE OS es la plataforma para esas tres fuerzas.

### 1.2 Objetivos de diseño

1. **Agente local-first.** La memoria, el razonamiento y el dispatch de herramientas se ejecutan en el hardware del usuario. Solo la inferencia (multiplicaciones de matrices ligadas a GPU) se enruta.
2. **Protocolo abierto.** Cada formato de mensaje, capacidad y acción económica está especificado en `NODE_PROTOCOL.md` y es auditable. Sin lock-in de proveedor.
3. **Mismo protocolo, todo despliegue.** La instalación de consumo, el on-prem empresarial y los despliegues soberanos air-gapped utilizan los mismos caminos de código.
4. **Alineación criptoeconómica.** Los proveedores hacen stake para servir; los usuarios pagan por uso; el protocolo cobra una comisión; los malos actores son slasheados.
5. **Sin asunciones de confianza de bridge dentro de nuestra red.** La EVM se ejecuta de forma determinista dentro del consenso de Antelope en lugar de como una cadena separada.

---

## 2. Arquitectura del sistema

### 2.1 Cinco capas

```
┌─────────────────────────────────────────────────────────────────────┐
│  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 Topología en un párrafo

Un dispositivo de usuario se empareja con la red firmando un desafío de wallet. Una vez emparejado, el runtime local del agente Aether en el dispositivo compone prompts a partir del registro de memoria del usuario formado por operaciones firmadas, llama a **SpaceRouter** para la inferencia, que descubre los proveedores GPU elegibles desde la cadena (filtrados por VRAM, descartados si el heartbeat está obsoleto) y enruta la petición a través de una subred de túnel WireGuard (`10.100.0.0/24`) hasta el `:8080` del proveedor elegido. Los tokens se transmiten de vuelta; la liquidación carga la wallet proxy del usuario en el lado EVM; las recompensas se reparten según la fórmula de §9.

### 2.3 Estructura de repositorios

La implementación vive en 22 repositorios activos. Los más estructurales se enumeran abajo; el inventario completo está en el árbol de fuentes.

| Componente | Repo | Stack |
|---|---|---|
| Cadena nativa | `spaceos-core` | C++20, Spring v1.2.2 |
| Nodo nativo + heartbeat GPU | `spaceos-node` | Bash + Docker + K8s |
| Contratos de sistema | `system-contracts` | C++ (Antelope CDT), WASM |
| Contrato runtime EVM | `evm-contract` | C++17 + Silkworm embebido |
| Nodo RPC EVM | `space-os-evm-node` | C++ (Silkworm), MDBX |
| Contratos Solidity | `space-os-evm-contracts` | Solidity 0.8.19, Foundry |
| Bridge EVM + tx-wrapper | `space-os-evm-bridge` | Node.js, ethers v6 |
| Coordinador | `space-os-aether` | Node.js, WS, ioredis, PG |
| Router de inferencia | `space-router` | Python, LiteLLM, FastAPI |
| Relay WireGuard | `space-os-relay` | Node.js, WG bindings |
| Daemon de dispositivo | `hostd` | Rust, Tokio |
| API central | `space-os-app-api` | Node.js, Mongo, Redis |
| Onramp fiat | `space-os-fiat-service` | Node.js, Mongo, Stripe + Wise |
| Custodia de claves | `space-os-kis` | Rust, axum, Postgres |
| Agente desktop / mobile | `space-os-aether-app` | Electron + Expo |
| Portal web | `space-os-app` | Next.js 16 |

---

## 3. El protocolo de nodos

`NODE_PROTOCOL.md` (en `space-os-aether-app/docs/`) es la especificación de referencia. Esta sección lo resume.

### 3.1 Roles

Un participante de la red declara uno o más roles:

| Rol | Función |
|---|---|
| `identity` | Autenticación de wallet, registro de dispositivos, emisión de JWT, facturación |
| `client` | Aloja el runtime del agente; capacidades de usuario/dispositivo |
| `coordinator` | Presencia, sincronización de memoria, enrutamiento de turnos, registro de relays |
| `inference.router` | Pasarela compatible con OpenAI (SpaceRouter) |
| `inference.gpu` | Sirve modelos en GPUs propiedad de los usuarios |
| `compute.cpu` | Cómputo en sandbox (nodelets) |
| `storage` | Almacenamiento direccionado por contenido con replicación |
| `relay` | Travesía NAT con WireGuard |
| `chain.node` / `chain.client` | Participación en Antelope y EVM |

### 3.2 Manifiesto de capacidades

Cada nodo, al unirse, declara sus capacidades:

```json
{
  "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 }
}
```

El coordinador anuncia una capacidad solo si al menos un nodo accesible la soporta.

### 3.3 Escala de tiers

Las capacidades están limitadas por un **tier** a nivel de OS. La mayoría de los usuarios viven en `runtime`. Android sideloaded, desktop y hardware dedicado pueden alcanzar tiers superiores.

| Tier | Desbloqueo | Añade |
|---|---|---|
| `runtime` | Permisos estándar | Cámara, mic, ubicación, VPN con consentimiento, WebView |
| `special` | Toggles en ajustes (Android) | Accesibilidad, MANAGE_EXTERNAL_STORAGE, overlay |
| `shizuku` | Emparejamiento ADB del usuario | Instalación silenciosa, wifi silencioso, captura de pantalla |
| `device_owner` | Provisioning DPC | VPN siempre activa, concesión silenciosa, configuración entre apps |
| `root` | Magisk / desktop / servidor | Sistema de archivos completo, cross-sandbox |

### 3.4 Scopes de capacidad

Las herramientas declaran un scope para que el coordinador pueda enrutar al nodo más adecuado para ejecutarlas. Así es como funcionan las llamadas a herramientas entre dispositivos (buscar desde tu portátil usando la IP residencial de tu móvil).

| Scope | Proveedor típico |
|---|---|
| `anonymous` | Cualquier nodo, fetch limpio |
| `residential_ip` | IP doméstica o móvil |
| `user_authenticated` | Nodo donde el usuario ha iniciado sesión |
| `geolocated(country)` | Jurisdicción específica (usado para enrutamiento soberano) |

### 3.5 Niveles de estado

| Estado | Significado |
|---|---|
| `foreground` | UI activa |
| `foreground_service` | Daemon en ejecución continua |
| `bg_ephemeral` | Recientemente en segundo plano |
| `suspended` | Accesible solo mediante wake por push |
| `offline` | Sin transporte |

El enrutamiento de turnos prefiere `foreground` y luego `foreground_service`, recurriendo a rutas de wake-up.

### 3.6 Protocolo de cable

El transporte es WebSocket (Aether) y HTTP compatible con OpenAI (SpaceRouter). Los tipos de mensaje incluyen `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`, y `ping` / `pong`. La gramática completa está en `NODE_PROTOCOL.md`.

### 3.7 Peer-RPC

Los dispositivos pueden llamarse entre sí sin pasar por el LLM. Plano de control: `health`, `describe_self`, `describe_tools`, `describe_topics`. Plano de datos: `agent_query`, `topic_get`, `topic_subscribe`, `tool_invoke`. `tool_invoke` está restringido por una lista blanca explícita por herramienta y por peer.

---

## 4. Aether — el agente

Aether es el **runtime que convierte un conjunto emparejado de dispositivos en un único agente**. El usuario tiene un agente, una identidad, una memoria — instanciados allí donde los necesite.

### 4.1 Bucle ReAct

El runtime es un bucle ReAct en TypeScript compartido entre desktop, mobile y web. En cada turno del usuario: compone una porción de prompt a partir de memoria, awareness y personalidad; despacha al modelo a través de SpaceRouter; transmite tokens; invoca cualquier herramienta que el modelo solicite; itera hasta que el turno se completa; persiste el resultado en el registro de memoria de operaciones firmadas.

### 4.2 Memoria

La memoria es un **registro append-only de operaciones firmadas** —conversaciones, hechos, adjuntos, preferencias, entidades, tareas, jobs. Cada operación está firmada por el dispositivo que la produjo. Los scopes dan al usuario el control:

- `synced` — replicado a los otros dispositivos del usuario.
- `local` — solo en el nodo, nunca sale de la máquina.
- `session` — efímero, no persistido.
- `subagent:{job_id}` — visible solo para un sub-agente.
- `private` — cifrado en el cliente antes de llegar al coordinador.

El cifrado y la gestión de claves del scope `private` son TBA — la implementación actual usa cifrado simétrico con una clave guardada en el dispositivo; la especificación debe indicar el algoritmo y la historia de rotación de claves.

Porción por turno = hechos pinneados + recuperación por embeddings + expansión de entidades + turnos recientes. Stores: `better-sqlite3` en desktop, `expo-sqlite` en mobile, IndexedDB en web.

### 4.3 Awareness

Un segundo grafo se ejecuta junto a la memoria: **Awareness**. Donde la memoria es un log cronológico de operaciones, awareness es un grafo estructurado de entidades —personas, proyectos, lugares, temas, cosas— construido en segundo plano por un watcher follow-along que etiqueta menciones en las conversaciones y propone nuevas entidades. Cada entidad tiene `INDEX.md` (frontmatter + resumen), `notes.md` (observaciones con marca de tiempo) y media adjunta.

Awareness es local-first; la sincronización es opt-in por entidad. Herramientas: `awareness.relevant()`, `awareness.get(id)`, `awareness.search()`, `awareness.create()`, `awareness.attach()`. Los ajustes exponen un panel de almacenamiento con políticas de auto-limpieza.

### 4.4 Personalidad

Una persona estructurada controla cómo responde el modelo. Sliders por rasgo (0–100) más un campo libre de identidad "Soul" de 1000 caracteres más carácter de voz más seis plantillas predefinidas. El system prompt se compone en el momento del turno, no se fija estáticamente. La personalidad se sincroniza entre los dispositivos del usuario como una operación `pref.set`.

Conjunto de rasgos: calidez, verbosidad, humor, asertividad, creatividad, formalidad, proactividad, IQ emocional.

### 4.5 Herramientas

Más de 50 herramientas en familias: fetch & navegación, mensajería, sensores, información personal, sistema de archivos, plano de almacenamiento, cómputo, automatización entre apps, redes, identidad, comodidades de memoria. Las herramientas se enrutan vía scope de capacidad al nodo más capaz de ejecutarlas.

### 4.6 Modo servicio

El desktop ejecuta el agente como daemon en segundo plano (systemd-user / Windows SCM / launchd). Cerrar la UI no detiene al agente. El Task Bus rastrea trabajo recurrente con una proyección de coste anual y auto-pausa en sobrepaso. El Event Bus (anillo de ~50k eventos) registra "cosas que han ocurrido y que pueden importarle al usuario." `agent.askOneShot` expone RPC one-shot para cargas headless (resumen de noticias, polling, investigación automatizada).

### 4.7 Voz

La voz es opt-in y se enruta según preferencia del usuario. Tres fuentes de voz:

- **Device** — Whisper STT en dispositivo y TTS en dispositivo (XTTS-v2 como fallback). La voz nunca abandona la máquina.
- **Hub** — STT + TTS en la nube (PROPOSED por defecto: Deepgram Nova-2 + ElevenLabs streaming) para uso de consumo de baja latencia.
- **Off** — voz suprimida.

Para los despliegues soberanos, solo se permite la ruta **Device**. La ruta hub está documentada pero nunca por defecto para clientes privados / gubernamentales / militares.

---

## 5. Red de inferencia

### 5.1 SpaceRouter

`spacerouter.ai` es una pasarela de inferencia compatible con OpenAI construida sobre LiteLLM. Endpoints: `/v1/chat/completions`, `/v1/completions`, `/v1/embeddings`. Autenticación: API key. Los mismos SDKs que OpenAI — solo cambia la base URL.

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

### 5.2 Descubrimiento de proveedores

SpaceRouter consulta la cadena cada 60 segundos (`SPACEOS_REFRESH_INTERVAL`) para obtener los proveedores activos en la tabla `gpuresource` de `eosio`. Los proveedores cuyo heartbeat esté obsoleto (`SPACEOS_HEARTBEAT_TIMEOUT = 600s`) son descartados. El router mantiene metadatos por proveedor sobre VRAM y soporte de modelos; en cada petición filtra a los proveedores que pueden servir el modelo solicitado y elige uno según la estrategia de enrutamiento (por defecto: el más barato, con cadena de fallback).

### 5.3 Estrategias de enrutamiento

| Estrategia | Comportamiento |
|---|---|
| `auto` | Proveedor elegible más barato; failover ante error |
| `parallel` | Carrera entre dos proveedores; gana el primero en completar |
| `handoff` | Fijado a un dispositivo; handoff manual |
| `failover` | Lista ordenada estricta con auto-recuperación |
| `custom` | Cadena definida por el usuario |

Las estrategias se exponen a usuarios avanzados en el panel Ajustes → Developer.

### 5.4 Tiers de proveedor

| Tier | Stake | Prioridad de enrutamiento | Multiplicador de recompensa |
|---|---|---|---|
| Free | 0 | Overflow | 1.0× |
| Basic | 1.000 SPACE | Normal | **PROPOSED** 1.25× |
| Pro | 10.000 SPACE | Alta | **PROPOSED** 1.5× |
| Enterprise | 100.000 SPACE | Máxima, voto en gobernanza | **PROPOSED** 2.0× |

El tier Free sirve inmediatamente y gana de las comisiones de inferencia. El tier Basic gana un multiplicador de 1.25× y APY sobre el SPACE en stake. El tier Pro gana 1.5× y se prefiere para usuarios premium. El tier Enterprise gana el máximo de 2.0×, vota en la DAO y obtiene acceso anticipado a nuevos despliegues de modelos. Cada GPU registrada también deposita un pequeño bond por dispositivo en `SpaceProviderBond` (slasheable por mal uptime, devuelto al deregistrarse); el bond es independiente del stake de wallet y solo el bond está en riesgo por incidencias a nivel de dispositivo.

### 5.5 Economía del proveedor — ilustrativa

Ganancias PROPOSED, mensuales indicativas en el tier Free asumiendo 80%+ de uptime:

| Clase de hardware | Mensual |
|---|---|
| RTX 3090 / 4090 (24 GB) | $120 – $260 |
| A6000 / L40S (48 GB) | $320 – $680 |
| A100 / H100 (80 GB) | $900 – $1,800 |

Estas cifras necesitan validación empírica frente al tráfico de testnet y la mezcla de demanda. **TBA: benchmark publicado a partir de un informe mensual de muestra una vez que el tráfico de mainnet se estabilice.**

### 5.6 Modelos

Actualmente enrutados a través de SpaceRouter (testnet, mayo de 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 (visión)
- BGE Large (embeddings)

Los modelos se añaden por solicitud y bajo demanda. El router expone `GET /api/router/models` para una lista en vivo.

---

## 6. Cadena nativa

### 6.1 Fork de Spring

La cadena nativa es un fork de **Spring v1.2.2** —el motor de consenso Antelope modernizado mantenido por la EOS Network Foundation. SPACE OS utiliza el tooling estándar de Antelope (`nodeos`, `cleos`, `keosd`) con 22/22 protocol features activadas, incluyendo BLS, WebAuthn y parámetros de blockchain configurables en runtime.

- **Token SPACE:** nativo de 4 decimales, suministro máximo 1.000.000.000,0000, emisión inicial de 100M a `eosio`.
- **Tiempo de bloque:** ~0,5 s.
- **Génesis:** bootstrap de testnet con un único productor. Conjunto de productores de mainnet: TBA.

### 6.2 Heartbeat GPU

Los proveedores ejecutan `spaceos-node` (`nodeos` dockerizado más un bucle de heartbeat). Cada cinco minutos el bucle llama a `gpuheartbeat` en el contrato de sistema, registrando las especificaciones de GPU del proveedor (modelo, VRAM, núcleos CUDA, TFLOPS) y afirmando liveness. La distribución de recompensas por tier de stake y la emisión por inflación (`gpudistrib`, `gpuminflate`) ocurren on-chain en el mismo contrato.

### 6.3 Contratos de sistema

`system-contracts/` despliega más de 18 contratos en la cadena nativa. Los más estructurales para un lector de este documento:

| Contrato | Rol |
|---|---|
| `eosio.token` | Saldo de SPACE + tokens bridgeados |
| `eosio.system` | Recursos (RAM, CPU, NET), staking, voto |
| `eosio.evm` | Intérprete EVM (ver §7) |
| `spaceos.prov` | Staking de proveedor, heartbeat, distribución de recompensas |
| `spaceos.dao` | Gobernanza (fase 1: solo cambios de parámetros) |
| `spaceos.bridge` | Lógica del bridge nativo ↔ EVM |
| `spaceos.bank` | Primitivas de liquidez / préstamo |
| `spaceos.vest` | Vesting de tokens |
| `spaceos.emit` | Emisión e inflación |

---

## 7. EVM embebida

### 7.1 Diseño

SPACE OS ejecuta una **EVM dentro de un contrato WASM de Antelope** en lugar de como cadena separada. El intérprete es un fork de Silkworm compilado a WASM y desplegado como `eosio.evm`. Cada transacción EVM se envuelve en una acción Antelope (`pushtx`) por el servicio **tx-wrapper**, se liquida atómicamente y es reproducida por `space-os-evm-node` (una segunda build de Silkworm que consume el estado de Antelope vía el protocolo SHiP y expone Ethereum JSON-RPC en `:8545`).

El beneficio: semántica EVM completa con el consenso y la finalidad de Antelope, sin bridge de cliente ligero entre dos cadenas, sin un conjunto de validadores separado.

### 7.2 Detalles de red

| Campo | Testnet | Mainnet |
|---|---|---|
| Chain ID | 800000 | 800000 |
| RPC | `https://testnet.evm.spaceos.com` | `https://evm.spaceos.com` |
| TX wrapper | `https://testnet.evm.spaceos.com/tx` | `https://evm.spaceos.com/tx` |
| Explorer | `https://testnet.evm-explorer.spaceos.com` | `https://evm-explorer.spaceos.com` |
| Gas token | SPACE (18 decimales) | SPACE (18 decimales) |
| Gas price | 150 Gwei | 150 Gwei |
| Tiempo de bloque | ~0,5 s | ~0,5 s |

Las transacciones son **solo legacy (tipo 0)** — EIP-1559 no está soportado (PUSH0 deshabilitado, EVM Shanghai). Solidity ≤ 0.8.19.

### 7.3 Contratos en lado EVM (selección)

| Contrato | Dirección (testnet) | Rol |
|---|---|---|
| BridgeTokenFactory | `0x23E73f0468eFB3c54e3104e844013cC039Fea18D` | Mintea/quema ERC-20s bridgeados |
| USD.s | `0xab4B7e7511Fd16aC57Ee3fdff820f140BAd38e62` | Stablecoin USD de SPACE OS |
| USDT.s | `0x038CeB66ec0Ca64F0a657b0d7819dA311f5b4EFe` | Tether bridgeado |
| USDC.s | `0x498c006a4850F358da4106616a4972468e1F3E39` | USDC bridgeado |
| SpaceVault | `0xb8015595b868767E8f501740EbAF6d79D2eC9294` | Lending auto-colateralizado (§12) |
| SpaceInsurance | `0x8f19eF01973e1E9Ca478210B20eAf873F6e39A5B` | Herencia de vault (§13) |
| SpaceIdentityRegistry | `0xdac13CD9f9d152577f58B864b9efB61A7F110374` | Niveles KYC/AML |
| SpaceRWAFactory | `0x92A425d8A690c27b34e9A3023284e78df972F46f` | Tokens RWA con cumplimiento normativo |
| SpaceFaucet | (solo testnet) | 100 SPACE / cooldown de 24h |
| SpaceStaking | (en producción) | 12,5% APY, unstake a 7 días |

---

## 8. Bridges

### 8.1 Nativo ↔ EVM

**Token SPACE nativo → EVM:**
1. Transferir SPACE a `eosio.evm` con memo `0xEVMAddress`.
2. SPACE acreditado como gas token nativo en EVM (conversión decimal ×10^14: 4 → 18).

**Stablecoin nativo → EVM:**
1. El usuario transfiere USD a `spaceos.brdg` con memo `0xEVMAddress`.
2. `spaceos.brdg` bloquea los tokens, llama a `eosio.evm::call`.
3. `BridgeTokenFactory.mint(token, to, amount)` en EVM.
4. El usuario recibe USD.s ERC-20.

**EVM → nativo:**
1. El usuario llama a `BridgeTokenFactory.bridgeToNative(token, amount, nativeAccount)`.
2. La factory quema los tokens .s, envía `bridgeMsgV0` a una dirección reservada.
3. `eosio.evm::onbridgemsg` entrega a `spaceos.brdg`.
4. `spaceos.brdg` libera los tokens nativos.

Conversión decimal en la frontera: 4 ↔ 18 para SPACE / USD, 4 ↔ 6 para tokens bridgeados legacy USDT/USDC.

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

`space-os-fiat-service` es el servicio operativo. **Cada stablecoin fiat en circulación está respaldado 1:1 por fiat real en una cuenta bancaria.**

| Token | Respaldo | Autoridad de mint | Origen |
|---|---|---|---|
| USD.s | USD en banco / Stripe | `FiatStablecoinFactory` (firmante de tesorería) | Stripe, Wise USD, transferencia bancaria |
| EUR.s | EUR en banco | `FiatStablecoinFactory` | Wise EUR, SEPA |
| GBP.s | GBP en banco | `FiatStablecoinFactory` | Wise GBP, banco UK |
| USDT.s | USDT bloqueado en bridge | `BridgeTokenFactory` | Ethereum, Polygon, etc. |
| USDC.s | USDC bloqueado en bridge | `BridgeTokenFactory` | Ethereum, Polygon, etc. |

**Cron de reconciliación** se ejecuta cada 6 horas: compara el `totalSupply()` on-chain con los saldos bancarios. El superávit (`banco − supply`) debe ser ≥ 0. **Auto-pausa el minteo si el déficit supera el 1%.** Las operaciones de mint y burn se escriben en una colección inmutable `MintBurnLog`. Las retiradas requieren revisión por administrador para importes superiores a un umbral configurable.

Límites de seguridad de tesorería: $500 máximo por transacción individual, $5.000 de salida diaria, guardia de idempotencia en cada transferencia.

### 8.3 Bridges de cadenas externas

El diseño actual soporta **EVM → SPACE OS** (lock-and-mint de USDT y USDC en USDT.s y USDC.s). Un bridge BTC nativo y un soporte más amplio de bridges EVM externos están en la hoja de ruta según `documents/planning-specifications/bridges.md`. **TBA: cronograma y modelo de seguridad para el bridge BTC.**

---

## 9. Economía del token SPACE

> **Estado:** §9 es la sección que necesita más expansión antes de su publicación. Las cifras de abajo proceden de `documents/planning-specifications/tokenomics.md` —forman un modelo v0 coherente pero carecen de una curva de emisión, un calendario de unlocks plurianual y diagramas explícitos de aplicación on-chain. Los puntos de expansión están marcados como TBA.

### 9.1 Utilidad

SPACE es el token de utilidad de la red. Los holders lo usan para:

1. **Pago de inferencia.** Los cargos por token (o créditos de suscripción) se liquidan en USD.s en la EVM, con SPACE como alternativa.
2. **Staking de proveedor.** Los tiers Basic / Pro / Enterprise requieren un stake mínimo de SPACE a nivel de wallet (1.000 / 10.000 / 100.000) para el multiplicador de ganancias; además, cada GPU registrada deposita un pequeño bond por dispositivo en `SpaceProviderBond` como colateral de slashing.
3. **Gobernanza.** Peso de voto en propuestas de la DAO (cuadrático — ver §15).
4. **Acceso a recursos.** Asignación de CPU / NET en la cadena nativa bajo la mecánica estándar de Antelope.

### 9.2 Suministro

- **Suministro total:** 1.000.000.000 SPACE.
- **Inflación:** 2% por año, minteado al pool de recompensas.
- **Deflación:** se queman el 20% de todas las comisiones del protocolo.
- **TBA:** curva anual de emisión hasta el año 10; calendario de reservas para el pool de recompensas; aplicación on-chain de los topes.

### 9.3 Distribución

| Asignación | % | Vesting |
|---|---|---|
| Proveedores / Edge | 40 | Lineal en 3 años |
| Becas a desarrolladores | 20 | Basado en hitos |
| Tesorería / DAO | 20 | Voto de gobernanza |
| Equipo / Ecosistema | 10 | Cliff de 4 años |
| Liquidez | 10 | Inmediato |

**TBA:** cadencia detallada de unlocks (tramos mensuales, fechas de cliff, quién controla el multisig que libera cada uno); una dirección publicada del contrato de vesting; la fecha del token generation event.

### 9.4 Rendimiento de staking

```
yield = base_apr + (inferences * 0.001 / stake)
```

Parámetros PROPOSED: `base_apr = 5%`, el componente de uso otorga 0,001 SPACE por inferencia servida, normalizado por unidad de stake. El resultado es un suelo de rendimiento del 5% con upside para proveedores de alta utilización. Los multiplicadores de tier (Staked 1.5×, Pro 2.0×) se componen encima.

### 9.5 Reparto de recompensas

Por comisión de inferencia, antes de quemas:

| Receptor | Proporción |
|---|---|
| Proveedor | 60% |
| Propietario del modelo | 20% |
| Oráculos | 10% |
| Tesorería | 10% |

El 20% de la parte de tesorería se **quema**; el resto se acumula en la wallet de tesorería controlada por la DAO para becas, auditorías y operaciones.

### 9.6 Slashing

| Disparador | Penalización |
|---|---|
| Incumplimiento de uptime (>5% heartbeats perdidos por época) | 10% del stake |
| Envío de prueba incorrecta (oráculo / inferencia / pin) | 50% del stake |

**TBA:** el mecanismo de testigo (quién atestigua el downtime — oráculos de heartbeat según `oracle-spec.md`); la vía de disputa más allá del voto DAO de 24h; la acción on-chain que ejecuta el slash.

### 9.7 Comisión de protocolo

1% sobre cómputo. **Interpretación PROPOSED:** el 1% es *aditivo* al precio del modelo por token publicado en `/pricing`. Los tiers de suscripción pre-pagan la comisión de protocolo dentro del bundle. Vale la pena confirmar con el equipo antes de publicación.

---

## 10. Primitivas DeFi sobre la EVM

### 10.1 SpaceVault — lending auto-colateralizado

El vault es una primitiva de lending **sin liquidación**. Los usuarios depositan un stablecoin y piden prestado contra él en **el mismo activo**.

| Parámetro | Valor |
|---|---|
| LTV stable | 95% (USD.s, USDT.s, USDC.s) |
| Comisión de protocolo | 0,5% sobre préstamos |
| Liquidación | Ninguna |
| Same-asset | Depositar USD.s → pedir USD.s |

El mecanismo es directo: como el depósito y la deuda están denominados en el mismo activo estable, no se necesita oráculo y no puede ocurrir liquidación por shock de precio. El vault cobra una comisión de origen del 0,5% sobre los préstamos. El producto está pensado para usuarios que quieren utilidad de depósitos de stablecoins ociosos sin asumir riesgo de liquidación.

**PROPOSED:** la restricción same-asset es el diferenciador y debería ser el titular de cualquier marketing del vault. Los diseños cross-asset están explícitamente fuera del alcance para conservar la propiedad de no liquidación.

### 10.2 SpaceInsurance — protección de vault

Producto opcional de seguro para depositantes del vault y otros casos de uso de tipo beneficiario.

| Característica | Valor |
|---|---|
| Cobertura base | Gratis — establecer beneficiario + timeout de inactividad |
| Cobertura de pool | Prima opcional por payout adicional |
| Disparadores de claim | Timeout de inactividad O override de 3-de-N guardianes |
| Dead man switch | Configurable de 30 días a 10 años |

El diseño dead-man-switch está pensado para casos de uso de planificación patrimonial y family office (segmento privado).

### 10.3 RWA — activos del mundo real

`SpaceRWAFactory` despliega activos del mundo real tokenizados con cumplimiento normativo. Jurisdicción: BVI / Cayman.

| Característica | Valor |
|---|---|
| Niveles KYC | Retail, Acreditado, Institucional, Exento |
| Restricciones de transferencia | Solo inversores verificados pueden mantener/transferir |
| Transferencia forzada | Órdenes judiciales vía agente de transferencia |
| Dividendos | Distribución proporcional on-chain |
| Registro de documentos | CIDs de IPFS para prospecto, escrituras, auditorías |
| Clases de activo | Inmobiliario, materias primas, valores, arte |

La verificación KYC la realiza `SpaceIdentityRegistry`. El hook de transferencia de un token consulta el registro en cada movimiento; las direcciones no verificadas son rechazadas.

---

## 11. Identidad y custodia de claves

### 11.1 Autenticación

La autenticación es **solo por firma de wallet** —sin contraseñas. Desafío de nonce EIP-191 estándar:

1. `GET /api/auth/nonce?address=0x...` → mensaje.
2. El usuario firma el mensaje con su wallet.
3. `POST /api/auth/verify` → JWT (caducidad de 7 días).

El primer dispositivo se empareja por firma de wallet. Los dispositivos posteriores se emparejan con un código de 6 dígitos generado por un dispositivo ya emparejado. La recuperación es la reimportación de la wallet.

Cada usuario autenticado recibe tres wallets:

- **Wallet conectada** — EOA externa (MetaMask, Coinbase, Phantom, Exodus, Trust, Rainbow).
- **Wallet proxy** — wallet EVM gestionada por el servidor en la cadena SPACE OS. Usada para pagos de protocolo y tokens custodiados.
- **Cuenta nativa** — cuenta Antelope para staking, voto y gobernanza.

### 11.2 KIS — Servicio de Emisión de Claves

Las claves privadas proxy y nativa están bajo un servicio de custodia con dominio de confianza separado en Rust (`space-os-kis`). KIS utiliza **ChaCha20-Poly1305 AEAD** para cifrado de envoltorio con una clave maestra envuelta vía scrypt. App-api nunca descifra; la firma ocurre dentro de KIS en una closure que mantiene la clave durante milisegundos y luego devuelve `raw_signed_tx`.

El flujo de firma en producción:

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

KIS expone `/sign-evm`, `/rotate` (sweep + intercambio de claves tanto para nativo como ERC-20), y `/admin/import` (restringido, para migraciones). El log de auditoría es JSON estructurado a stdout, en un namespace distinto de app-api. Keystore cifrado respaldado por Postgres con un PVC de 5 GiB; backend HSM planificado para una fase futura.

KIS está desplegado en testnet. El hardening de producción —provisionamiento de secretos con Vault-Agent, terminación mTLS, lockdown multisig, ceremonia de exportación endurecida, swap-in de HSM— está en el roadmap contra la checklist estándar de pre-lanzamiento de custodia. **TBA: informe de auditoría de lanzamiento de producción y vía de divulgación de seguridad.**

### 11.3 KYC y registro de identidad

`SpaceIdentityRegistry` es el registro KYC on-chain. Registra cuatro niveles: Retail, Acreditado, Institucional, Exento. Los contratos RWA y otros productos sujetos a cumplimiento consultan el registro en la transferencia. Los proveedores de KYC se integran off-chain por `app-api`; el estado verificado se escribe on-chain por el rol verificador. **TBA:** la lista de proveedores KYC activos y la política de almacenamiento de evidencias.

---

## 12. Gobernanza

`spaceos.dao` es el contrato de gobernanza on-chain. El marco se establece en `dao-constitution.md`.

### 12.1 Poder de voto

- Los holders del token votan con **voto cuadrático** (1 SPACE = 1 voto, raíz cuadrada en el conteo).
- **Tres consejos** elegidos trimestralmente: Proveedor, Desarrollador, Usuario.
- **Control de tesorería:** multisig 3-de-5 del consejo + quórum del 10% de holders del token.

### 12.2 Tipos de propuesta

| Tipo | Quórum | Duración | Retraso de ejec. |
|---|---|---|---|
| Cambios de parámetros | 5% | 7 días | 1 día |
| Upgrades | 20% | 14 días | 7 días |
| Gasto de tesorería | 10% | 7 días | 3 días |
| Pausa de emergencia | 1% | 24 h | Inmediato |

### 12.3 Fases

- **v1 (hoy):** solo cambios de parámetros — tasas de comisión, umbrales de slashing, mínimos de tier.
- **v2:** control completo de tesorería + upgrades.

Mecanismos anti-captura: timelocks en cada ejecutable; topes de delegación que evitan la concentración; la pausa de emergencia requiere solo un quórum del 1% para detener la red en un incidente de seguridad, pero no puede usarse para *cambiar* nada — solo para detener.

**TBA:** la lista precisa de parámetros mutables en v1, la ABI de la acción on-chain `propose / vote / execute`, y la dirección del contrato una vez finalizada.

---

## 13. Privacidad

### 13.1 Hoy

- Las operaciones de memoria están firmadas por el dispositivo productor.
- El scope de memoria `private` está **cifrado en el cliente antes de llegar al coordinador**. Cifrado: **TBA — debe especificarse el algoritmo (AES-GCM 256 propuesto), la derivación de claves y la política de rotación de claves antes de la publicación.**
- App-api y KIS se ejecutan en dominios de confianza separados.
- Los despliegues soberanos operan el coordinador on-prem; ningún tráfico abandona el perímetro del cliente.

### 13.2 Roadmap — ZK + FHE (fase 3)

`zk-fhe-privacy.md` esboza el diseño de la fase 3:

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

El usuario cifra las entradas con FHE; el proveedor GPU computa dentro de un enclave sobre la entrada cifrada; una prueba ZK atestigua la ejecución correcta sin revelar entradas ni salidas.

**TBA:** esquema FHE concreto (¿CKKS / TFHE / BFV?), sistema de pruebas (¿Groth16 / Halo2 / Plonk?), hardware de enclave (TEE: ¿SGX / TDX / Nitro?), presupuesto de latencia end-to-end, modelo de coste (la inferencia FHE es actualmente 100–1000× más lenta que en plano — necesita guía explícita sobre a qué cargas se aplica).

### 13.3 Seguridad de IA

Filtros pre y post inferencia para toxicidad e intentos de jailbreak. Listas negras gestionadas por la DAO. Comportamiento del modelo monitorizado por oráculos. **TBA:** implementación de filtros, objetivo de tasa de falsos positivos, vía de apelación.

---

## 14. Oráculos

`spaceos.oracle` es una red descentralizada de oráculos al estilo Chainlink para pruebas de hardware, SLA de uptime, estado de pin de IPFS y precios. Los nodos oráculo hacen stake de SPACE; los datos incorrectos se slashean al 50%. Agregación: mediana + firmas de umbral + pruebas ZK. Umbral honesto: 51%. Ventana de disputa: 24 h vía voto DAO.

| Tipo de prueba | Datos | Verificación |
|---|---|---|
| Hardware | Modelo de GPU, VRAM | Benchmark ZK (sin VM) |
| Uptime | SLA del 99% | Oráculos de heartbeat |
| Estado de pin | Disponibilidad de CID en IPFS | Test de fetch multinodo |
| Precios | Tasas de mercado | Feeds DEX + ofertas |

Recompensa de oráculo: 5% APY + porción de las comisiones de inferencia. **TBA:** la dirección del contrato de oráculo on-chain, la ABI de envío de pruebas, y el conjunto bootstrap de operadores de oráculo.

---

## 15. Almacenamiento

Almacenamiento direccionado por contenido con replicación. Herramientas: `storage.put / .get / .has / .pin / .unpin`. **TBA:** backend elegido (con inclinación hacia IPFS según los documentos de planificación, pero no finalizado), factor de replicación, estructura de incentivos para pinning, y economía del rol de proveedor de almacenamiento. La superficie del protocolo está definida; la capa operativa, no.

---

## 16. Hardware

### 16.1 Dispositivos SPACE OS-ready

La Store vende tres tiers de hardware de referencia:

| Tier | Clase | Rol |
|---|---|---|
| Aether Mini | Mini PC, 16 GB RAM | Host siempre encendido, servicio de agente, nodo ligero |
| Aether Studio | RTX 4090, 64 GB RAM | Inferencia local clase 70B, proveedor Free / Basic |
| Aether Workstation | H100, 128 GB RAM, 10 GbE | Proveedor Pro / Enterprise, expansión multi-GPU |

Más hardware complementario (superficie de voz Aether Orb, Companion Display) y merch usando el set de iconos AetherMark. La Store está actualmente en pre-lanzamiento con captura de email; el checkout abre con mainnet.

### 16.2 Hardware soberano

Para los despliegues privados / gubernamentales / militares, el hardware es a medida y air-gapped: un nodo clase Workstation con el coordinador on-prem, sin dependencia de la nube, con solo la ruta de voz **Device** activada. **TBA:** socios de hardware nombrados y documentos de arquitectura de referencia.

---

## 17. Modelos de despliegue

La misma arquitectura se despliega en cuatro perfiles de cliente sin cambios en el protocolo —solo configuración.

| Cliente | Coordinador | Inferencia | Scope de memoria | Voz | KYC |
|---|---|---|---|---|---|
| Consumidor | Cloud (`*.spaceos.com`) | Malla SpaceRouter | `synced` por defecto | Hub o Device | Ninguno |
| Empresa | Cloud o on-prem | SpaceRouter o autoalojado | Por equipo, a menudo `local` | Device por defecto | Gestionado por la org |
| Privado | On-prem (residencia) | Local + red opt-in | `private` por defecto | Solo Device | Family office |
| Gobierno / Militar | On-prem (nacional / táctico) | Malla soberana | `private` + cifrado on-prem | Solo Device | Soberano |

Los scopes de capacidad (§3.4) hacen del enrutamiento jurisdiccional una cuestión de primer nivel, no una idea tardía.

---

## 18. Modelo de amenazas

> **TBA: §18 está deliberadamente delimitada para v1. Cada perfil de cliente en §17 tiene un modelo de amenazas distinto y necesita una sub-sección separada. A continuación se ofrece el esqueleto estructural.**

Para cada perfil deberíamos especificar:

1. **Modelo de adversario.** Quién ataca, cuáles son sus capacidades.
2. **Fronteras de confianza.** Qué componentes deben ser confiables, cuáles pueden comprometerse sin romper la propiedad.
3. **Propiedades preservadas.** Confidencialidad, integridad, disponibilidad, corrección de facturación, solidez de gobernanza.
4. **Mitigaciones y riesgo residual.**

Primera pasada PROPOSED: el perfil consumidor asume un proveedor curioso y un coordinador curioso; el perfil privado asume un coordinador comprometido (mitigado por on-prem); el perfil soberano asume un adversario estado-nación con capacidades de red y de cadena de suministro (mitigado por air-gap, atestación de hardware y auditoría de protocolo).

---

## 19. Estado de implementación

Según `implementation-plan.md`, un plan por fases de 36 semanas con security gates (auditoría ≥ 80/100 por fase, ≥ 95/100 final). Presupuesto indicativo de $240K hasta mainnet.

| Fase | Duración | Objetivos | Estado |
|---|---|---|---|
| 0 — Cimientos | 6 sem | Fork de Spring, contratos oracle/DAO, baseline | **Testnet en producción** |
| 1 — Staking principal | 6 sem | Staking GPU/TEE | **En producción** (`spaceos.prov`, UI de tier en la app) |
| 2 — Aether edge | 8 sem | P2P/orquestación de dispositivos, streams de sensores | **En producción** (coordinador + app desktop) |
| 3 — Gobernanza DAO | 8 sem | Voto cuadrático + incentivos | **Fase 1 en producción** (solo parámetros); v2 en curso |
| 4 — Mainnet | 8 sem | Dashboard de KPIs, auditoría completa, onboarding | **Pendiente** |

Objetivos KPI de mainnet: TVL $10M+, 1M de inferencias/día, 10k proveedores, churn <5%, latencia p95 <100 ms.

**TBA:** fecha objetivo de mainnet, firma auditora y fechas de informe, y la hoja de ruta post-mainnet.

---

## 20. Análisis comparativo

> **TBA: §20 está reservada para v1. Una sección comparativa real necesita afirmaciones cuidadosas y es la sección con más probabilidades de atraer escrutinio —no merece la pena publicarla con prisas.**

La estructura prevista:

| Proyecto | Red de inferencia | Agente personal | Pagos on-chain | Protocolo abierto | Despliegue soberano |
|---|---|---|---|---|---|
| Bittensor | ✓ (subnets) | parcial | ✓ | parcial | parcial |
| Akash | ✓ (cómputo general) | ✗ | ✓ | ✓ | parcial |
| io.net | ✓ | ✗ | ✓ | parcial | ✗ |
| OpenRouter | ✓ (centralizado) | ✗ | ✓ | ✗ | ✗ |
| **SPACE OS** | ✓ | **✓** | ✓ | **✓** | **✓** |

Cada fila necesita un párrafo de comentario citando fuentes públicas. **PROPOSED:** el diferenciador con el que lideramos es la combinación *agente personal + despliegue on-prem + protocolo abierto* —ninguno de los comparadores cubre los tres. Validar esta afirmación frente al estado actual de las subnets de Bittensor TAO y Akash antes de la publicación.

---

## 21. Conclusión

SPACE OS opera sobre una tesis: que la IA personal es el próximo cambio de plataforma, que la inferencia descentralizada es la estructura de oferta correcta, y que un protocolo abierto con arquitectura desplegable de forma soberana es la forma adecuada para la próxima década de uso de IA regulado y sensible a la seguridad. La tesis está implementada en 22 repositorios activos con testnet desplegado y un plan por fases hacia mainnet.

Para los consumidores: **Aether es tu agente de IA en tus dispositivos.** Para los desarrolladores: **SpaceRouter es inferencia compatible con OpenAI a menor coste.** Para los proveedores: **gana SPACE con tu GPU ociosa.** Para operadores privados, gubernamentales y militares: **la arquitectura se despliega air-gapped sin cambios en el protocolo.**

El trabajo restante está bien delimitado: profundidad en tokenomics, especificidades de ZK/FHE, análisis comparativo, modelos de amenazas por segmento, y el security gate de auditoría de mainnet en producción. Ninguno de ellos es un problema de investigación; todos son trabajo de documentación y operaciones contra una base de código madura.

---

## Apéndice A — Glosario

- **Aether** — el runtime del agente de IA personal que vive en los dispositivos del usuario.
- **Aether coordinator** — el servicio en cloud (u on-prem) `space-os-aether` que gestiona presencia, sincronización de memoria, enrutamiento de turnos.
- **Antelope / Spring** — el motor de consenso de la cadena nativa (fork de Spring v1.2.2).
- **Manifiesto de capacidades** — declaración JSON que cada nodo envía al unirse.
- **Scope de capacidad** — anotación en una herramienta que permite al coordinador enrutar la ejecución al nodo adecuado.
- **EVM embebida** — la EVM basada en Silkworm que se ejecuta dentro de un contrato WASM de Antelope (`eosio.evm`).
- **KIS** — Servicio de Emisión de Claves. Servicio de custodia en Rust, dominio de confianza separado.
- **Nodelet** — un runtime local en sandbox (Python o Node) supervisado por `hostd`.
- **Peer-RPC** — mensajería tipada dispositivo-a-dispositivo que evita el LLM.
- **SpaceRouter** — la pasarela de inferencia compatible con OpenAI.
- **Modo servicio** — el agente desktop ejecutándose como daemon en segundo plano.
- **Tier (operador)** — Free (0) / Basic (1k SPACE) / Pro (10k SPACE) / Enterprise (100k SPACE) — prioridad de enrutamiento del proveedor y multiplicador de ganancias (1.0× / 1.25× / 1.5× / 2.0×). Independiente del bond por dispositivo depositado en `SpaceProviderBond`.
- **Tier (capacidad)** — runtime / special / shizuku / device_owner / root — techo de permisos a nivel de OS.
- **USD.s, EUR.s, GBP.s** — stablecoins respaldados por fiat en la EVM, respaldo bancario 1:1.
- **USDT.s, USDC.s** — stablecoins bridgeados, respaldados por tokens bloqueados.

## Apéndice B — Endpoints (testnet)

| Servicio | URL |
|---|---|
| Portal web | `https://test.app.spaceos.com` |
| App API | `https://test.app-api.spaceos.com` |
| EVM RPC | `https://testnet.evm.spaceos.com` |
| EVM Explorer | `https://testnet.evm-explorer.spaceos.com` |
| Antelope explorer | `https://testnet.explorer.spaceos.com` |
| Faucet | `https://testnet.faucet.spaceos.com` |
| Router de inferencia | `https://spacerouter.ai/v1` |
| Registro de relay | `https://test.relay.spaceos.com` |
| Coordinador (Aether) | `wss://test.aether.spaceos.com` (PROPOSED — confirmar hostname) |

## Apéndice C — Cuestiones abiertas para v1

1. Tokenomics: curva de emisión, cadencia de unlocks plurianual, aplicación on-chain.
2. Privacidad: cifrado explícito para el scope de memoria `private`; esquema de fase 3 ZK/FHE + sistema de pruebas + TEE.
3. Slashing: mecanismo de testigo, vía de disputa más allá del voto de la DAO.
4. Bridges: cronograma y modelo de seguridad del bridge BTC.
5. Almacenamiento: backend elegido, replicación, incentivos de pinning.
6. Modelos de amenazas por segmento de cliente.
7. Análisis comparativo frente a Bittensor, Akash, io.net, OpenRouter.
8. Fecha de mainnet, firma auditora, hoja de ruta post-lanzamiento.
9. Política de ruta de voz para los despliegues soberanos (por defecto solo Device — confirmar).
10. Auditoría de producción de KIS y vía de divulgación.

## Apéndice D — Referencias

- Código fuente: `gitlab.64b.net/SPACE_OS/*`
- Open Node Protocol: `space-os-aether-app/docs/NODE_PROTOCOL.md`
- Especificaciones de planificación: `documents/planning-specifications/*.md`
- Integración EVM: `documents/planning-specifications/evm-integration.md`
- Tokenomics: `documents/planning-specifications/tokenomics.md`
- Constitución de la DAO: `documents/planning-specifications/dao-constitution.md`
- Plan de implementación: `documents/planning-specifications/implementation-plan.md`
- Plan de stablecoin fiat: `documents/fiat-stablecoin-plan.md`
- Revisiones anteriores: `website/docs/aether-app-review.md`, `aether-desktop-review.md`, `spaceos-fullstack-review.md`

---

*Fin del borrador v0. v1 a continuación tras la revisión por el fundador de los puntos TBA / PROPOSED.*