← Main page

SPACE ID Architecture: How Decentralized Naming Works

MD Article by MD

Introduction

Wallet addresses are powerful but unfriendly. Long hexadecimal strings create friction for users, increase the risk of errors, and make Web3 applications harder to use. Decentralized naming systems solve this problem by mapping human-readable names to blockchain resources.

SPACE ID is a multi-chain decentralized naming and identity protocol designed to unify Web3 identities across ecosystems. This article breaks down how SPACE ID works under the hood, explaining its architecture, components, and how decentralized naming is achieved.

Core Components of SPACE ID Architecture

SPACE ID can be understood as three practical pieces:

  • Domain Registry Layer (who owns what)
  • Resolver Layer (where records live)
  • Resolution & Integration Layer

1. Domain Registry Layer

The registry is the foundation of SPACE ID.

What the Registry Does

  • Keeps track of domain ownership
  • Records domain expiration and renewal data
  • Stores references to resolvers (like wallet addresses)

Each top-level domain (TLD) such as .bnb or other supported TLDs has its own registry contract, deployed on its native chain.

Why This Matters

  • Ownership is on-chain and trustless
  • Users control domains via their wallets
  • No centralized actors

2. Resolver Layer

Resolvers are where decentralized naming becomes practical.

What Is a Resolver?

A resolver is where a domain name is translated into usable data, such as:

  • Wallet address records
  • Domain-related metadata
  • Profile fields like avatars or NFT references (when supported)

How Resolution Works

  1. The app checks the registry to find who owns the name and which resolver it uses.
  2. Then it asks the resolver for the domain’s address record (and optionally other metadata).

3. Resolution & Integration Layer

Many apps avoid doing full multi-chain on-chain resolution inside their own code. Instead, they use SPACE ID’s hosted resolution API because it’s fast and simple.

The Common Pattern

Apps often resolve a domain by calling an endpoint like:

https://nameapi.space.id/getAddress?domain=123.inj https://nameapi.space.id/getAddress?domain=123.bnb https://nameapi.space.id/getAddress?domain=123.sei https://nameapi.space.id/getAddress?domain=123.eth

That gives apps a clean developer experience:

  • No multi-chain RPC setup
  • No chain-specific contract calls in the client
  • No dealing with different resolution patterns across ecosystems

What the API Typically Does Behind the Scenes

  • Detects the TLD (like .bnb, .sei, .inj)
  • Queries the correct chain/contracts and/or a maintained index
  • Returns the resolved address and any supported metadata
Resolution Flow: From Name to Address
  1. User enters a domain (e.g. alice.bnb)
  2. The app calls nameapi.space.id with the domain
  3. The API returns the resolved address
  4. The app uses the address for transfers, display names, and identity across dApps

Security and Decentralization

SPACE ID’s architecture follows key Web3 security principles (with a practical tradeoff in how most apps integrate):

  • User-owned assets: domains are owned by wallets
  • On-chain ownership: registries anchor who controls the name
  • Permissionless integration: any app can resolve names

Why This Architecture Matters

SPACE ID’s approach enables:

  • Better UX for users (names instead of addresses)
  • Easy integration for developers
  • Multi-chain support
  • Less friction for adoption

SPACE ID’s naming system can look complex on paper, but its architecture is straightforward: registry for ownership, resolver for records, and a resolution layer that makes it easy for apps to integrate.

Published December 31, 2025 8 min read