Spaces Protocol provides human-readable names that replace long alphanumeric Bitcoin addresses. A user who owns a name can publish a Bitcoin address, a silent payment address, a Lightning offer, or any other payment records behind that name. Senders resolve the name and receive the current payment instruction without copying a long string. The same name can also serve as a Nostr username. Once the name is registered, the owner controls the records that appear when the name is looked up. The records can be updated later without changing the name itself.
Registration occurs through open auctions on the Bitcoin blockchain. The highest bidder at the close of the auction window becomes the owner of the top-level space. Bids are burned, so no central party retains the proceeds. The protocol limits new top-level spaces to roughly 3,600 per year, with up to ten advancing each day based on bid amount. After the claim period ends, the winning bidder controls the associated UTXO. That control can later be used to issue handles underneath the space. Handles such as alice@bitcoin are recorded in a Merkle tree. The operator commits the root of the tree to Bitcoin as a 32-byte hash. Each handle owner then receives a certificate that proves inclusion and prior non-existence. After the commitment confirms, the handle cannot be revoked by the operator or by any third party.
Verification of ownership does not require trust in a remote server for the final proof. A client can check the certificate against the Bitcoin-anchored root. The design keeps most data off-chain while anchoring the commitment to Bitcoin’s proof of work. The on-chain footprint remains small because many handles share a single root. Handles do not expire and do not require annual renewal fees. Ownership rests with the private key that controls the certificate or the associated UTXO.
The protocol also supports the publication of records that point to content. A name can resolve to the location of a site or other data that is stored in a decentralized network rather than on a single server controlled by one operator. Traditional websites can be taken offline by the entity that operates the server or by an authority that directs that entity. Content referenced through a Spaces name remains reachable as long as the underlying network continues to host it and the name continues to resolve. The name itself is protected by the same Bitcoin security that secures ordinary transactions. No single party can seize the name once the claim has confirmed and the keys remain under the owner’s control.
Security follows from the underlying chain. Name registrations and root commitments are ordinary Bitcoin transactions. They inherit the same resistance to reversal that applies to any confirmed Bitcoin transfer. The cryptographic rules that prevent double-spending also prevent unauthorized reassignment of a claimed space. Users who verify the certificate against the committed root do not need to trust an intermediary for the final check. This removes the single point of failure that exists when a centralized registrar controls both the name and the resolution path.
The open-source nature of the project allows any developer to inspect the code, propose changes, or build additional clients. Contributions do not require permission from a foundation or company. The protocol itself does not rely on a token or a separate blockchain. Bitcoin is the settlement layer, and the naming rules are enforced by interpreting existing transaction patterns. Anyone who can submit a Bitcoin transaction can participate in an auction. Anyone who can verify a Merkle proof can confirm a handle. These properties keep the system open to new participants without requiring coordination with a central authority.
Compared with traditional domain systems, Spaces removes the registrar that can suspend a name for policy reasons. Compared with earlier Bitcoin naming attempts, it avoids placing large amounts of data directly on-chain and avoids dependence on soft forks that have not activated. The combination of auction-based allocation, burned bids, off-chain handle issuance, and Bitcoin-anchored commitments produces a system in which short names are scarce, ownership is non-revocable after claim, and verification is possible without a trusted resolver.
For everyday use, the practical result is a single stable identifier. A merchant can publish a Spaces handle on a sign or a receipt. Customers resolve the handle in a compatible wallet and receive the current Bitcoin or Lightning address. The merchant can rotate the underlying address later without reprinting materials. A user can share the same handle across payment apps, Nostr clients, and other services. Lookups that verify against the trust anchor derived from Bitcoin do not route the final proof through a company server. The name remains under the owner’s keys even if the original application or operator disappears.
The protocol launched on mainnet on November 20, 2024. Since then, auctions have continued, handles have been issued under the first production operators, and documentation and client software have been released. The explorer shows open auctions, claim windows, and registered spaces. A mobile application generates keys on the device, submits a name to an operator, and later receives the certificate after the root is committed. Full-node users can run the client, bid on spaces, and verify the entire state against Bitcoin. Both paths end with control of a name whose ownership proof can be checked by any party that follows the protocol rules.
Adoption depends on continued integration by wallets and applications. Each new resolver that accepts a Spaces handle increases the number of places where a short name can be used instead of a long address. Each new auction that clears a desirable name reduces the remaining supply of short labels. The fixed annual issuance rate means that early participants secure names while availability is higher. Later participants compete for the remaining supply or purchase existing spaces on secondary markets. The underlying mechanics remain the same: open bidding, burned proceeds, non-revocable ownership, and verifiable commitments on Bitcoin.
The combination of human-readable names, Bitcoin security, and the ability to update records without changing the name addresses a long-standing friction in Bitcoin. Users no longer need to share or verify long strings for routine payments. Developers can resolve names in a few lines of code and verify the result against a Bitcoin-anchored root. Merchants can publish a stable identifier that continues to work when addresses change. These properties are available today through the existing clients and documentation. As more applications add support, the same name becomes useful across a larger set of services while remaining under the owner’s exclusive control.
Ready to claim a sovereign name on Bitcoin?
Visit https://spacesprotocol.org/ to learn more, check the explorer at https://explorer.spacesprotocol.org/, review the documentation at https://docs.spacesprotocol.org/, or get a handle through the Nacho app at https://nacho.io/.
