What is an Inscription "envelope"?
"Enveloping" is one of the least understood parts of how Inscriptions actually work, but also one of the most interesting & unexplored innovations that have come out of "Ordinal Theory".
Understanding envelopes also opens up a discussion on what the definition of an "Inscription" really is and also sets the stage for new innovations on Bitcoin beyond just Ordinal Theory.
Let's try to explain what an "envelope" is.
Want the quick & simple TL;DR?
An Inscription gets broken up into small parts so that it can go onto Bitcoin, but we "package" all those parts together in an "envelope". An envelope is the specific format that helps indexers like "ord" or OrdinalHub's "gord" identify where Inscriptions are & display their data. There are a lot of interesting uses for "envelopes' BEYOND just Ordinals and this idea may unlock many more things beyond just Inscriptions.
Why do we need an "envelope"?
An envelope helps an indexer look through the witness data on Bitcoin and determine 2 things:
1) If an Inscription exists in the witness data
2) What data constitutes that Inscription
In simple terms, an Inscription gets broken up into small parts so that it can go onto Bitcoin, but we "package" all those parts together in an "envelope". An envelope is the specific data structure that helps indexers like "ord" or OrdinalHub's "gord" identify & read Inscriptions.
An Inscription is typically stored in Bitcoin's "witness data", where a Bitcoin transaction's signatures & public keys reside ("Script Witness"). The part of the witness data that we've been putting Inscriptions in (Taproot script spends) can have a maximum size of 520 bytes. If we want to create an Inscription larger than 520 bytes, we have to link these together. An "envelope" is a format that we use to say "what comes after this is an Inscription" so that indexers can identify each piece of data & link them together to form the entire Inscription.
What does an envelope look like/how does it work?
As first explained on docs.ordinals.com, "Envelopes consist of an OP_FALSE OP_IF … OP_ENDIF wrapping any number of data pushes." These "data pushes" are OP_PUSH's, and each one can be no longer than 520 bytes.
We see below an example of an envelope that contains a simple text Inscription that says "Hello, world!".
First, OP_PUSH "ord" indicates that what follows is an Inscription. Indexers like ord & gord look for this specific string to identify if there is an Inscription in the witness data. Then the indexer reads the following OP_PUSH's and assembles the Inscription.
Next, OP_PUSH 1 is often used to indicate the content type ("MIME type") of the Inscription, .jpeg/.mp4/.webp etc.
Then, OP_PUSH 0 is used to include the actual Inscription content. OP_PUSH's use up to 520 bytes each until the entire content of the Inscription is included.
Lastly, after all the OP_PUSH 0's have finished including the Inscription data, OP_ENDIF indicates that the nonexecutable data section is done.
But there are other potential uses for envelopes beyond just Ordinal Theory
That's right, you can create an envelope on Bitcoin without Ordinals at all. It's important to note that it's possible to simple create a Taproot transaction that includes an envelope and is not intended to be used for Ordinal Theory at all.
We can think of Ordinal Theory as being important for when digital artifacts, digital assets, need to be tracked or have an owner. But envelopes are simply for when you want information to be stored on Bitcoin's blockchain.
These are often related, but not necessarily required to go together.
A simple example may be one of the various "news" type protocol projects like Inscribe.news. This project wants to preserve news & information on Bitcoin, and we don't particularly care who the "owner" of the news is – we first care about preserving the information. An envelope without Ordinal Theory might actually make more sense, because if the information is associated with ownership that could actually complicate things.
Another example could be a better way to design & track metaprotocols like BRC-20.
One of the big challenges for BRC-20 marketplaces has been tracking deploy/mint/transfers of BRC-20 tokens. This is because BRC-20 as a metaprotocol is experimental and not initially designed to be a serious fungible token standard. Marketplaces had to track all of the BRC-20 transactions themselves with little agreement on what even "is" a BRC-20 transaction, and occasionally missing the transactions entirely.
One suggested improvement was to create a specific envelope just for BRC-20.
Creating a specific envelope + protocol identifier for BRC-20 could have (and could possibly still) significantly improve the indexing & tracking of BRC-20 tokens. That way, Indexers wouldn't have to sift through a bunch of unrelated Inscriptions that have nothing to do with BRC-20, it could be ignored by people who thought it was irrelevant or detracting from Inscriptions, and it could possibly be designed slightly differently to improve consensus & features.
There are numerous other metaprotocols which could take advantage of dedicated envelopes.
We are experimenting with a specific type of enveloping structure that will power a new idea we're putting out there called [REDACTED]. You can recognize it by the protocol identifier [REDACTED].
We will talk more about [REDACTED] later this week.
There are numerous other topics we could discuss, such as different parts of witness data, what even is an "Inscription", can an Inscription go somewhere like OP_RETURN that's not in the witness data? But we will save those topics for a later time!