SATROOT · Launch note

A satoshi is the floor of value, not the ceiling of meaning.

SATROOT turns one native BSV satoshi into the root of a deterministic, replayable semantic ledger — and we anchored one for real, on mainnet, with every step reproducible from raw bytes by anyone who fetches them.

THE FLOOR: 1 NATIVE SATOSHI1 SAT

The idea

Bitcoin's smallest native unit is the satoshi. Most token designs respond to that floor in one of two ways: pretend to subdivide it, or ignore the chain entirely and keep balances in a database. SATROOT takes a third position:

The satoshi is not subdivided. The satoshi anchors a protocol-defined state space.

One specific one-satoshi UTXO becomes a root witness — the namespace handle for a ledger whose state is computed purely by replaying signed events. Token units, machine credits, receipts, identities, licenses, and event-stream custody all live as overlay state above that root. The chain provides the anchor and the publication; ordering comes from the events themselves, via sequence numbers and a hash chain. The protocol provides deterministic meaning. Nothing about the satoshi itself changes, and moving it is never mistaken for a semantic transfer: state follows valid signed events, not UTXO activity.

v2.0.0 — the genesis record is now authenticated

It never was. A forged, empty or absent signature on the genesis record — the one that fixes the mint authority, the max supply and the entire opening allocation — replayed clean under every scheme. So the root of every ledger was forgeable, and every later event was being verified against a root anyone could have written.

It was found by someone implementing the specification from scratch and reading only the document. Seven rounds of that produced twenty-six specification defects and grew the conformance corpus from 33 vectors to 68. None of the serious ones were reachable by 1,751 tests, two implementations or twelve earlier review rounds, because all of those were written against the code.

Authenticating genesis changes its event_id, and therefore every state hash, so a v1 ledger does not replay under v2. The alternative was leaving the root of every ledger forgeable, which is not a trade. See MIGRATION.md.

Break it yourself

The corpus is the standing invitation: 68 vectors — 19 that must replay, 49 that must be rejected — with a runner that needs nothing but Python.

python vectors/run.py --impl your_verifier.py

If your verifier disagrees with EXPECTED.txt, that disagreement is the most useful thing anyone can send this project — whichever of us turns out to be wrong. It is how v2.0.0 happened.

What shipped

The reference implementation is a dependency-free, pure-Python kernel — a canonical event format, a replay engine with strict sequence and hash-chain enforcement, and three signature schemes (a demo placeholder, hmac-sha256, and ed25519). Above the kernel sit six released profiles — stable reference units, machine credits, receipts, identities, licenses, and event-stream heads. They add required genesis metadata and validation to the same token-and-account reducer; they do not define their own state or transitions. Above them sits a full publication ladder that packages ledgers into signed bundles, releases, catalogs, and registry workspaces, each layer carrying its own manifest hashes and verification tooling.

Nineteen tagged releases and ~1,766 tests behind a single release gate. Install it:

pip install satroot
satroot1 replay examples/events_floor1.json

The proof

A protocol document can claim anything. So instead of claiming, we ran the whole loop against the real chain and recorded every artifact. The loop has four steps, and each one is reproducible:

Anchor. A real one-satoshi mainnet outpoint was bound as the root_id of a demo namespace, its full lifecycle signed and verified with ed25519.
Publish. That namespace was pushed through the entire publication ladder — bundles, release, catalog, registry — with ed25519 at every layer.
Commit. The namespace's state hash was broadcast on-chain inside the spec's OP_RETURN envelope.
Verify. The broadcast transaction's raw bytes were fetched and verified fully offline: the bytes hash to the recorded txid, and the envelope matches the deterministically rebuilt commitment byte for byte.

Record · Root outpointBSV mainnet

38ff9da029e66ee9b6a1b175025388caf7fb6d3bb0273812737d7dd6b347c473:0

One satoshi, held by the operator, anchoring the namespace. Custody of this output is deliberately outside the protocol: moving it is not a semantic transfer.

Record · State commitmentsemantic ledger

sha256:34049329f152c388cad547440b32213d48be583c0fa16d93a94582f7399fde58

The anchored namespace's semantic state hash — the value committed on-chain.

Record · Envelope transactionBSV mainnet

7f5946898440a96e18526440ed7140eda85e7dad7e753c7d0b88d09f008b1f83

Output 0 is a zero-value OP_FALSE OP_RETURN carrying the SATROOT1 tag, content type, and the canonical JSON commitment of root and state hash. Look it up on any mainnet explorer.

Don't take the article's word for it. Save the raw transaction hex to a file and run the offline verifier yourself:

python scripts/run_envelope_verification_smoke.py \
  --raw-tx-hex-file rawtx.hex \
  --root-id 38ff9da029e66ee9b6a1b175025388caf7fb6d3bb0273812737d7dd6b347c473:0 \
  --state-hash sha256:34049329f152c388cad547440b32213d48be583c0fa16d93a94582f7399fde58 \
  --expected-txid 7f5946898440a96e18526440ed7140eda85e7dad7e753c7d0b88d09f008b1f83

No network access, and no trust in us once you have fetched the raw transaction and the expected root and state hash from a source you choose — take them from this page and you have checked consistency with this page's claims, not independent truth. The verifier parses the bytes, hashes them, finds the envelope output, and compares it byte-for-byte against the commitment it rebuilds from scratch. The complete record of every intentional anchored run lives in ANCHORS.md — the only place in the repository a real outpoint may appear.

What it deliberately is not

SATROOT's documentation spends as much effort on boundaries as on features, because overlay protocols die of overclaiming:

It does not subdivide Bitcoin below one satoshi, and semantic units are not native Bitcoin units.
It creates no stablecoin, security, redemption right, or reserve claim; stable-value designs are reference-only profiles with those non-claims stated in the genesis record itself.
There is no token sale. The protocol is Apache-2.0, and the anchored satoshi is worth exactly one satoshi.
The frozen kernel authorizes on the signer string plus a valid signature under a registered key; binding keys to accounts across trust domains is explicitly an application-layer responsibility, documented rather than hand-waved.

Where this goes

The profile system is the point, within a limit worth stating: SATROOT is a typed token-and-account ledger with domain-labelled profiles, not a general application-state framework. A namespace rooted in one satoshi can label the custody lineage of a telemetry stream, the prepaid credit balance of an autonomous agent, or the assignment history of a license, mapping each onto the same account and balance operations — deterministically, with offline verification, for the cost of almost nothing. The machine-credit and event-stream profiles are aimed squarely at the emerging problem of proving what autonomous agents consumed, published, and were authorized to do.

The kernel is frozen; the profiles are open. If you want to build an object class on a one-satoshi root, the repository ships everything this article described — including the tooling that produced its own proof.