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.

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:

3.2 Manifiesto de capacidades

Cada nodo, al unirse, declara sus capacidades:

{
  "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.

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).

3.5 Niveles de estado

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.

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

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

5.4 Tiers de proveedor

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:

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:

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

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)

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.

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

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:

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

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.

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.

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.

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

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.

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:

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.

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.

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:

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)

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.