Single-Use Seal

What Is a Single-Use Seal?

A single-use seal is an abstract cryptographic primitive, first proposed by Peter Todd, that prevents double-spending by guaranteeing an object can be "closed" over a message only once. The concept is inspired by physical tamper-evident seals used on shipping containers: once a seal is broken, it cannot be resealed, and anyone inspecting the container can tell whether it has been opened.

In the digital world, a single-use seal serves a similar purpose. It is a unique identifier that someone can close over a specific piece of data (a "message"). Once closed, the seal produces a witness that proves what message it was closed over. The critical security property is that no attacker can produce valid witnesses for two different messages on the same seal. This makes single-use seals a foundational building block for preventing double-spends in digital asset systems.

While the concept is abstract, its most important concrete implementation uses Bitcoin's UTXO model: a transaction output that can be spent exactly once, with the spending transaction serving as proof that the seal was closed.

How It Works

A single-use seal defines two core operations that any implementation must provide:

The Two Operations

The formal definition is minimal. A seal system needs only two functions:

Close(seal, message) → witness
  Close the seal over a message, producing a witness.

Verify(seal, witness, message) → true/false
  Check whether the seal was closed over the given message.

The security guarantee is straightforward: it must be impossible for an attacker to make Verify return true for two distinct messages when applied to the same seal. In other words, a seal can be closed exactly once, over exactly one message. Multiple witnesses for the same seal-message pair are acceptable (different proofs of the same fact), but witnesses for different messages on the same seal are not.

This property cannot be enforced by mathematics alone. It requires a consensus mechanism (like Bitcoin's proof of work) or a trusted authority to determine which closing is the valid one. Todd described single-use seals as analogous to a public key that can only be signed with once: the cryptography constrains what can happen, but a consensus layer enforces that it happens only once.

Bitcoin UTXOs as Single-Use Seals

Bitcoin's UTXO model provides the most widely used implementation of single-use seals. Each UTXO is globally unique, identified by its transaction ID and output index (the outpoint). Bitcoin consensus rules guarantee that a UTXO can only be spent once: any attempt to spend it a second time is rejected by every node on the network.

This maps directly onto the seal abstraction:

• The seal is a specific UTXO, identified by its outpoint (txid:vout)
• Closing the seal means spending that UTXO in a transaction that commits to a message (typically via a Taproot commitment or OP_RETURN output)
• The witness is the spending transaction itself, which proves on-chain that the seal was closed
• Verification means checking that the UTXO was spent and that the spending transaction contains the expected commitment

Because Bitcoin's consensus already prevents double-spending of UTXOs, single-use seals built on Bitcoin inherit the full security of the Bitcoin network without requiring any protocol changes or soft forks.

Commitment Schemes

When closing a seal, the message must be embedded into the spending transaction. Two primary methods are used:

• Tapret (Taproot commitment): the message hash is placed inside a Taproot script tree leaf. This is invisible to outside observers because the commitment is hidden within the Taproot structure unless the specific script path is revealed.
• Opret (OP_RETURN commitment): the message hash is placed in an OP_RETURN output. This is simpler but slightly less private, as the OP_RETURN data is visible on-chain (though its meaning remains opaque without the off-chain context).

In both cases, the Bitcoin transaction itself adds no data beyond what a normal transaction would contain (in the Tapret case) or only a small hash (in the Opret case). The actual contract state, asset details, and transfer logic all remain off-chain.

Role in Client-Side Validation

Single-use seals are the core anti-double-spend mechanism within client-side validation protocols. In these systems, contract state and transaction history are stored off-chain by the participants rather than published to the blockchain. When receiving an asset transfer, the recipient validates the entire history of the asset by checking each previous transfer against the Bitcoin blockchain.

The validation process works as follows:

1. The sender provides the recipient with the full chain of prior state transitions for the asset, including the seal (UTXO) used at each step
2. The recipient checks that each seal was closed exactly once by verifying the corresponding Bitcoin transaction exists and was confirmed
3. The recipient checks that no seal was closed over conflicting messages (no double-spend occurred)
4. If all checks pass, the recipient accepts the transfer and takes ownership of the new seal (the UTXO that will anchor the next transfer)

This model separates validation from consensus. Bitcoin provides the single-use guarantee (a UTXO can only be spent once), while the parties involved validate the contract logic themselves. The result is a system that scales independently of Bitcoin's block size because no contract data appears on-chain. For a deeper explanation, see the research article on how client-side validation scales Bitcoin.

Use Cases

Token Issuance and Transfer

The RGB protocol uses single-use seals to issue and transfer tokens on Bitcoin. Each token state is anchored to a UTXO. Transferring the token means closing the seal on the current UTXO and opening a new seal on the recipient's UTXO. The entire history of the token, from issuance to the current holder, forms a chain of sealed state transitions that anyone can verify against the Bitcoin blockchain. See the RGB protocol deep dive for technical details.

Smart Contracts on Bitcoin

Single-use seals extend beyond simple token transfers. By attaching contract schemas to sealed state transitions, protocols like RGB enable general-purpose smart contract logic on Bitcoin. Each state transition can enforce rules (spending conditions, access control, voting thresholds) that are validated client-side rather than by miners. This brings programmable asset logic to Bitcoin without modifying Bitcoin Script or requiring soft forks.

Statechain Transfers

Statechains use a related concept: the ownership of a UTXO is transferred off-chain by passing signing authority rather than spending the UTXO on-chain. The UTXO itself acts as a single-use seal for the current ownership state. When the owner wants to settle on-chain, they spend the UTXO (close the seal), proving the final state of ownership. This approach enables instant, fee-free transfers of whole UTXOs without on-chain transactions.

Scalable Asset Systems

Because single-use seals keep all asset logic off-chain, thousands of asset operations can share a single Bitcoin transaction. A Taproot commitment can anchor a Merkle tree of many contract state transitions in a single output. This means the system scales with the number of Bitcoin transactions (which serve as anchors), not with the number of asset operations. The blockchain sees only normal Bitcoin transactions, with no visible difference between a standard payment and a transaction anchoring thousands of RGB state transitions.

Why It Matters

Single-use seals solve a fundamental challenge in building token and contract systems on Bitcoin: how to prevent double-spending of off-chain assets without bloating the blockchain. Before this primitive, approaches to issuing assets on Bitcoin (such as colored coins) typically required publishing all asset data on-chain, consuming scarce block space and reducing privacy.

By using Bitcoin UTXOs as tamper-evident seals, protocols can anchor asset state to Bitcoin's security model while keeping the actual data off-chain. This unlocks the ability to build complex financial instruments, token ecosystems, and smart contracts on top of Bitcoin with minimal on-chain footprint. For Bitcoin layer 2 systems like Spark, single-use seals represent one of several approaches to scaling Bitcoin's capabilities beyond simple value transfer.

Risks and Considerations

History Verification Burden

In client-side validation, recipients must verify the full history of an asset. For tokens that have been transferred many times, this history can grow large. Each transfer adds another seal closing that needs to be checked against the Bitcoin blockchain. Long-lived, frequently traded assets accumulate increasingly heavy proofs over time.

Data Availability

Because contract state lives off-chain, losing that data means losing the ability to prove ownership. If a sender fails to transmit the full state history, or if a recipient loses their local copy, the asset becomes unspendable. There is no on-chain fallback to recover the state. Reliable backup and data transmission infrastructure are essential.

Trust in the Seal Medium

The security of single-use seals depends entirely on the medium that enforces the single-closing property. For Bitcoin-based seals, this means trusting Bitcoin's consensus mechanism and the assumption that a 51% attack will not reorganize confirmed transactions. If the underlying consensus is compromised, seals that were considered closed could be reopened through chain reorganizations.

Interoperability Complexity

Different protocols implement single-use seals with different commitment schemes, validation rules, and state transition formats. RGB, Taproot Assets, and other systems are not interoperable by default. Assets issued on one protocol cannot be natively transferred using another, which fragments the ecosystem and requires bridges or conversion mechanisms.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.