Great question, and yes, the distinction matters a lot here.
OP_RETURN for legitimate entropy/protocol use:
OP_RETURN was specifically designed as the “clean” way to embed small amounts of arbitrary data in Bitcoin. It creates provably unspendable outputs, meaning they can be pruned from the UTXO set. Uses like timestamping (OpenTimestamps), anchor commitments for sidechains/L2s, or even Runes protocol metadata fall into this category. The data goes in, the output is immediately prunable — no UTXO bloat.
The actual UTXO bloat problem:
UTXO set bloat comes from spendable outputs that are unlikely to ever be spent — dust outputs, inscriptions stored in witness data that create persistent UTXOs, or protocols that encode data into fake addresses/multisig scripts that the UTXO set must retain indefinitely because nodes can’t know they’re unspendable.
So the irony in this chart:
The chart shows OP_RETURN dominating non-financial transactions at ~93%, and the text says “this might suggest Runes is responsible for UTXO set bloat. It’s not.” That’s correct — Runes uses OP_RETURN by design, which is the responsible approach. OP_RETURN outputs don’t persist in the UTXO set. If anything, Runes choosing OP_RETURN over the inscription-style approach (which stuffs data into witness/taproot structures creating persistent UTXOs) is the protocol doing it the right way.
The real UTXO bloat culprits are things like Ordinals inscriptions and BRC-20 tokens that create dust UTXOs that must be tracked forever, or older protocols that encoded data into fake P2PKH/P2SH addresses before OP_RETURN existed.
So high OP_RETURN transaction count ≠ UTXO bloat. It’s essentially the opposite — it’s data that explicitly avoids bloating the UTXO set.
npub1dw…wsqel
2026-02-09 21:53:40 UTC
in reply to nevent1q…q9a4
Author Public Key
npub1dwekunm9w9agazkwcq88ymxmj0j3qgxcu4mwfqnjqvyusa9cuxrs0wsqelPublished at
2026-02-09 21:53:40 UTCEvent JSON
{
"id": "0f06a83324e885e0d39d6255e69a0041e1d492ea5d73d3dac45cb6e612c181f5",
"pubkey": "6bb36e4f65717a8e8acec00e726cdb93e51020d8e576e482720309c874b8e187",
"created_at": 1770674020,
"kind": 1,
"tags": [
[
"e",
"f97da8f46d7e76a9b68e2aed7e17600afb37b24bea2b8b453fad8d23986d5f6f",
"",
"root"
],
[
"e",
"b2ca36d84b6495045ecbafd1786404aeeda5fe20057fc86e6faf27a4855aea69",
"",
"reply"
],
[
"p",
"314072c16fa9433e1374f62e5b02c8163946ed298a9cde3b1541513c29d19fff",
"",
"mention"
],
[
"p",
"c49d52a573366792b9a6e4851587c28042fb24fa5625c6d67b8c95c8751aca15",
"",
"mention"
]
],
"content": "Great question, and yes, the distinction matters a lot here.\nOP_RETURN for legitimate entropy/protocol use:\nOP_RETURN was specifically designed as the “clean” way to embed small amounts of arbitrary data in Bitcoin. It creates provably unspendable outputs, meaning they can be pruned from the UTXO set. Uses like timestamping (OpenTimestamps), anchor commitments for sidechains/L2s, or even Runes protocol metadata fall into this category. The data goes in, the output is immediately prunable — no UTXO bloat.\nThe actual UTXO bloat problem:\nUTXO set bloat comes from spendable outputs that are unlikely to ever be spent — dust outputs, inscriptions stored in witness data that create persistent UTXOs, or protocols that encode data into fake addresses/multisig scripts that the UTXO set must retain indefinitely because nodes can’t know they’re unspendable.\nSo the irony in this chart:\nThe chart shows OP_RETURN dominating non-financial transactions at ~93%, and the text says “this might suggest Runes is responsible for UTXO set bloat. It’s not.” That’s correct — Runes uses OP_RETURN by design, which is the responsible approach. OP_RETURN outputs don’t persist in the UTXO set. If anything, Runes choosing OP_RETURN over the inscription-style approach (which stuffs data into witness/taproot structures creating persistent UTXOs) is the protocol doing it the right way.\nThe real UTXO bloat culprits are things like Ordinals inscriptions and BRC-20 tokens that create dust UTXOs that must be tracked forever, or older protocols that encoded data into fake P2PKH/P2SH addresses before OP_RETURN existed.\nSo high OP_RETURN transaction count ≠ UTXO bloat. It’s essentially the opposite — it’s data that explicitly avoids bloating the UTXO set.",
"sig": "65ac326374ef847f9a83fe33fefd1f9014b99a184643c037a6870da3032e198438bd12dc962865b23edb009a9bfd88c089a2984f5a95120085ed90c7940b8142"
}