RFC: Parent-child Ethscriptions (native collections & onchain metadata/traits)

[tunnckoCore]

For over a year i thought it may not need protocol level addition, but it IS needed the indexer to know about a format.

Just recently JefDiesel started making some sort of parent-child through the @chopperdaddy 's TIC comments/reactions protocol. And that made me think about that again. And @RogerPodacter started mentioning that we need to figure out "collections".

While Jef's thing is cool, temporarily called "Subscriptions" lol, it's not proper "parent-child" anybody can create "a child" for any ethscription. And i thought for that way too - my initial idea awhile ago was to just reference "the parent" in a DataURI param, like data:<content_type>;parent=ethscription_id,<base64_data>. While that is doable and works TODAY, it could be treated as "not proper parent-childing" and have unintended side-effects. At least we should not label it "parent child" cuz people may expect to work in different than it does in for example Ordinals.

---

Currently, we do collections in few ways:

• collection is everything that has the same "creator" - which requires complex scheduling and queue-ing of incoming transactions and then an EOA inscribing it
• creating through contracts with ESIP-3 - where the ESIP-3 has its drawbacks and we can add RFC: alternative contract-creation of ethscription (similar to esip3) #25 for fixing it

The #25 is huge unlock for many such things. The idea is that there could be a well-design contract that is used by many projects to create ethscription collections - with complex minting policies, configurations, allowlists, and whatnot, while the minters are still respected as "creator". Currently it would always be the contract address, which sucks for provenance, that's why currently if you want collection you would need to either use EOA and all its complexities, or deploy a ESIP-3 contract per collection.

---

The parent-child idea is that only the owner of asset can create children. To be proper, the indexer should detect the parent param and assign it to the ethscription referenced.

Parent-child in Ordinals is also used for sort of "collections" - project creators inscribe some collection info and metadata, then that creator is the only one that can create children. But that's possible only because of how Bitcoin transactions work, more specifically - how Bitcoin addresses in combination with UTXO work.

Ordinals also have a "metadata field", where you can put traits for each asset/item. Both things work well in combination.

---

So, what if we introduce both in one go (but they are not linked together, some can use just one of them or the other):

• parent_ref=<ethscription_id> - referencing already inscribed asset
• erc721metadata_ref=<ethscription_id> - referencing already inscribed metadata. Interesting use case where some project may want to inscribe the metadatas first then the actual content.
• erc721metadata=<metadata_json> - the erc721 compliant metadata json as Base64
• metadata - optional collection metadata/manifest/info like urls description name and etc
• metadata_ref - id to already ethscription collection manifest

So how indexer would need to track that:

1. Detect if transaction has is parent_ref param - go get the ethscription by that reference and check its current_owner

• if both the transaction.from matches the referenced_ethscription.current_owner then it's valid
• if not, then ignore and do not create the ethscription at all, ignore it alltogether - in fact, it should create the ethscription, it just will not assign it to "collection". Or it should ignore it? Don't know, not sure.

2. Detect if tx has metadata_ref param - go get the ethscription data and assign it to the new ethscription
3. Detect if tx has metadata param - assign the erc721 metadata to the newly created ethscription

The default should be "by current_owner", but we could also introduce "by creator" - meaning that the param would be something like parent_by_creator and the check would be referenced_ethscription.creator. These are TWO DISTINCT and different scenarios, and some may want one, someone else may want the other.

---

What additional things would there be in the API outputs:

• parent: true | false
• filter by parent
• metadata: {} - the resolve metadata json. If we also do "ESIP-9" (RFC: ESIP-9 — endpoints standardization / "recursion" #18) then:
  • /ethscriptions/<id>/meta would be ethscription's metadata (not the erc721) - immutable things like gas fee, tx fee, and etc - check Calldata API endpoint for ethscription 0x9e4866...5b16 - it does not include owners or the content, cuz there are endpoints for them
  • /ethscriptions/<id>/owners - current_owner, previous_owner, creator, initial_owner
  • /ethscriptions/<id>/manifest - collection metadata if this ethscription is a "parent"
  • /ethscriptions/<id>/erc721metadata - would be the item's erc721 metadata (matching term with the data URI param)
  • /ethscriptions/<id>/content and /ethscriptions/<id>/data - the actual ethscription content

---

Both "parent-child" and "metadata" things will NOT be linked together. They WILL NOT require each other. We can split the RFC into 2 different ESIPs, all fine.