Where is inscription data stored?

In the witness of a Taproot script-path spend, inside an OP_FALSE OP_IF block that never executes. Because the branch is unreachable, the data is never interpreted as script and can be anything.

Why does inscribing take two transactions?

The data lives in the script being spent, so the script has to be committed to first. The commit pays to an address derived from the script; the reveal spends it and publishes the script.

What is actually inside an inscription

An inscription is data hidden inside a Taproot script that never executes, revealed when the script is spent. Here are the exact bytes, checked against a 105,900-byte witness item on Bitcoin.

Inscription data is not in an output. It is in the witness of a Taproot script-path spend — inside a branch of script that can never run.

<32-byte pubkey> OP_CHECKSIG
OP_FALSE
OP_IF
  "ord"
  0x01 <content type>      tag 1
  0x03 <parent>            tag 3, when claiming provenance
  OP_0                     separator
  <body>                   one or more pushes, 520 bytes each at most
OP_ENDIF

OP_FALSE OP_IF opens a branch that is never taken, so everything between it and OP_ENDIF is never executed and never has to be valid script. That is the whole trick. The signature check in front of it is what actually authorises the spend.

Details that are easy to get wrong

The body is chunked. A single push is capped at 520 bytes, so anything larger arrives as consecutive pushes which the indexer concatenates. The 550-cat reveal used this to carry 105,900 bytes in one witness item.
The parent tag is not the inscription id as text. It is the txid in reverse byte order, followed by the output index little-endian with trailing zero bytes stripped — so index 0 contributes no bytes at all, and the tag is 32 bytes rather than 33.
Tags are pushes, not opcodes. Tag 1 is a one-byte push of 0x01, not OP_1. They look identical in a hex dump if you are not paying attention and are not interchangeable.
Omit the pointer tag unless you mean it. Tag 2 sets an absolute satoshi offset in the outputs. It exists for batches. Emitting it on a single inscription is a good way to put something somewhere unintended.

Why two transactions

The script has to exist before it can be spent, and its data is only published when it is spent. So inscribing is always:

Commit. Build the script, derive a Taproot address that commits to it, pay that address. The chain learns nothing about the content.
Reveal. Spend that output via the script path, publishing the script — and with it the inscription — in the witness.

The commit must confirm before the reveal is broadcast, unless you run your own node and can submit them as a package. A reveal whose commit the receiving node has not seen comes back as missing-inputs.

Verifying this

This is not a description written from the specification. This project rebuilds the envelope from its own inputs and compares it byte-for-byte against the witness of 3cbbdd020f5026a3e71c95868a7a4e87813da32d98af6b1430ffbb79d8ae0b38, the reveal that carried 551 inscriptions in 105,900 bytes. It matches exactly, which is the only reason the details above are stated as facts rather than as a reading.

Questions

Where is inscription data stored?: In the witness of a Taproot script-path spend, inside an OP_FALSE OP_IF block that never executes. Because the branch is unreachable, the data is never interpreted as script and can be anything.
Why does inscribing take two transactions?: The data lives in the script being spent, so the script has to be committed to first. The commit pays to an address derived from the script; the reveal spends it and publishes the script.

See the collection this came from