What if you could make a promise, cryptographically bind it to Bitcoin, and close it forever with one action — all while broadcasting its intent through Nostr?
Welcome to Threadlocks — a new pattern for time-boxed commitments that live at the intersection of Bitcoin and decentralized social protocols.
⛓️ The Problem with Open-Ended State
Distributed systems struggle with consensus over time and state. You want to make a claim — or a promise — and prove it happened. But you don’t want to bloat a blockchain. And you don’t want to trust a centralized party. You just want a one-time, cryptographically verifiable commitment, and a public record that it occurred.
💡 Introducing Threadlocks
Threadlocks are a minimal, composable mechanism for one-time commitments. Inspired by the idea of single-use seals, Threadlocks build on native Bitcoin primitives (like Taproot key tweaking) and pair beautifully with Nostr, the decentralized event-based protocol.
🧵 What’s a Threadlock?
A Threadlock is:
- Time-boxed: It exists only until it’s used.
- Single-use: Once closed, it can never be reopened.
- Cryptographically anchored: It’s tied to a Bitcoin UTXO or Taproot tweak.
- Narratively threaded: Nostr events document, declare, and extend Threadlocks in social or application logic.
It’s like a fuse you can light once — but visible forever in the chain.
🔧 How Threadlocks Work (In Plain Terms)
1. Lock the Thread
You create a commitment point:
- Usually a Bitcoin UTXO.
- Or better yet, a tweaked Taproot pubkey derived from a base key and a secret (your claim hash, a nonce, or logic payload).
This UTXO becomes your Threadlock.
2. Declare the Thread
You post a Nostr event with a special t tag or threadlock tag:
{
"kind": 3xxxx,
"content": "I claim access to channel #xyz",
"tags": [
["c", "txo:chain:txid:vout"]
]
}
This announces your intent and binds it to a specific Bitcoin output.
3. Resolve the Lock
Later, you spend that UTXO in a Bitcoin transaction, embedding the commitment proof in witness data, an OP_RETURN, or via script logic.
Once spent, that output is forever closed — your Threadlock is done.
📜 Why Not Just Use Smart Contracts?
Because:
- You don’t need a VM or gas fees.
- You don’t need global consensus on execution.
- You don’t want to publish logic on-chain.
- You just want a provable state transition: once, verifiably.
Threadlocks are the „less is more“ of crypto commitments.
🌐 What Nostr Brings to the Table
Nostr gives Threadlocks:
-
Event sequencing (via
created_at) -
Threaded logic (
etags / reply chains) - Lightweight announcements
- Social context for commitments
Threadlocks can be:
- Referenced by future events
- Forked into multiple branches
- Validated by others watching for specific closure conditions
🧪 Use Cases
Threadlocks enable:
- ✅ One-time claims („I minted this“, „I voted“)
- 🔐 Access control (only those with unspent Threadlocks can act)
- 🗳️ DAO governance (commit → vote → finalize)
- 🎮 Game state progression (quests, puzzles, unlocks)
- 🧾 Credential issuance (proof of training, rights, NFTs)
All without smart contracts. Just Bitcoin + Nostr.
🛠️ Future: Libraries, NIPs, Agents
We’re working on:
- A lightweight JavaScript library for managing Threadlocks
- A NIP proposal for a standardized
threadlocktag - Autonomous agents that monitor and act on Threadlock resolution