Active development · testnet
ProductsDownloadsAssistantAPIBlockchainNetworkPricingCustomersStoreWikiDevs
Launch
Back to Wiki

Wiki · Architecture

Architecture

The three-wallet model that bridges external EVM ecosystems, SPACE OS smart contracts, and the SPACE OS native chain.

Architecture

Each authenticated user gets a three-wallet model that bridges external EVM ecosystems, SPACE OS smart contracts, and the SPACE OS native chain.

The three wallets

Connected Wallet

Your external EVM wallet (MetaMask, Coinbase, WalletConnect, etc.). Used to sign in via SIWE (Sign-In With Ethereum) and to interact with other chains. Keys remain in the user's control.

Proxy Wallet

A server-managed EVM wallet on the SPACE OS chain. Holds your SPACE, USDT.s, USDC.s, and USD.s. Used for deposits, withdrawals, and API top-ups without requiring an external wallet signature for every transaction. Keys held in KIS (Key Custody Service), a separate-trust-domain custody service.

Native Account

A SPACE OS native account (Spring/Antelope) for staking, governance, and chain-level operations. Created automatically on first sign-in. Public key derivable; private key held in KIS.

Why three?

This model exists because SPACE OS spans two chain stacks (EVM + Spring/Antelope) and several user surfaces (web, desktop, API). The three-wallet split lets:

  • External wallets remain the user's identity root
  • High-frequency operations (API top-ups, micropayments) use the proxy without per-tx signing
  • Native chain operations (staking, governance) work without requiring users to manage Antelope keys

KIS holds proxy and native keys in a separate trust domain, so a compromise of the main API does not compromise user funds.

For wallet endpoints, see Wallet Management.