Jameson Lopp has described Bitcoin as a database whose protocol defines how users buy space and make updates. In a free-market view, any use case that fits within those constraints and is paid for at the prevailing market rate is legitimate. The Spaces Protocol applies that principle to naming. It allocates short, human-readable identifiers through open auctions on Bitcoin, burns the bids, and anchors ownership so that no single party can revoke a claimed name after the fact.
Lopp’s framing treats block space as a scarce resource priced by willingness to pay. Users who want to store data, open a channel, or register a name compete for the same limited capacity. The protocol itself does not rank uses. It only enforces the rules that keep the chain consistent and the supply of new coins fixed. Under that standard, a naming system that consumes modest on-chain data, settles through ordinary transactions, and leaves verification possible for anyone who follows the chain is simply another buyer of block space. Spaces meets those conditions. Top-level names are assigned by auction. The winning bid is burned. Subsequent handles under a claimed space are recorded off-chain in a Merkle tree whose root is committed to Bitcoin as a 32-byte hash. The resulting certificate proves inclusion and prior non-existence. Once the commitment confirms, the handle cannot be reassigned by the operator or by any third party.
This design keeps the on-chain footprint small. Many handles share a single root commitment. The cost of securing a name is therefore limited to the auction bid and the occasional root update rather than a full on-chain record for every identifier. Users who prefer can still move a handle onto a UTXO for fully on-chain control. The choice remains with the owner. The protocol does not require a soft fork or a new consensus rule. It interprets existing transaction patterns and signaling. Anyone who can broadcast a Bitcoin transaction can participate in an auction. Anyone who can verify a Merkle proof against a Bitcoin-anchored root can confirm ownership without trusting a remote server for the final check.
The free-market test Lopp outlines is therefore satisfied. The use case stays inside the protocol constraints. Participants pay the market rate for the space they consume. The system does not rely on a privileged intermediary that can override the chain. Ownership of a claimed space rests with the private key that controls the associated UTXO. Ownership of a handle rests with the key that controls the certificate after the root has been committed. Neither can be seized by a registrar, a platform, or an operator once those conditions are met.
Practical consequences follow. A merchant can publish a stable handle on a sign or a receipt. Customers resolve the handle in a compatible client 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 check the certificate 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 annual issuance of top-level spaces is capped at roughly 3,600. Up to ten advance each day from a priority queue ordered by bid amount. The claim window lasts about 1,440 blocks. The highest bidder at the close controls the space. Because the supply is fixed and the allocation is open, short and memorable labels clear first. Later participants face higher bids or choose from longer names that remain available. The same auction rules continue regardless of demand. The protocol does not expand the daily or annual limit. It simply continues to allocate the remaining inventory, burn the bids, and record the winners on Bitcoin.
Secondary markets have begun to appear. Owners who prefer to sell an already-claimed space can list it for transfer. Different price bands form around length and category. One- and two-character names already command higher bids in primary auctions. Longer memorable strings form their own floors once primary supply tightens. Both primary auctions and secondary transfers end with control of a name whose proof can be verified against Bitcoin. The marketplace does not alter the underlying scarcity or the non-revocable character of a confirmed claim.
For developers, integration is straightforward. A client can resolve a handle, verify the certificate against the committed root, and return the published records. Those records can include Bitcoin addresses, silent payment addresses, Lightning offers, Nostr public keys, or other data the owner chooses to attach. Updates to the records do not require a new on-chain transaction for the name itself. The name stays constant while the data behind it changes. This separation reduces the ongoing cost of maintaining a useful identifier and keeps the chain free of unnecessary data.
The combination of open auction allocation, burned proceeds, off-chain handle issuance, and Bitcoin-anchored commitments produces a naming system that is scarce, non-revocable after claim, and verifiable without a trusted resolver. It fits the free-market standard Lopp described: a use case that stays within protocol constraints and is paid for at market rate. As more wallets and applications add support, the same short name becomes usable across a larger set of services while remaining under the exclusive control of the owner’s keys. The scarcity of top-level spaces and the permanence of issued handles create a clear incentive for early participation. The mechanics remain the same whether the registered total is low or high. The protocol continues to allocate names through open bidding and records the results 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/, explore the marketplace at https://spaces.market/, or get a handle through the Nacho app at https://nacho.io/.
