How parent and child inscriptions work

Giving an inscription a parent means spending the parent's own output. That one requirement turns provenance into an ownership proof that needs no login, no signature challenge and no database.

An Ordinals inscription can name another inscription as its parent. The claim is written into the child's envelope as tag 3, and the parent is identified by its inscription id.

What makes it more than an assertion is the rule an indexer applies before accepting it: the reveal transaction that creates the child must also spend an output that holds the parent. Naming a parent you do not hold produces an inscription with no recorded parent at all — the tag is there in the witness, and it is ignored.

Why this is an ownership proof

Spending a UTXO requires a signature from whoever controls it. So a confirmed child inscription is, by construction, evidence that at the moment of that transaction somebody could sign for the parent.

This is worth dwelling on, because it replaces a whole category of infrastructure. A site that wants to offer something only to holders of a collection normally needs a wallet connection, a signature challenge, a session, and a database of who holds what. Parent/child needs none of it. There is nothing to log in to and nothing to be on a list for. The chain either has the child or it does not.

C.A.T. uses this twice. Every cat is a child of one parent inscription (be813be7d5ab89e5b7059b28bb4419d09e2988e42bf066ff0987ea555f6439fbi0), which is what makes the collection verifiable from the chain rather than from a list somebody publishes. And a cat's holder can inscribe a name under their own cat, which is gated by nothing except their ability to spend it.

What it costs

The parent has to move. Its output is spent in the reveal and sent straight back, in the same transaction, which means:

• The parent's satoshi must land where it started, or it has effectively been sent somewhere. This is a real hazard and it is governed by output ordering, not by intent.
• The holder pays for a commit and a reveal, because inscribing is always two transactions.
• While the reveal is unconfirmed the parent is pending-spent, so it cannot be moved, listed or renamed until it settles.

Checking one yourself

Any indexer exposes the relationship in both directions. For a child this project inscribed as a rehearsal:

/r/parents/7297e15c5f56581cd2280e14af8b722056ec3282d5fffca36fc824e71058f8ebi0
  -> 07d56e9b95ae47f9273cf668bee79d3bbfc8c799a1884d08a753962e36f9bf2ci0

/r/children/07d56e9b95ae47f9273cf668bee79d3bbfc8c799a1884d08a753962e36f9bf2ci0/inscriptions/0
  -> 7297e15c5f56581cd2280e14af8b722056ec3282d5fffca36fc824e71058f8ebi0

Note the /inscriptions/0 on the children endpoint: it is paginated, 100 per page, oldest first. Reading only page zero on a parent with many children returns the oldest of them, which is the wrong answer to "what is this called now".