SPACE ID

SPACE ID: A Multi-Chain Naming Layer With ID Governance

SPACE ID combines blockchain domain registration, name resolution, domain trading, and developer integrations. The ID token is primarily a governance and ecosystem token, while the protocol’s practical usefulness depends on adoption by wallets, applications, domain issuers, and supported networks.

What SPACE ID is designed to do

SPACE ID presents itself as a universal name-service network for discovering, registering, trading, and managing Web3 domains. Its product is intended to replace or supplement long blockchain addresses with human-readable names, while giving users one interface for domains issued across different networks and top-level domains. The platform documentation describes four main functions: discovery, registration, trading, and management. These functions cover searching for available names, registering names, transferring or trading domain NFTs, and updating ownership or records.

The project’s initial identity products included .bnb names on BNB Chain and .arb names on Arbitrum, alongside support for .eth names through the broader platform. SPACE ID documentation says that domain names can be used as readable identifiers for applications and, where integrations exist, for activities such as sending funds or displaying a primary name. Those integrations are dependencies rather than automatic properties of every domain: a wallet or application must support the relevant resolver and naming standard before a name replaces an address in its interface.

How the naming stack works

At the user level, a domain is represented as a blockchain-based asset whose ownership can be transferred and whose records can be edited. The management documentation describes controls for transferring ownership, changing the record address, extending registration, and selecting a primary name for a network. A primary name is an application-facing choice: it tells compatible services which readable name should represent an address, but it does not make every application recognize that name.

For developers, SPACE ID provides a Web3 Name SDK and API. The registration integration documentation describes partner-facing tools for registering .bnb, .arb, and .eth names through an application’s own interface. The API documentation lists supported chains and domains, including Ethereum and BNB Chain, Arbitrum, Solana, and a growing set of ecosystem-specific namespaces. This creates a practical distinction between the core naming concept and the integration layer: the user experience depends on SDK availability, resolver support, chain connectivity, and the continued operation of the relevant APIs or front ends.

The role of the ID token

ID is described by SPACE ID as the ecosystem’s governance token. The project’s documentation assigns it three principal functions: staking for discounts on domain-marketplace fees and domain registration, payments within the ecosystem and Web3 Name SDK integrations, and participation in SPACE ID DAO votes. These functions make ID different from the domain assets themselves. A user does not need to treat ID as the name being registered; instead, it is intended to support incentives, fee-related benefits, and collective decision-making around the platform.

The documented maximum supply is 2,000,000,000 ID. The published allocation includes Binance Launchpad, advisors, strategic and seed sales, the core team, ecosystem and marketing programs, the foundation, and community airdrops. Several categories have staged vesting schedules, including cliff periods followed by quarterly or monthly releases. That structure makes unlock timing and the management of unvested allocations relevant to token supply analysis. The documentation also points to separate APIs for circulating and total supply, indicating that supply figures can change as unlocks, burns, or other accounting events are recorded.

Governance and control

SPACE ID’s governance model gives ID holders a formal role in DAO proposals and treasury decisions. The published process describes a discussion stage on the governance forum followed by a Snapshot vote. The documentation states that a proposal requires at least 50% passing votes from addresses collectively holding at least 5,000,000 ID, after which execution is handled by the core team and funding distributions are authorized by multi-signature signers elected by the DAO.

This is a hybrid control model rather than a claim that every protocol action is directly executed by token holders. Token holders can influence proposals under the stated rules, but the published process also assigns operational execution to the core team and treasury authorization to designated multi-signature signers. Readers should therefore distinguish voting rights from direct control over contracts, interfaces, domain operations, and treasury execution. The current forum is the more useful place to review whether the documented governance process has produced active proposals and how decisions are implemented in practice.

Expansion through TLD infrastructure

SPACE ID’s later documentation describes a permissionless toolkit for communities or developers seeking to launch their own top-level domains through the SPACE ID 3.0 infrastructure. The stated toolkit covers domain issuance, marketplace functions, management, and SDK or API access. The documentation also lists support for multiple domain systems, including .eth, .lens, .crypto, .bnb, and .arb, as well as domains launched through the toolkit. This broadens the project from operating individual naming services toward providing infrastructure for third-party namespaces.

The roadmap labels AI-agent domains as a later area of exploration and describes earlier stages focused on .bnb and multi-chain Web3 domains. These roadmap statements are project plans, not evidence that every planned product or integration has been delivered. The practical test for the expansion thesis is continued use of the registration tools, resolver APIs, marketplaces, and partner integrations across supported chains.

Material limitations and open questions

SPACE ID’s usefulness depends on network compatibility and third-party adoption. A readable name has limited value if wallets, exchanges, decentralized applications, or payment tools do not resolve it correctly. Multi-chain coverage also introduces operational complexity: users must distinguish domains by network and top-level domain, while developers must maintain integrations with the relevant SDKs, APIs, contracts, and chain endpoints.

The ID token has additional supply and governance risks. Scheduled releases can increase the tradable supply, while the token’s utility depends on actual fee discounts, staking participation, ecosystem payments, and governance activity. The project documentation also describes a revenue policy in which 50% of net platform revenue is intended for ID buybacks and burns and the remaining 50% for the DAO treasury. That is a stated governance and economic mechanism, not a guarantee of revenue, buybacks, burns, or token-value support; implementation should be checked against current governance records and on-chain transactions.

Key takeaways

• SPACE ID is a multi-chain Web3 naming platform covering discovery, registration, trading, management, and developer tooling.
• Its main user-facing assets are domain names such as .bnb, .arb, and .eth; ID is a separate ecosystem token.
• ID is documented for governance, staking-related discounts, and payments or SDK integrations.
• The governance design combines token voting with core-team execution and multi-signature treasury controls.
• The project’s expansion depends on wallet, application, chain, resolver, SDK, and API integrations.
• Supply unlocks, uncertain adoption, third-party dependencies, and the gap between planned and delivered infrastructure remain central evaluation points.

Risks and open questions

• The token allocation includes multiple categories with staged vesting, so future unlocks may affect circulating supply and market liquidity.
• The practical value of domains depends on continued support from wallets, applications, marketplaces, and other third-party integrations.
• The documented governance process does not give token holders direct execution control over every protocol or treasury action.
• The revenue buyback-and-burn policy is a project-documented mechanism, not an assurance that sufficient revenue or burns will occur.
• The scope of supported domains and chains may change, and API or SDK availability can create operational dependencies for developers.
• The project’s roadmap and promotional adoption statements should not be treated as independently verified usage or delivery evidence.