Spaces Protocol
Category: White Paper
Status: Living Document
Updated: March 2026
M. Carson
Buffrr
Impervious
February 2024

White Paper

Spaces is a naming protocol that leverages the existing infrastructure and security of Bitcoin1 without requiring a new blockchain or any modifications to Bitcoin itself. "Spaces" serve as community identifiers that are distributed through an auction process built using existing Bitcoin scripting capabilities. Proceeds generated through auctions are irrevocably burned. Within each Space, users can create "Subspaces," which are sovereign, non-revocable identities bound to public keys. Subspaces operate primarily off-chain through compact certificates, but can be bound to UTXOs on-chain when interactive functionality is required. Spaces is designed to be verifiable by end-users in a trustless manner without requiring a full node. This is achieved through a stateless zero-knowledge light client, which produces a universal root of trust from Bitcoin's header chain. The protocol essentially acts as a scalable & trustless Bitcoin certificate authority.

BITCOIN BLOCK HEADER prev_block_hash merkle_root version timestamp difficulty ₿ TRANSACTIONS space tx space tx state transitions STATE ACCUMULATOR state_root 32 bytes 0x a3 f7 1b ... c9 02 FIG. 1 — BITCOIN BLOCK HEADER TO SPACES STATE

Background

Public Key Infrastructure (PKI) is a critical component of internet security, enabling secure communication and authentication between parties. However, traditional PKI systems often rely on centralized authorities, which can be vulnerable to attacks, censorship, and single points of failure. This has led to a growing interest in decentralized PKI solutions, particularly those built on blockchain technology. Over the past decade, various decentralized naming protocols have emerged to address this need. Namecoin3 pioneered this field in 2011 but fell short due to usability issues and a significant number of inactive or "squatted" domains4. The Ethereum Name Service (ENS)5 has become the most widely adopted naming system, primarily because most ENS users rely on trusted third parties for resolving .eth identities. However, this reliance on intermediaries undermines the decentralized nature of these names, and ENS lacks meaningful light client support.

The Handshake6 blockchain attempted to improve upon Namecoin's design by introducing an auction process for acquiring names. However, this approach has proven ineffective, as bots can open numerous auctions during a short time period and acquire valuable names unnoticed. Being a niche blockchain with limited utility, focusing on an alternate root to the existing DNS, Handshake faces substantial challenges. First, it fails to match the security found in well-established blockchains such as Bitcoin. In addition, name collisions further undermine its practicality, violating a crucial principle of URLs: uniqueness. This unique identification permits the unambiguous sharing of links and access to web resources. Inconsistent user configurations or name resolution preferences will affect even more subtle issues such as the loading of subresources on the web.

These innovations fall short of delivering the security attributes inherent to a robust Proof-of-Work blockchain such as Bitcoin. This paper seeks to address these shortcomings, proposing a highly secure, scalable and decentralized PKI anchored in Bitcoin.

Table of Contents

Name Syntax

bob @ bitcoin subspace individual identity separator space community identifier FIG. 2 — NAME SYNTAX

A "Space" acts as a community identifier in the Spaces protocol, similar to a top level domain like .com or .org on the traditional web. For instance, in the identity "bob@bitcoin", 'bob' represents a subspace or a member of the 'bitcoin' community.

Acquiring a Space

Pre-auctions priority queue rollout top 10 / day Auctions ~10 day window winning after SCP Registration Space UTXO created FIG. 3 — AUCTION PROCESS

The protocol uses an auction-based method for distributing names, rather than a first-come first-serve approach, aiming to prevent any single entity from accumulating a disproportionate number of valuable names. Since auctions alone cannot entirely eliminate the possibility of name squatting, and to further ensure fairness, the protocol introduces a dynamic name rollout process to control the release of names through a pre-auctions phase ensuring that each name gets adequate attention and the opportunity for fair & open public bidding.

Pre-auctions Phase

During the pre-auction phase, users propose names they're interested in. Names that receive enough interest, determined by their highest bid values, advance to the auction phase. The protocol caps the number of spaces released to 10 per day, or a total of 3600 community spaces per year.

Auctions Phase

When a pre-auctions Space advances to the top 10 on a given day, it enters the auctions phase. Auctions last for 10 days. To discourage last-minute bidding, new bids extends the auction duration by one day.

Auction Design

The basic principle behind the auction mechanism is selecting some UTXO to represent the Space (known as the "Space UTXO"). This UTXO is "passed" around by bidders until the auction concludes. An open transaction is first submitted to initiate the auction and place the initial bid.

A bid is made by burning the amount in an OP_RETURN output. In addition, the bidder also leaves a partially signed Bitcoin transaction (PSBT) that says, "If I'm outbid, the next person may consume my Space UTXO, as long as they give me my money back."

For instance, consider Bob as the initial bidder who commits 1 BTC. Alice comes along and decides to bid 1.5 BTC, she completes Bob's PSBT, which gives Bob his 1 BTC back, and she then burns an additional 0.5 BTC, increasing the total burned amount for the auction to 1.5 BTC. Alice shares her own UTXO and PSBT, representing the new leading bid for the Space UTXO. This pattern continues until the auction concludes.

To facilitate this process, some transaction with at least two UTXOs is necessary. One is used as the Space UTXO while the other is spent in the bid transaction. This makes it possible to "compress" the entire PSBT into a 65-byte format to fit within the OP_RETURN output, which is already being used to burn the bid amount.

INPUTS OUTPUTS #f9395e:2 Spend output from tx containing a Space UTXO OP_RETURN <bid amount> <cPSBT> 65-byte Compressed PSBT 6 1-byte locator .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. .. 64-byte signature FIG. 4 — BID PSBT STRUCTURE

To reconstruct a PSBT from its compressed form, the first step is to recover the Space UTXO outpoint, which includes a 32-byte transaction ID and an output index. The transaction ID can be obtained by identifying the input index that corresponds to the OP_RETURN output, as both should align index-wise. Since this input originates from the transaction that includes the Space UTXO, its transaction ID is used. Within the OP_RETURN data, the initial byte indicates the Space UTXO's output index. For instance, the Space UTXO in the referenced figure would be identified as outpoint #f9395e:6. The Space UTXO's locking script is used as the refund address and its value is added to the refunded bid amount. This PSBT is then used to construct the next bid transaction, continuing with this pattern until the auction concludes.

In scenarios where multiple bids are placed simultaneously on the same Space UTXO, only one bid will succeed in burning the coins. This is because other bids will attempt to spend a UTXO that has already been spent and their transaction will be rejected by Bitcoin full nodes. Similar techniques have been used in the past to implement Dutch auctions7, although they do not allow for arbitrary bids and may require a larger on-chain footprint to implement for this purpose.

Protocol-specific rules are enforced through a client-side consensus node. For example, spending the auctioned UTXO without following the auction pattern or attempting to register the Space before the safe closing period is technically possible, but it violates a protocol rule, which causes the auction to be invalidated. As a result, the offending bidder will lose their coins. Additionally, it's important to open auctions with zero or low initial bids. If two auctions for the same name open simultaneously, only the first auction will be recognized.

Finalizing an Auction

Auctions continue indefinitely until a winning bidder chooses to conclude the process once the Safe Closing Period (SCP) begins. The SCP begins following a predetermined timeframe, approximately 10 days, once a Space transitions from the pre-auctions pool to the active auctions phase.

Spaces start in a pre-auctions pool, awaiting interest from potential bidders. This pool functions as a priority queue; Spaces ascend within this queue as their bids increase. Every 144 blocks, roughly equivalent to one day, the top 10 Spaces in this queue are moved into the auctions phase.

Assuming a Space enters the auctions phase at block N, the auction then spans 1440 blocks from this point, with the SCP set to start at N+1440. This creates a window during which bids can be placed and extended. If a bid is placed towards the end of the auction, specifically on the 10th day or later, it extends the SCP by an additional 144 blocks from the bid's block.

To finalize an auction, the winning bidder must actively end it, once the SCP begins. This closure is done by creating a transaction that spends the last Space UTXO, signaling the end of the auction and establishing the bidder as the new owner of the Space. If the winning bidder does not conclude the auction, the Space remains unregistered and open to new bids. Ending the auction before the SCP starts will invalidate it, resulting in the bidder losing their coins.

Space UTXOs

After an auction is finalized, the Space is represented as a Bitcoin UTXO. Space UTXOs can hold any value, just like regular Bitcoin UTXOs. Moreover, any coin a user might already possess can be converted or "marked" as the Space's UTXO. They're similar in principle to Colored Coins8 except they're indistinguishable from standard UTXOs. They can be used for payment in Bitcoin transactions, and returned as change. Space UTXOs do not necessarily expand Bitcoin's UTXO set size more than a normal UTXO used to hold value would. The protocol encourages their use in transactions, serving a dual purpose: it facilitates regular Bitcoin transactions and simultaneously renews the Space's registration, thereby preventing its expiration.

There's one rule when it comes to transacting with Space UTXOs. If a Space UTXO is used as an input at a certain index within a transaction, the corresponding output or change, i.e. — the new Space UTXO must be placed at the next sequential index. For instance, if the Space UTXO is at input index 2, then the new UTXO must be at output index 3. This facilitates trustless and non-interactive resale of Spaces in secondary marketplaces by creating a PSBT with signature type SINGLE|ANYONECANPAY using the Space as the input and the required payment is set as the output.

Transaction INPUTS OUTPUTS idx 0 ... idx 1 idx 1 ... idx 2 ... ... Space UTXO 1 Space UTXO 2 Space UTXO 1 Space UTXO 2 idx+1 idx+1 FIG. 5 — SPACE UTXO TRANSACTION MOVEMENT

To ensure active utilization of Spaces and prevent valuable names from getting lost, the protocol requires renewals to ensure that a Space's owner is still in control of their UTXO.

Subspaces

Subspaces are human-readable names bound to unique script pubkeys (standard Bitcoin locking scripts), issued by Space operators off-chain. Once issued, a subspace binding is sovereign and non-revocable — it functions indefinitely without requiring any on-chain operation or renewal. Subspaces are organized into a Binary Merkle Trie, and the root of this tree is committed on-chain by the Space's operator as a compact 32-byte hash. The core client accepts these commitments without examining their internal structure; cryptographic validity is verified off-chain by certificate verifiers. When interactive functionality is needed — such as key rotation or atomic swaps — subspaces can be bound to UTXOs on-chain with minimal footprint.

r1 alice@bitcoin <script_pubkey> charlie@bitcoin <script_pubkey> dennis@bitcoin <script_pubkey> FIG. 6 — SUBSPACES MERKLE TRIE

State Commitments

A commitment is a 32-byte Merkle tree root representing the state of all subspaces for a given Space at a given block height. The operator constructs a Binary Merkle Trie containing all subspace mappings (name -> script_pubkey) and submits the tree root on-chain.

State transitions are append-only. New subspaces are added to the tree, producing a new root. Existing bindings are never modified or removed. Consider a sequence of commitments R = (r1, r2, ..., rN). Each successive commitment extends the previous state with new additions. The protocol requires that new additions did not previously exist in any prior commitment — this is what prevents double-issuance.

Example structure of a commitment entry in the tree:

struct Commitment {
  state_root: [u8; 32],
  prev_root: Option<[u8; 32]>,
  rolling_hash: [u8; 32],
  block_height: u32
}

Each commitment maintains a constant 32-byte on-chain footprint regardless of the number of subspaces being issued. The core client accepts commitments into the chain of roots without examining their internal structure or cryptographic validity. It is the responsibility of certificate verifiers to check the validity of commitments off-chain. Submitting an invalid commitment breaks the cryptographic chain of proofs, permanently disabling the Space's ability to issue new subspaces — the chain cannot be repaired since subsequent commitments cannot provide valid non-existence proofs.

An entity responsible for administering a Space is known as the 'Operator'. Operators manage subspace issuance and submit commitment roots on-chain.

Certificates

Subspace owners hold a Certificate — a cryptographic proof of ownership that functions entirely off-chain. Once issued, a certificate is valid indefinitely without requiring renewal or any on-chain interaction. A certificate must include:

  • An inclusion proof demonstrating the handle exists in the committed Merkle tree.
  • A non-existence proof showing the handle was not present in any previous commitment, preventing double-issuance.

Non-existence can be proved via explicit exclusion proofs against each prior commitment. While correct, these proofs grow in size with each new commitment, becoming increasingly verbose over time. To keep certificates compact, recursive zk-SNARK or STARK proofs can compress the full chain of non-existence checks into a single succinct proof — essentially validating a rolling hash across all commitments without double-spends. Both approaches are valid; certificate verifiers can be implemented to support either proof type independently of the core client.

UTXO Binding

The majority of subspace users should rely entirely on off-chain certificates without ever needing any on-chain interaction. UTXO binding is reserved for cases requiring interactive functionality such as key rotation or atomic swaps.

A UTXO binding is created by constructing a transaction that spends to the subspace's unique script_pubkey. Because each subspace is bound to a distinct script_pubkey, no additional metadata or explicit handle name is needed on-chain — the UTXO itself is the binding. Multiple subspaces can be bound in a single transaction to reduce on-chain costs.

UTXO BINDING TRANSACTION INPUTS Funding inputs ... OUTPUTS vout 0 script_pubkey_1 alice vout 1 script_pubkey_3 dennis vout 2 script_pubkey_5 satoshi No additional metadata needed — identified by script_pubkey FIG. — UTXO BINDING TRANSACTION

Creating a UTXO binding nullifies the off-chain certificate and initiates an on-chain lifecycle for the subspace. The original certificate remains necessary as the genesis proof and must be referenced off-chain to establish the link between the handle name and the on-chain UTXO.

Loss of Liveness

When a Space operator becomes unavailable and stops submitting commitments, existing subspace holders remain unaffected — their certificates provide complete ownership proof independent of the operator. Certificates continue to function indefinitely regardless of operator status.

If the parent Space expires and is reacquired by a new owner, the new operator must prove that any proposed names did not previously exist, which requires access to the complete subspace tree. If the tree is unavailable, the Space permanently loses the ability to issue new subspaces. Existing subspaces continue to function regardless of operator changes or tree availability.

Operators

Operators are the owners of top-level Spaces who manage subspace issuance. Their primary responsibility is maintaining the subspace tree and submitting commitment roots on-chain. Each commitment is a compact 32-byte hash regardless of the number of subspaces issued.

Operators are not trusted with the security of existing subspaces — once a certificate is issued, it functions independently. However, operators bear permanent responsibility for the integrity of their commitment chain: submitting an invalid commitment irreversibly breaks the ability to issue new subspaces.

Accumulators

Spaces implements dynamic hash-based accumulators, similar in function to Utreexo9, to summarize the protocol's entire state using two roots: spaces_root and nums_root.

  • spaces_root represents the root hash of the spaces tree, keeping track of top-level spaces, their auction state, bid ordering, and ownership in a binary trie structure.
  • nums_root stores UTXO bindings for subspaces and commitment roots for various spaces in a binary trie structure.
state_root Binary Tries spaces_root ... ... @bitcoin owner: <pubkey> Space @nostr bid: 0.5 BTC Pre-auction (sorted by bid) nums_root ... ... @bitcoin ‖ root-1 commitment alice@bitcoin UTXO binding OFF-CHAIN TREES r1 ... ... alice@bitcoin <script_pubkey> charlie@bitcoin <script_pubkey> FIG. 7 — PROTOCOL STATE OVERVIEW

Binary Trie

The protocol is designed to work with zero-knowledge light clients and as a result it necessitates a universal accumulator to support membership and non-membership proofs for batches of elements. To achieve this, we implement a binary trie known as a Merklix10 tree. Various Trie structures have been used in blockchains in the past. For instance, Ethereum11 currently uses a base-16 trie and have been exploring the transition to a binary trie12. Handshake6 uses some variation of a binary trie with its tree root included in the block header. Spaces does not require modifications to Bitcoin's block header itself but it can accumulate name data into a state root in a verifiable way using zero-knowledge proofs.

The individual bits of the keys are used to route the leaf nodes to their appropriate paths. A trie offers simplicity over a Sparse Merkle Tree, as the latter necessitates dealing with empty leaves. The tree has only two types of nodes: An internal node, potentially containing a prefix for path compression, and a leaf node. Considering keys are hashed prior to insertion, they consistently have a fixed length. The overall depth of the tree is therefore determined by the number of bits produced by the hash function.

root 0 1 00 01 10 11 Compressed path 010100 0 000 001 100 101 1100 1101 000110 001101 100010 101111 110011 110110 FIG. 8 — BINARY TRIE WITH 7 LEAF NODES

Sub Trees

It is possible to prove both the existence and non-existence of single or multiple keys by extracting a portion of the larger tree whilst concealing the branches of irrelevant nodes. For instance, consider the figure above demonstrating the larger tree. If we want to prove the existence of keys 000110 and 010100 and additionally prove the non-existence of keys 0111001 and 000111, we can selectively carve out a specific subtree. Importantly, this subtree still hashes to the same tree root as the larger tree.

root 0 1 hash node 00 01 010100 000 001 000110 hash node FIG. 9 — SUBTREE EXTRACTION

The above subtree includes the leaves we're interested in and also proves the non-existence of 0111001 and 000111 (or any keys with prefixes that traverse exposed paths). It's important to note that we lack the necessary information to make conclusive statements about keys starting with 1 or 001 as these paths need to be revealed.

Similarly, we can execute operations on the subtree just as we do the larger tree. For insertions, we can only insert into the revealed paths and we can also update the values of existing keys.

A significant advantage of this structure is its capacity to function as an accumulator. We can make modifications by working primarily with small subtrees, while only keeping track of a single tree root to represent the accumulator state, not an entire database.

Light Clients

A zero-knowledge light client needs to perform two main tasks: verify Bitcoin's header chain, similar to the header chain proof by ZeroSync13, and enforce protocol-specific rules to produce a compact state header in its public outputs. This state header encapsulates the entire state of the protocol and serves as a universal root of trust — a root certificate from which all Space and subspace certificates can be verified without requiring access to a Bitcoin full node.

For instance, verifying a Space requires checking an inclusion proof against the spaces_root in the state header. For subspaces, a client checks an inclusion proof against the nums_root to verify that the subspace's commitment chain is anchored in the protocol state. Certificate-level proofs (inclusion and non-existence) are verified off-chain by certificate verifiers, not by the light client itself. The light client produces the trust anchor; certificate verifiers use it.

Record Storage

The core functionality of the Spaces protocol is centered around its role as a certificate authority, as it does not inherently provide a mechanism for storing records on-chain. This design choice keeps the protocol streamlined and focused on its primary task of securely managing and verifying digital spaces and identities within the Bitcoin network.

The trustless nature of the protocol makes it an ideal foundation for developing a Peer-to-Peer (P2P) protocol that uses Spaces as a trust anchor to support record storage and other use cases entirely off-chain. Additionally, integrating Spaces with various other protocols such as Nostr14 is relatively straightforward.

References

  1. Bitcoin: A Peer-to-Peer Electronic Cash System — bitcoin.org/bitcoin.pdf
  2. (Reserved)
  3. Namecoin — namecoin.org/resources/whitepaper
  4. An Empirical Study of Namecoin — cs.princeton.edu/~arvindn/publications/namespaces.pdf
  5. Ethereum Name Service (EIP-137) — eips.ethereum.org/EIPS/eip-137
  6. Handshake — handshake.org/files/handshake.txt
  7. Summa Auction — medium.com/summa-technology/summa-auction-bitcoin-technical
  8. Colored Coins — en.wikipedia.org/wiki/Colored_Coins
  9. Utreexo — eprint.iacr.org/2019/611.pdf
  10. Merklix Tree — blog.vermorel.com/pdf/merklix-tree-for-bitcoin-2018-07.pdf
  11. Ethereum Patricia Merkle Trie — ethereum.org/.../patricia-merkle-trie
  12. Binary Trie (EIP-3102) — eips.ethereum.org/EIPS/eip-3102
  13. ZeroSync — zerosync.org/demo
  14. Nostr — en.wikipedia.org/wiki/Nostr
Document
Spaces Protocol
Author
M. Carson / Buffrr
Revision
Feb 2024 · Updated Mar 2026