Inscriptions inscribe sats with arbitrary content, creating bitcoin-nativedigital artifacts, more commonly known as NFTs. Inscriptions do not require asidechain or separate token.
These inscribed sats can then be transferred using bitcoin transactions, sentto bitcoin addresses, and held in bitcoin UTXOs. These transactions, addresses,and UTXOs are normal bitcoin transactions, addresses, and UTXOS in allrespects, with the exception that in order to send individual sats,transactions must control the order and value of inputs and outputs accordingto ordinal theory.
The inscription content model is that of the web. An inscription consists of acontent type, also known as a MIME type, and the content itself, which is abyte string. This allows inscription content to be returned from a web server,and for creating HTML inscriptions that use and remix the content of otherinscriptions.
Inscription content is entirely on-chain, stored in taproot script-path spendscripts. Taproot scripts have very few restrictions on their content, andadditionally receive the witness discount, making inscription content storagerelatively economical.
Since taproot script spends can only be made from existing taproot outputs,inscriptions are made using a two-phase commit/reveal procedure. First, in thecommit transaction, a taproot output committing to a script containing theinscription content is created. Second, in the reveal transaction, the outputcreated by the commit transaction is spent, revealing the inscription contenton-chain.
Inscription content is serialized using data pushes within unexecutedconditionals, called "envelopes". Envelopes consist of an OP_FALSE OP_IF … OP_ENDIF wrapping any number of data pushes. Because envelopes are effectivelyno-ops, they do not change the semantics of the script in which they areincluded, and can be combined with any other locking script.
A text inscription containing the string "Hello, world!" is serialized asfollows:
OP_FALSEOP_IF OP_PUSH "ord" OP_PUSH 1 OP_PUSH "text/plain;charset=utf-8" OP_PUSH 0 OP_PUSH "Hello, world!"OP_ENDIFFirst the string ord is pushed, to disambiguate inscriptions from other usesof envelopes.
OP_PUSH 1 indicates that the next push contains the content type, andOP_PUSH 0indicates that subsequent data pushes contain the content itself.Multiple data pushes must be used for large inscriptions, as one of taproot'sfew restrictions is that individual data pushes may not be larger than 520bytes.
The inscription content is contained within the input of a reveal transaction,and the inscription is made on the first sat of its input if it has no pointerfield. This sat can then be tracked using the familiar rules of ordinaltheory, allowing it to be transferred, bought, sold, lost to fees, and recovered.
Content
The data model of inscriptions is that of a HTTP response, allowing inscriptioncontent to be served by a web server and viewed in a web browser.
Fields
Inscriptions may include fields before an optional body. Each field consists oftwo data pushes, a tag and a value.
Currently, there are six defined fields:
content_type, with a tag of1, whose value is the MIME type of the body.pointer, with a tag of2, see pointer docs.parent, with a tag of3, see provenance.metadata, with a tag of5, see metadata.metaprotocol, with a tag of7, whose value is the metaprotocol identifier.content_encoding, with a tag of9, whose value is the encoding of the body.delegate, with a tag of11, see delegate.
The beginning of the body and end of fields is indicated with an empty datapush.
Unrecognized tags are interpreted differently depending on whether they areeven or odd, following the "it's okay to be odd" rule used by the LightningNetwork.
Even tags are used for fields which may affect creation, initial assignment, ortransfer of an inscription. Thus, inscriptions with unrecognized even fieldsmust be displayed as "unbound", that is, without a location.
Odd tags are used for fields which do not affect creation, initial assignment,or transfer, such as additional metadata, and thus are safe to ignore.
Inscription IDs
The inscriptions are contained within the inputs of a reveal transaction. Inorder to uniquely identify them they are assigned an ID of the form:
521f8eccffa4c41a3a7728dd012ea5a4a02feed81f41159231251ecf1e5c79dai0
The part in front of the i is the transaction ID (txid) of the revealtransaction. The number after the i defines the index (starting at 0) of new inscriptionsbeing inscribed in the reveal transaction.
Inscriptions can either be located in different inputs, within the same input ora combination of both. In any case the ordering is clear, since a parser wouldgo through the inputs consecutively and look for all inscription envelopes.
| Input | Inscription Count | Indices |
|---|---|---|
| 0 | 2 | i0, i1 |
| 1 | 1 | i2 |
| 2 | 3 | i3, i4, i5 |
| 3 | 0 | |
| 4 | 1 | i6 |
Inscription Numbers
Inscriptions are assigned inscription numbers starting at zero, first by theorder reveal transactions appear in blocks, and the order that reveal envelopesappear in those transactions.
Due to a historical bug in ord which cannot be fixed without changing a greatmany inscription numbers, inscriptions which are revealed and then immediatelyspent to fees are numbered as if they appear last in the block in which theyare revealed.
Inscriptions which are cursed are numbered starting at negative one, countingdown. Cursed inscriptions on and after the jubilee at block 824544 arevindicated, and are assigned positive inscription numbers.
Sandboxing
HTML and SVG inscriptions are sandboxed in order to prevent references tooff-chain content, thus keeping inscriptions immutable and self-contained.
This is accomplished by loading HTML and SVG inscriptions inside iframes withthe sandbox attribute, as well as serving inscription content withContent-Security-Policy headers.
Self-Reference
The content of the inscription with ID INSCRIPTION_ID must served from theURL path /content/<INSCRIPTION_ID>.
This allows inscriptions to retrieve their own inscription ID with:
let inscription_id = window.location.pathname.split("/").pop();If an inscription with ID X delegates to an inscription with ID Y, that is tosay, if inscription X contains a delegate field with value Y, the content ofinscription X must be served from the URL path /content/X, not/content/Y.
This allows delegating inscriptions to use their own inscription ID as a seedfor generative delegate content.
Reinscriptions
Previously inscribed sats can be reinscribed with the --reinscribe command ifthe inscription is present in the wallet. This will only append an inscription toa sat, not change the initial inscription.
Reinscribe with satpoint:ord wallet inscribe --fee-rate <FEE_RATE> --reinscribe --file <FILE> --satpoint <SATPOINT>
Reinscribe on a sat (requires sat index):ord --index-sats wallet inscribe --fee-rate <FEE_RATE> --reinscribe --file <FILE> --sat <SAT>
