Blocktrails v0.1

Nostr-native state on Bitcoin

Blocktrails let you anchor evolving state to Bitcoin using nothing but keys and hashes. Each state update creates a new output. Bitcoin's UTXO model guarantees only one valid history exists. No extra tokens. No sidechains. No new consensus rules. A primitive you extend — define tokens, voting, audit trails through Profiles.

State 0
JSON
→
Address 0
P2TR
→
UTXO
funded
↓ spend
State 1
JSON
→
Address 1
P2TR
→
UTXO
head

How It Works

Your private key plus a hash of the current state determines the output key. When state changes, you spend to a new key derived from the new state. Anyone with the state history can verify the chain.

  1. Hash your state to get a tweak value
  2. Add the tweak to your base private key
  3. The resulting public key becomes a P2TR output
  4. To update state, spend to the next derived key
import { Blocktrail } from 'blocktrails'; // Create a trail with your Nostr key const trail = new Blocktrail(privateKey); // Commit state → get P2TR address const genesis = trail.genesis('{"balance": 1000}'); console.log(genesis.p2trAddress); // bc1p... // Advance state → new address trail.advance('{"balance": 900}');

Why Nostr-Native?

Blocktrails use full secp256k1 keys internally — the same keys Nostr uses. Your existing Nostr identity can control a Blocktrail directly. No awkward key conversions. No parity headaches. The x-only encoding required by Taproot is handled only at the Bitcoin boundary.

Minimal

One P2TR output per state update. Key-path spends only. No scripts.

SPV-Compatible

Verify with merkle proofs. No full node required.

Composable

A primitive, not a protocol. Define your own state format and rules.

No Extra Tokens

Just Bitcoin. No wrapped assets, no bridges, no new consensus.

Comparison

How Blocktrails compares to other Bitcoin state protocols:

Blocktrails RGB Taproot Assets
Complexity Minimal High Medium
Validation Client-side Client-side Universe servers
State model Linear chain DAG Asset tree
On-chain footprint 1 P2TR output 1 output + commitment 1 output + witness
Key model Nostr-native Custom Custom
Best for Simple state machines Complex contracts Asset issuance

The Math

State commitment is simple scalar addition:

# derive key for state
t = SHA256(state) mod n
d = d_base + t
P = d·G

# Bitcoin output uses x-coordinate
output = x(P)

Use Cases

Blocktrails are a building block. Applications define what state means:

Token ledgers Version control Voting systems Audit trails Game state IoT logs Any linear state machine
Read the Spec Profiles (MRC20) Live Demo GitHub

FAQ

How is this different from RGB or Taproot Assets?

RGB and Taproot Assets are full protocols with complex validation layers. Blocktrails is a minimal primitive — just key tweaking and spend chains. You build your own rules on top. Think of it as the simplest possible state anchoring.

Where is the state stored?

Off-chain. Bitcoin only stores the commitment (the output key). You need the actual state bytes to verify, but they can live anywhere — git repos, IPFS, Nostr relays.

What prevents invalid state transitions?

Client-side validation. Verifiers check that each transition follows the rules your application defines. Bitcoin enforces ordering and prevents double-spends.

Can I define my own state format?

Yes — that's the point. Blocktrails is a primitive, not a protocol. The spec defines Profiles for application-specific rules. MRC20 defines fungible tokens. Monochrome defines generic state machines. You can create your own profile for voting, attestations, game state — anything that fits a linear state model. The base layer never changes.

Do I need to run a full node?

No. Blocktrails are SPV-compatible. You only need output keys and merkle inclusion proofs.

Is there a reference implementation?

Yes. npm install blocktrails — JavaScript/Node.js with full test suite. See the GitHub repo.