What is a recursive inscription?

An inscription whose content references other inscriptions by id, using the /content/ path. The referenced data is already on chain, so nothing needs hosting and the reference cannot break.

Because the alternative is inscribing every image in full. A collection that shares its parts pays for them once and then pays only for the recipe, which is the difference between hundreds of megabytes and less than one.

Recursive inscriptions, with a complete worked example

An inscription can load another inscription's content by id. C.A.T. uses it to fit 2,222 pieces of generative art into 622 KB — each cat is 114 bytes that reference a shared engine and 138 on-chain trait images.

An inscription's content can reference another inscription by id, at /content/<id>. The reference resolves on chain: the data is already there, so there is nothing to host and no link that can rot.

The whole chain, for one cat

C.A.T. #57 is 115 bytes, and this is all of it:

<!DOCTYPE html><script 57 src=/content/948a5a52b7939789e4e5d3d00f7dc3d48ad23e61c866ee368807a1f34dcb6c08i0></script>

That is the entire artwork. The number 57 sitting where an HTML attribute would go is the cat's index — invalid HTML, read back by the script from its own tag, and two bytes cheaper than doing it properly. Cats with fewer digits are 114 bytes; four-digit ones are 117.

What it loads is a 399-byte engine, which holds the canvas configuration and imports the renderer:

948a5a52b7939789e4e5d3d00f7dc3d48ad23e61c866ee368807a1f34dcb6c08i0    399 bytes    config + import
7691aad0b5623b507fb3fda015c7993e4f3536fc5b5ceaa26e57b99f7b40c411i0    9,268 bytes  the renderer
197b1db238e465f4803e1de2ba331aef532e15161affbec38a7bf09bbe09cdb1i0   14,649 bytes  which traits each cat has

The renderer reads the index, looks up that cat's traits in the metadata inscription, and composites the matching images from 138 on-chain trait PNGs onto a 1440×1440 canvas with image smoothing off, because the art is pixel art and interpolation would ruin it.

The arithmetic

2,222 cats at roughly 114 bytes each is about 250 KB. Add one engine, one renderer, one metadata file and 138 trait images, each paid for exactly once, and the complete collection is 622 KB on chain. Inscribing 2,222 full-size images instead would have cost hundreds of times that in both bytes and fees.

The 22 hand-drawn one-of-ones do not fit the recipe, so they are inscribed as themselves — which is why one of them is 2,381 bytes rather than 114.

What this buys beyond cost

Every part is independently addressable and independently verifiable. Anybody can fetch the engine, the renderer, the metadata and any trait image straight from an indexer and rebuild any cat from scratch. There is no server in the path, including ours: this website renders the cats by pointing at the same on-chain content everyone else can point at.

That is the property the collection is actually about. If every site that displays these disappeared tonight, the art would still be there and still be renderable by anybody who can read Bitcoin.

Questions

What is a recursive inscription?: An inscription whose content references other inscriptions by id, using the /content/<id> path. The referenced data is already on chain, so nothing needs hosting and the reference cannot break.
Why does it matter?: Because the alternative is inscribing every image in full. A collection that shares its parts pays for them once and then pays only for the recipe, which is the difference between hundreds of megabytes and less than one.

See the collection this came from