# Parent-Child Inscriptions

There are at least two primary advantages of structuring parent-child hierarchy into a collection: (1) the establishment of on-chain provenance; and (2) the establishment of fixed supply constraints, and whereas the former will provide verifiable proof that a particular inscription does or does not belong to a given collection, the latter will provide verifiable proof that the number of inscriptions within a particular collection cannot be expanded or inflated. In order for an individual to add more child inscriptions to a parent-child collection, they must hold the parent inscription in their wallet; therefore, if the parent inscription was effectively *burned* by sending it to [**Satoshi's address**](https://www.ord.io/1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa?profile-tab=inscriptions), then that would provide on-chain proof that the supply of the collection cannot be increased.&#x20;

Unlike most other Bitcoin Ordinals collections, **DomoDucks** possesses both on-chain provenance and fixed supply constraints! As previously touched upon, inscription #256 is the parent of the collection, but in another respect, you might call it the grandparent. This is because the thought of burning such an early artifact would be on par with desecrating a relic. And, therefore, the parent-child hierarchy of the collection is structured such that a single child has been produced from [**Inscription #256**](https://www.ord.io/256) (let's call it the collection's “logo”), and then [**256 children**](https://www.ord.io/?childrenOf=84defb5e7db11f047b4bc58685b65654980be4a55e254a510048a71e0e43e532i0) have been produced from that child, and, thereafter, that single child (*i.e.*, [**the logo**](https://www.ord.io/43138070)) was burned. Therefore, even if Inscription #256 somehow fell into the wrong hands, it would still be impossible for anyone to add another Ordinal into the collection—its supply will always remain capped at 256.&#x20;

<figure><img src="https://4092101906-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FBU6lTkLqk8CwLOsgdFX7%2Fuploads%2FrS6qG2nloo6le47YsuL7%2Fimage.png?alt=media&#x26;token=5cf140ce-af57-49fd-aac6-3ee5c312c241" alt=""><figcaption></figcaption></figure>

As for the artistic conception of the logo inscription, it was arrived at by combining inscription #256 with Domo's pfp so that the logo not only has a black cap (like Domo), but a VR headset, too. This logo inscription was sacrificed in order to protect the integrity of the collection as a whole. How poetic!

<figure><img src="https://4092101906-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FBU6lTkLqk8CwLOsgdFX7%2Fuploads%2FxloKIzyCLAwJkThYfhgM%2Flogo_process.png?alt=media&#x26;token=de7ddfb5-6094-4237-95ff-196cad17180f" alt=""><figcaption></figcaption></figure>

The creator of the Ordinals Protocol (*i.e.*, Casey Rodarmor) once [**remarked**](https://x.com/rodarmor/status/1888391428461760642) that if he had it to do over, he would “seriously consider requiring all inscriptions to have at least one parent, linking them all into a huge, convoluted family tree.” And since that's precisely the way that **DomoDucks** is structured, we have a [**web application**](https://sockits.github.io/Domoducks.familytree/) that allows everyone to easily explore all of the parent-child relations within the entire **DomoDucks** family tree. It's so much fun to analyze on-chain data in this way—give it a try!

{% embed url="<https://drive.google.com/file/d/1wkd7JiVQ-55SAofE_I_gF8h4a5fhosVh/view?usp=sharing>" %}


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://domoducks.gitbook.io/domoducks/parent-child-inscriptions.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
