Technical April 7, 2026 4 min read

How OP_RETURN Works on Bitcoin (And Why It Matters)

By Ducat Team

Bitcoin is not just a payment network. It has always had the ability to embed arbitrary data in transactions. OP_RETURN is the standardised way to do that. It underpins the Runes token standard, Ordinals inscriptions, timestamping services, and a range of other applications that most people have never heard of.

Here is what it does and why it matters.

What is OP_RETURN?

OP_RETURN is a Bitcoin script opcode, a single instruction in Bitcoin's scripting language. When an output uses OP_RETURN, it is marked as provably unspendable. No wallet can claim those funds because OP_RETURN deliberately makes the output unspendable.

What OP_RETURN does allow is attaching up to 80 bytes of data to that output. Those 80 bytes are included in the blockchain permanently. They sit in the transaction, recorded and immutable, alongside the regular payment outputs.

To put 80 bytes in context: that is enough for a short message, a hash of a document, a timestamp, or structured token data. Not a lot, but enough for many purposes.

Why unspendable outputs?

The reason OP_RETURN outputs are designed to be unspendable is to keep them out of the UTXO set.

Every spendable Bitcoin output has to be tracked by every full node in the network until it gets spent. This is the UTXO set: the collection of all unspent transaction outputs. It needs to be kept in memory for fast access. If arbitrary data outputs could be spendable, anyone could bloat the UTXO set permanently with junk.

OP_RETURN solves this by making the outputs unspendable and therefore droppable from the UTXO set immediately. Nodes store the data in the blockchain (which everyone has regardless) but do not need to track it in the active UTXO memory. This is a reasonable compromise: permanent data embedding without permanent UTXO bloat.

The 80-byte limit

The 80-byte limit is a policy choice, not a fundamental protocol rule. For much of Bitcoin's history the limit was smaller: 40 bytes, then 80. There have been ongoing debates about whether to raise it.

Casey Rodarmor's Runes protocol is designed to work within the 80-byte limit. The Rune data encoding is compact enough to track token transfers in that space. An OP_RETURN output can specify: which Rune is being transferred, how many units, and to which output. Multiple transfers can be batched into a single OP_RETURN.

For context: a SHA-256 hash is 32 bytes. You can fit two document hashes plus some metadata into a single OP_RETURN. You can fit a Bitcoin public key (33 bytes compressed) with room to spare.

What people use OP_RETURN for

Token protocols. The Runes fungible token standard uses OP_RETURN to store token transfer data. Ordinal inscriptions use a different mechanism (tapscript), but Runes uses OP_RETURN directly. This is efficient and well-understood.

Timestamping. Services like OpenTimestamps publish hashes of documents in OP_RETURN outputs. The hash commits to the document's existence at a specific block height. This is useful for proving when something was created without revealing the contents.

Application data. Some applications use Bitcoin as a settlement layer and store application state hashes in OP_RETURN outputs. Coloured coins were an early attempt at this. Modern approaches are more refined.

Proof of existence. Companies and individuals embed document hashes in OP_RETURN outputs to create an immutable public record. Legal documents, certificates, intellectual property registrations.

How Ducat uses OP_RETURN

Ducat issues UNIT stablecoins as Runes. Every UNIT transfer is a Bitcoin transaction with an OP_RETURN output encoding the Rune transfer data.

When you borrow UNIT against your BTC vault, the protocol creates a transaction that mints UNIT and records it in OP_RETURN. When you transfer UNIT to another address, the transaction includes an OP_RETURN specifying the Rune, the amount, and the receiving output. When you repay the loan, UNIT is burned and the record updated via OP_RETURN.

The result is a complete audit trail of UNIT issuance and transfer, recorded on the Bitcoin blockchain, readable by anyone running a Runes-aware indexer. No separate ledger. No separate chain. The stablecoin's entire history is on Bitcoin.

This is what it means in practice for UNIT to be a Bitcoin-native stablecoin. Not marketing language, just the mechanics: the token data lives in OP_RETURN outputs on the Bitcoin blockchain.

OP_RETURN vs Taproot inscriptions

Ordinals inscriptions use a different embedding method. They use the Taproot script path spend to include arbitrary data in transactions, with no size limit beyond what miners will include. An inscription can be several megabytes.

OP_RETURN is smaller and simpler. For token data (where 80 bytes is more than enough), OP_RETURN is the cleaner choice. For larger data like images or longer documents, Taproot inscriptions are more appropriate.

Runes chose OP_RETURN deliberately for efficiency. A Rune transfer that fits in 80 bytes is cheaper and takes up less block space than an inscription equivalent.