Orgchain v1.14: soulbound belts ride their seats' sats

A belt is soulbound: the reducer already bound it to the seat it names,
and now the lab inscribes it on that seat's own sat, so by ordinal theory
it goes wherever the seat goes and never sells apart from it. One reveal
carries an award, three coins in: the seat's, which the pointer puts the
belt in and the seat's own key signs, accepting it; the issuer's, the
parent; and the commit, which pays the fee. Both coins come back unchanged,
so an award needs no postage and costs two fees (1,000 sats). ord marks it
a reinscription and vindicated, since a pointer and an envelope past the
first input would have cursed it before the jubilee. The engine takes that
three-input reveal and nothing looser: the parent spent from the
inscriber's key, both coins returned unchanged, the pointer on an inscribed
sat of the first.

A belt is never a lot, and an award can't land in a tree that is listed or
sold. Trees count and split by inscribed sat, so a seat's belts stay on it
through every sale. Inspect shows a node's belts and ord's charms, and the
award form says whose sat the belt will ride. Belts from before v1.14 stay
with their issuers and count the same.

Rehearsed on Bitcoin Core regtest from height 161: sixteen beats and 131
transactions; ord charms the three belts as the lab does, and after two
whole-tree sales each belt shares its seat's satpoint. The compare now
checks satpoints and charms.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01H4upF5LVwmPDDqrhdUfnXh
This commit is contained in:
teahubxyzandClaude Opus 5.5 committed 2026-10-15 15:48:31 -07:00
1 parent 74ed801176
commit c8c18b073e
18 files changed
+368 -107

No files matched your search

+25 -13
View File
@@ -18,11 +18,11 @@ lineage/v0 uses these fields of the ord envelope ([inscriptions](https://docs.or
| 5 | metadata | a CBOR map: `op` and its fields (section 4), strings except a keyring's `proof` map, in 520-byte pushes (Orgchain keeps it under 2048 bytes) |
| 3 | parent | the inscription id of the node that authorizes the event; exactly one, except for `found` |
| 1 | content type | `text/plain;charset=utf-8`; the body is a short label such as `birth time` (a keyring's is its statement), ignored by the rules |
| 2 | pointer | puts a child's inscription in its own output when the parent is spent first |
| 2 | pointer | puts a child's inscription in its own output when the parent is spent first, and a belt on its recipient's sat (section 7) |
The body, delegate (tag 11) and properties (tag 17) carry no meaning here; properties may later carry display traits
such as a belt's colour, never authority. Unknown odd tags are ignored. Never use unknown even tags: ord treats such an
inscription as unbound, so it has no location.
such as a belt's colour, never authority. Nor do ord's charms, such as a belt's (section 7). Unknown odd tags are
ignored. Never use unknown even tags: ord treats such an inscription as unbound, so it has no location.
A reveal is a script-path spend whose tapleaf commits to the envelope script's exact bytes (BIP-341). Orgchain's reveals
before v1.9 committed to a re-encoded script; real Bitcoin rejects those, and Orgchain's local chain still loads them.
@@ -55,7 +55,7 @@ the inscription moves the authority.
| --- | --- | --- | --- |
| `found` | none | `name` | a holding; no active holding may already have that name |
| `birth` | an active holding, org or graduated agent | `name`, `kind` (`org` or `agent`, default `org`) | a child; the parent may not already have an active child of that name |
| `award` | an active holding, org or graduated agent | `to`, `skill`, `belt` (`white`, `green` or `black`) | `to` (any other active node, in any holding) holds that belt in that skill, replacing its earlier belt in it |
| `award` | an active holding, org or graduated agent | `to`, `skill`, `belt` (`white`, `green` or `black`) | `to` (any other active node, in any holding) holds that belt in that skill, replacing its earlier belt in it; the belt is bound to `to`, whoever holds its inscription (section 7) |
| `decide` | an active node | `title` (required), `why` (optional) | a decision on the node's record |
| `make` | an active node | `name`, `note` (optional) | an item, made and first held by the node; a node makes one item per name |
| `keyring` | the node itself, active | `taproot`, `segwit`, `nostr`, `ethereum`, and `proof`: each key's signature | the node's keys are bound to it, replacing its earlier keyring (section 8) |
@@ -128,7 +128,8 @@ by one of its derived descendants; an award and its recipient's close; two found
graduation or close that retires it; two keyrings that list the same key; a join or adoption and a graduation, close or
birth that changes the moving node or its new parent. Orgchain keeps a keyring and the graduation that would retire it
a block apart, and it freezes a tree that is listed or sold (section 7), so nothing in it acts, and nothing above it
graduates or closes it, before its buyer adopts it.
graduates or closes it, before its buyer adopts it. An Orgchain award spends its recipient's inscription as well as its
issuer's (section 7), so an award and its recipient's close are chained, in a fixed order.
## 7. Ownership, items and deals
@@ -157,11 +158,21 @@ In Orgchain a deal on a tree goes like this:
lot's own first, and pays them into one output at the lot's key, with a coin of the seller's last for the fee, so no
inscription's sat pays it. The ask signs that output, and withdrawing the ask splits it back.
- After the `join` and the `adopt`, the buyer splits the output it bought: one transaction with an output for each
inscription, running from its sat to the next one's (the first from the output's start), to the node's new key, or,
for an item, to the new key of the node that held it, which the deal records as its layout.
inscribed sat, running from it to the next one (the first from the output's start), to the new key of the node whose
inscription is on it, or, for an item, to the new key of the node that held it, which the deal records as its layout.
A sat's inscriptions never part, so a node's belts stay on its sat.
- While a tree is listed or sold it is frozen: nothing in it acts or moves money, nothing above it graduates or closes
it, nothing in it sells alone, and a listed holding mines nothing. The records of a tree's events (decisions, belts,
keyrings and the like) are not part of it: they carry no authority, and stay where they landed.
it, nothing in it sells alone, and a listed holding mines nothing. The records of a tree's events (decisions,
keyrings and the like) are not part of it: they carry no authority, and stay where they landed. Its nodes' belts ride
their sats (below), so they come along.
A belt is soulbound: it belongs to the node it names, whoever holds its inscription, and is never a lot. Orgchain
inscribes it on that node's own sat, so it goes wherever the node goes. The award's reveal spends three outputs: the
one holding `to`'s inscription, which its holder signs, accepting the belt; the issuer's, the parent; and the commit,
which pays the fee. It returns the first two unchanged, and its pointer (tag 2) is the offset of `to`'s sat in the
first, so the belt lands on that sat, a reinscription. ord charms it ♻️ reinscription and ❤️‍🔥 vindicated: a pointer,
or an envelope past the first input, would have cursed it before the jubilee. Orgchain's belts from before v1.14 sit
with their issuers, and count the same.
## 8. Keys and keyrings
@@ -220,9 +231,10 @@ chain's own wallets sign a message.
## 10. Conformance
`tools/regtest` rehearses Orgchain's sample on Bitcoin Core regtest, byte for byte, keyrings, asks, offers and whole
trees changing hands included (bundled outputs and their splits too), and `bin/lineage-index.mjs --compare` checks that
ord and the lab tell the same story: the same events in the same beats, the same metadata and parents, the same trees
and keyrings, and every inscription in the same output. `tests/indexer.test.js` replays a recorded run.
`tools/regtest` rehearses Orgchain's sample on Bitcoin Core regtest, byte for byte, keyrings, belts, asks, offers and
whole trees changing hands included (bundled outputs and their splits too), and `bin/lineage-index.mjs --compare`
checks that ord and the lab tell the same story: the same events in the same beats, the same metadata and parents, the
same trees and keyrings, and every inscription on the same sat (ord's satpoint), with the same ♻️ reinscription and
❤️‍🔥 vindicated charms. `tests/indexer.test.js` replays a recorded run.
`tests/keyring.test.js` checks the proofs against BIP-322's published vectors, the key tree page's Ethereum vector, and
values cross-checked with bip322-js, ethers and nostr-tools.