Bitcoin solved the problem of digital scarcity for money. It left open the question of how people identify themselves and each other without relying on companies that can freeze accounts or seize names. Spaces Protocol answers that question by giving users permanent, self-custodial handles anchored directly to Bitcoin. A name such as alice@bitcoin functions as a single pointer that can hold a Bitcoin address, a Lightning offer, a Nostr public key, social profiles, and other records. Anyone can look it up and verify the data against a root committed on the Bitcoin blockchain. No registrar sits between the owner and the name once the commitment is confirmed.
The protocol runs on mainnet today. Top-level spaces are distributed through open auctions that anyone can join. The video walkthrough shows the exact steps required to participate with a full node. Those steps are straightforward for anyone already familiar with Bitcoin Core, and they demonstrate that the system does not depend on a central service for its core operation.
Begin by installing Bitcoin Core from the official source and allowing it to sync fully. Configure RPC authentication in the bitcoin.conf file by setting an RPC user and an RPC password of your choice. Once the node is synchronized, install the Spaces daemon. The latest binary releases are available on the project GitHub. Version 4 or higher is required for mainnet; the current release is version 6. Verify the installation with the version commands for both the daemon and the command-line interface. The daemon is a lightweight process that connects to Bitcoin Core over RPC and watches only the transactions relevant to the protocol. It does not require a separate blockchain.
With the node ready, start the daemon and create a wallet. The create wallet command generates a default wallet. The get new address command returns a Bitcoin address that can receive funds. Send a small amount of Bitcoin to that address and confirm the balance. These coins cover the fees and any bids you place. All subsequent commands are issued through the same command-line interface.
Top-level spaces serve as community identifiers. The protocol limits the number that can be created to roughly 3,600 per year. Every day the ten highest-bid names advance from the pre-auction stage into an open auction. You can monitor currently open auctions on the public explorer. To propose a new name, use the open command followed by the desired label. A minimum of 1,000 satoshis places the name into the pre-auction queue. You may also attach a higher initial bid in the same transaction, though this carries risk. If another participant opens the same name with a higher bid in the same block, only one transaction confirms and the other loses the funds. A safer sequence is to open the name at the minimum amount, wait for confirmation, and then place a separate bid.
Bidding uses the bid command with the space name and the desired amount in satoshis. Each bid is a Bitcoin transaction, so two fees are paid if you open and bid separately. The bid covenant requires that the output be spent either by a higher bid or by a registration once the claim height is reached. You can check the status of any space with the get space command or list all spaces you control with the list spaces command. The explorer provides a convenient visual overview of active auctions and claim periods.
Registration occurs only when you hold the leading bid and the claim height has been reached. The register command finalizes ownership. Attempting to register early can push the auction forward by an additional day, so timing matters. Once registered, the space is controlled by the private key that holds the associated UTXO. No third party can seize it or alter its ownership record.
The design keeps the on-chain footprint small. Most data for individual handles lives off-chain inside a Merkle tree. Only a 32-byte root is written to Bitcoin. After the operator includes a handle in a commitment, the owner receives a certificate that proves inclusion. From that moment the handle cannot be revoked. The same root also serves as a trust anchor that wallets and applications can use to verify records without trusting a remote server. Clients that hold the trust anchor can confirm that a particular set of records matches the commitment on the blockchain.
This architecture delivers several practical advantages. A single handle can publish multiple payment destinations at once, so a sender can choose Bitcoin, Lightning, or another method without copying long addresses. Social and contact information can be updated at any time without changing the name itself. Because verification is anchored to Bitcoin, the system inherits the same security assumptions that Bitcoin users already accept for their funds. There are no annual renewal fees for the handles once issued, and no company can suspend the name.
For users who prefer not to run a full node, the Nacho application provides a mobile path to the same outcome. Keys are generated on the device, a name is selected, and a one-time payment is completed. The operator later includes the handle in a batch commitment. The user receives a certificate and retains control through the seed phrase and backup file. The on-chain cost remains low because many names share a single root commitment. Early participants benefit from wider name availability while the system is still in its growth phase.
The protocol also supports operators who want to run their own top-level space. After winning an auction, an operator can issue large numbers of handles underneath it. The operator commits roots periodically, and each recipient holds a certificate that proves ownership against that root. This model scales without requiring a transaction for every individual name. It also keeps the base layer free for settlement while everyday lookups and payments continue on Layer 2 systems or through direct verification.
Spaces Protocol does not ask users to abandon existing tools. It adds a Bitcoin-native name that can point to whatever records the owner chooses to publish. The name remains under the owner’s control, the proof is checkable against Bitcoin, and the records can be updated as needed. That combination removes the friction of long addresses while preserving the self-custody properties that Bitcoin users already expect. As more wallets and applications integrate resolution, the utility of a short, permanent name increases for both individuals and developers.
The quick-start process shown in the video makes the system accessible to anyone willing to run Bitcoin Core. The same principles of open auctions, burned bids, and non-revocable handles apply whether you participate through the command line or through a mobile application. In both cases the result is a name that lives on Bitcoin rather than on a company server. For anyone who currently shares long addresses or maintains separate profiles across different services, a Spaces handle offers a simpler and more durable alternative.
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/.
