bitcoin-metaprotocols-inscriptionsInscriptions: arbitrary data committed to specific sats via Taproot envelope structure. Foundation for BRC-20, recursive inscriptions, "Bitcoin NFTs". USE WHEN: creating/parsing inscriptions, debugging inscription flow, evaluating inscription cost / fee impact.
Independent GitHub snapshot · Automated classification · Original documentation governs
Casey Rodarmor's scheme (Jan 2023) for embedding arbitrary data on Bitcoin via Taproot script-path commitments. Combined with ordinals, each inscription is "owned by" a specific sat.
1. Construct a Taproot script tree containing an "envelope" leaf:
OP_FALSE
OP_IF
OP_PUSH "ord"
OP_PUSH 1 ; field 1 = content type
OP_PUSH "image/png"
OP_PUSH 0 ; field 0 = body
OP_PUSH <data chunks>
...
OP_ENDIF
2. Commit to the script tree in a Taproot output.
3. Reveal the inscription via spending that output, using script-path:
- Witness includes the envelope + control block.
- Data appears in the witness on chain.
The data is "inscribed on" the first sat of the spent input.
Most inscriptions use a 2-tx pattern:
This pattern allows re-use of prior key/script tree.
field 0: body (the actual data)
field 1: content_type (MIME type)
field 2: pointer (sat offset within UTXO)
field 3: parent (parent inscription ID for relationships)
field 5: metadata (CBOR-encoded)
field 7: metaprotocol (e.g., "brc-20")
field 9: content_encoding (e.g., "br" for brotli)
Field 6: delegate lets one inscription reference content of
another. Forms a graph; saves bytes by re-using inscribed data.
Inscription "scripts" that load JS/SVG/HTML can use
/r/inscription/<id> URLs to fetch other inscriptions on-chain.
Inscriptions consume witness space, which is discounted 4x in fee accounting. But they still cost real money:
In Bitcoin Core the -datacarrier* options govern OP_RETURN
outputs only, so they never applied to inscriptions, which ride in
the witness. Knots differs: -datacarrierfullcount defaults to 1
there ("Apply datacarriersize limit to all known datacarrier
methods") and its DatacarrierBytes() walks the input witness, so
the Knots -datacarriersize=83 default does bear on envelopes
(v29.4.1.knots20260508, Sept 2026). Core's defaults changed
materially in 30.0 (October 2025) and still stand in
31.1 (July 2026):
<= 29.x 30.0+
-datacarriersize 83 bytes 100,000 bytes (aggregate)
OP_RETURN outputs/tx 1 many (relay + mining)
-minrelaytxfee 1 sat/vB 0.1 sat/vB
-incrementalrelayfee 1 sat/vB 0.1 sat/vB
-blockmintxfee 1 sat/vB 0.001 sat/vB
100,000 bytes "effectively uncaps the limit, as the maximum
transaction size limit will be hit first" (30.0 release notes): an
OP_RETURN scriptPubKey is non-witness, 4 WU per byte, so 100 KB of
it already blows past the 400,000 WU standard-tx weight limit.
Consequences for metaprotocols:
OP_RETURN is now a relay-viable data channel of effectively
arbitrary size, and no longer capped at one output per tx. Matters
most for protocols that encode state there (Runes).OP_RETURN cheaper than a witness envelope:
witness bytes cost 1 WU, OP_RETURN bytes cost 4 WU, so bulk
inscription payloads stay ~4x cheaper in the witness.-datacarriersize=83 restores the old cap. The removal proposal
discussed during 30.0 development was dropped — neither option
carries a deprecation marker as of 31.1 (July 2026).Some Bitcoin developers see inscriptions as chain spam — using
chain space for non-monetary data. Bitcoin Knots filters them by
default: at v29.4.1.knots20260508 (Sept 2026) -rejectparasites=1
("refuse to relay or mine parasitic overlay protocols") and
-rejecttokens=1 are the shipped defaults, alongside
-datacarriersize=83 and -minrelaytxfee of 1 sat/vB.
Counterview: inscriptions pay full market fees, are legitimate tx, and can't be filtered without arbitrary mempool policy that deviates from consensus. Core moved its own defaults the other way (see above); the uncapping merged as PR #32406 on 9 June 2025, four months before 30.0 shipped on 13 October 2025. The dispute ran alongside a node-share surge over the same period: Knots went from ~400 reachable nodes in Jan 2025 to a peak of 7,112 on 14 Sep 2025, and sits at 4,399 — 17.0% of 25,864 reachable public nodes — as of 15 September 2026 (coin.dance). Reachable-node counts are not sybil-resistant, so read that surge as a signal, not a headcount.
On Core's chain this stays policy, not consensus: a filtered
tx remains valid and confirms as soon as any miner includes it. That
is no longer true of current Knots builds. BIP-110 ("Reduced Data
Temporary Softfork") invalidates, at the consensus layer, Tapscripts
that execute OP_IF/OP_NOTIF, pushdata payloads and script-argument
witness items over 256 bytes, and Taproot annexes — which covers the
inscription envelope itself. Its mandatory-signaling window opened on
8 August 2026, the chain split, the minority chain stalled, and the
BIP was marked Closed in the BIPs repo days later (bips#2245,
"following a chain split with stalled mining"). It never reached its
55% threshold by signaling; instead it took effect as a flag day at
block 961,640 (30 August 2026), the first block of a separate BLAKE2b
proof-of-work chain, with the data limits running to 1 September 2027.
That change shipped in the v29.4.1.knots20260508 line (rc1 tagged
21 August 2026; final release 2 September 2026). UTXOs created before
the flag-day height are grandfathered, so inscriptions made earlier
stay spendable there. So as of September 2026: policy on Core's chain,
consensus on the Knots BLAKE2b chain — and those are two different
chains. See ../../core/knots/SKILL.md.
api-mainnet.magiceden.dev/v2/ord/btc/* returns
503 no healthy upstream as of September 2026 — do not code
against it.