In a February 2025 clip from the TFTC podcast, Marty Bent and Ian Carroll examine the rising pressure for digital identity systems. They note that some form of digital identification is likely to become necessary, particularly at borders, yet they warn that poorly designed solutions can create long-term mechanisms of control. The conversation returns repeatedly to a simple distinction: an identity should belong to the individual who holds it. “An identity is very personal,” one speaker observes. “I am me and you can’t tell me that I’m not who I am. This is my identity. I own it.” The preferred frame, they argue, is that people create their own credentials rather than receiving them from a government or corporation. Protocols that support pseudonymous or self-sovereign identity, they suggest, offer a path that avoids the slippery slope into centralized authority.
Spaces Protocol supplies a concrete Bitcoin-native implementation of that frame. A space is a human-readable name, such as @bitcoin, acquired through an open auction conducted entirely on the Bitcoin blockchain. The winning bid is burned. The resulting space is represented by a Bitcoin UTXO controlled solely by the owner’s private keys. From that space the owner can issue handles, for example alice@bitcoin. Those handles are organized into a Merkle tree whose 32-byte root is committed on-chain. Once the root is on Bitcoin, each handle becomes non-revocable. The person who possesses the corresponding private key controls the handle. No registrar, foundation, or government retains the power to reassign or revoke it.
This architecture directly addresses the ownership concern raised in the TFTC discussion. Traditional digital identity systems typically issue credentials from a central issuer. The issuer can later modify, suspend, or cancel the credential. Spaces reverses the relationship. The protocol does not issue an identity to a user. A user acquires a top-level space through competitive bidding on Bitcoin, then issues handles under that space. After the root commitment, control rests exclusively with the key holder. Verification of any claim made with the handle can be checked against the Bitcoin anchor without relying on a third-party database that an authority could alter.
Protocol Rules That Enforce Ownership
Top-level spaces are released at a controlled rate of at most ten per day, or roughly 3,600 per year. Anyone may open a pre-auction by placing an initial bid. The highest-bid proposals advance daily into a formal auction window lasting approximately ten days. Last-minute bids extend the window by one day. The highest bidder at the close may claim the space, which is then bound to a Bitcoin UTXO. Because the auction proceeds are burned rather than paid to any operator, no entity extracts rent from the namespace itself.
Handles issued under a registered space follow a different permanence rule. They do not expire. The Merkle-tree root commitment records their existence and binding on Bitcoin. Subsequent updates can add new handles, but existing ones cannot be unilaterally removed by the space operator. This separation between the renewable top-level space and the permanent handles mirrors the distinction the TFTC speakers draw between an identity that is granted and one that is owned. The space owner controls issuance policy for new handles, yet loses the ability to reclaim handles once they have been committed.
On-chain footprint remains minimal. Only the 32-byte root and occasional updates appear on Bitcoin. Millions of handles can theoretically exist under a single space while the blockchain stores only the cryptographic commitment. Resolution of a handle can return a Bitcoin address, a Lightning invoice, a Nostr public key, a website, or other records. All of these records are published under the authority of the handle’s key. Applications that support Spaces can therefore treat the handle as a stable, user-controlled identifier without maintaining their own account databases that a platform could freeze.
Relation to the Framing Problem Discussed on TFTC
The TFTC conversation emphasizes that the battle over digital identity is partly a battle over framing. If the default assumption is that governments or large platforms must issue credentials, then every subsequent system inherits that centralization. If the default assumption is that individuals create and control their own identifiers, then the technical design follows. Spaces adopts the second assumption at the protocol level. There is no issuer key that can override an owner’s keys. There is no administrative interface that can transfer a handle without the owner’s signature. The only way a handle changes hands is if the owner deliberately transfers the controlling key.
This property aligns with the pseudonymous model the speakers describe as preferable to mandatory real-name systems. A Spaces handle need not be linked to a legal name, address, or government identifier. It can function as a persistent online identity for payments, social profiles, and application logins while remaining under the sole control of its key holder. At the same time, nothing prevents an owner from voluntarily attaching stronger attestations if a particular context requires them. The choice remains with the individual rather than with a central authority that could later expand the requirements.
The same ownership model also limits the long-term control risks the speakers identify. Because verification is performed against Bitcoin rather than against a mutable registry, an application or service cannot unilaterally invalidate a handle by updating a central database. Revocation would require the key holder to stop using the handle or to transfer it. In environments where platforms have previously suspended accounts or altered display names, a Spaces handle continues to resolve according to the rules recorded on Bitcoin.
Practical Utility of an Owned Identity
Once a handle is committed, its owner can publish records that applications read directly. A wallet can resolve alice@bitcoin to a payment address without the user copying a long string. A Nostr client can display the handle alongside an npub. A website or peer-to-peer application can use the handle as a login identifier. In each case the underlying control remains with the private key. The February 2025 video’s description explicitly positions Spaces as one available response to the digital-identity pressures under discussion: a system in which the identity is created and held by the user rather than issued by an external party.
Current explorer data illustrate that the system is already in active use. Several thousand top-level spaces have been registered. Live auctions continue for additional names, with bids and burn totals visible on-chain. Handles have been issued under spaces such as @bitcoin and others. These handles are available for use today in supporting applications. The annual supply constraint of roughly 3,600 new top-level spaces ensures that the namespace cannot be flooded, while the open auction process allows any participant to compete for a desired name.
Comparison with Issuer-Based Systems
Most existing digital-identity proposals rely on an issuer that attests to attributes and can later revoke the attestation. The TFTC speakers express concern that such designs, even when introduced for limited purposes such as border control, can expand over successive iterations. Spaces does not rely on an issuer for the existence or control of the handle itself. The handle’s validity is established by the Bitcoin commitment and the owner’s key. Optional attestations can be added later, but they are not required for the handle to function as an identifier. This separation keeps the core identity under user control even if external parties later attempt to impose additional requirements.
The protocol’s design choices therefore match the ownership frame articulated in the discussion. Identity is not granted by an authority that retains residual power. It is acquired through a transparent, competitive process on Bitcoin and thereafter controlled exclusively by the holder’s keys. Handles, once committed, do not expire and cannot be reassigned without the owner’s participation. Verification occurs against the chain rather than against a database an intermediary can modify.
The concerns raised by Marty Bent and Ian Carroll about digital identity are substantive. Centralized issuance creates residual control that can be exercised later. Spaces Protocol implements an alternative in which the user acquires and holds the identifier. The rules that enforce this outcome, the daily rollout limit, the burn of auction bids, the UTXO representation of a space, and the non-revocable commitment of handles, are all specified and verifiable on Bitcoin. For participants who share the preference for identities that individuals actually own, the protocol supplies a working mechanism today.
