Bitcoin OP_RETURN Use Cases: Data Anchoring, Tokens, and More

What Is OP_RETURN?

OP_RETURN (opcode 0x6a) is a Bitcoin Script instruction that immediately terminates script execution and marks the output as provably unspendable. Because nodes recognize these outputs as unspendable, they are excluded from the UTXO set, preventing permanent blockchain bloat. The output value must be 0 satoshis to be considered standard by default relay policy.

This property makes OP_RETURN the canonical method for embedding arbitrary data in Bitcoin transactions. Since its standardization in Bitcoin Core 0.9.0 (March 2014), dozens of protocols have used it for timestamping, token issuance, sidechain anchoring, and commitment schemes. The payload was originally limited to 40 bytes, later increased to 80 bytes, and as of Bitcoin Core v30.0 (October 2025), the default relay policy allows up to 100,000 bytes across multiple OP_RETURN outputs per transaction.

Use the OP_RETURN decoder to inspect the payload of any Bitcoin transaction containing embedded data, or explore the full Bitcoin opcode reference for context on how OP_RETURN fits into the scripting system.

Protocols Using OP_RETURN

The following table summarizes the major protocols that have used OP_RETURN to embed data on Bitcoin. Each protocol encodes its payload differently, but all rely on the same underlying mechanism: a provably unspendable output carrying an application-specific byte sequence.

Timestamping and Proof of Existence

One of the earliest and most enduring uses of OP_RETURN is proving that a document or dataset existed at a specific point in time. By embedding a cryptographic hash in a Bitcoin transaction, the document's existence becomes anchored to a block with a known timestamp, inheriting Bitcoin's immutability guarantees.

Proof of Existence

Created by Manuel Araoz and Esteban Ordano in 2013, Proof of Existence was the original blockchain notary service. Users upload a document, the service computes its SHA-256 hash, and embeds that 32-byte hash in an OP_RETURN output. The document itself never touches the blockchain: only its fingerprint is recorded. This provides cryptographic proof that the document existed at the time of the transaction without revealing its contents.

OpenTimestamps

Created by Peter Todd, OpenTimestamps improves on per-document timestamping by aggregating an unlimited number of timestamp requests into a Merkle tree, then committing only the root hash to a single Bitcoin transaction. This means one on-chain transaction can timestamp millions of documents. The system is free for end users because the transaction fee is amortized across all requests in the batch.

Four public calendar servers (Alice, Bob, Finney, and Catallaxy) each produce at most one Bitcoin transaction per block. In 2017, OpenTimestamps demonstrated its scalability by timestamping over 750 million files from the Internet Archive in a single Merkle tree committed to one Bitcoin transaction. The payload uses fewer than 40 bytes, making it compatible even with the most restrictive relay policies.

Token Protocols

Before Ethereum existed, developers built token issuance systems on Bitcoin using OP_RETURN to encode transfer instructions. These protocols laid the groundwork for the broader tokenization movement.

Omni Layer (Original USDT)

Omni Layer (originally Mastercoin) traces back to J.R. Willett's "Second Bitcoin White Paper" published in January 2012. Its fundraiser in July 2013, raising approximately 4,700 BTC, is widely considered the first-ever ICO. The protocol encodes token transactions in OP_RETURN outputs using a 4-byte ASCII prefix (omni / hex 6f6d6e69) followed by the transaction type, token identifier, and amount.

Omni Layer's most significant contribution was hosting the original USDT issuance. Tether first issued tokens on Bitcoin via Omni in October 2014, with USDT assigned property ID 31. As stablecoin volume grew, Tether migrated the majority of supply to Ethereum (ERC-20) and Tron (TRC-20) for lower fees and faster settlement. Tether formally discontinued Omni Layer support on August 17, 2023. For more on stablecoin platforms, see our research on stablecoins on Bitcoin.

Counterparty (XCP)

Counterparty launched on January 2, 2014, through a proof-of-burn event where participants sent BTC to the unspendable address 1CounterpartyXXXXXXXXXXXXXXXUWLpVr. Over 2,131 BTC were burned to create approximately 2.6 million XCP tokens, with no ICO and no founder allocation.

The protocol uses OP_RETURN for payloads under 80 bytes and falls back to 1-of-3 bare multisig outputs for larger data. Counterparty hosted early experiments in blockchain-based digital assets, including Spells of Genesis (2015) and the Rare Pepe collection (October 2016): one of the earliest NFT ecosystems. Active development resumed in 2024 with "Counterparty 2.0" adding UTXO-based asset support and a fair minting mechanism.

Colored Coins

The colored coins concept, first proposed by Yoni Assia in March 2012 and formalized by Meni Rosenfeld in December 2012, used Bitcoin outputs to represent external assets such as stocks, bonds, or property deeds. Before OP_RETURN standardization, colored coin implementations required complex transaction structures to "tag" outputs. After March 2014, the Open Assets Protocol (created by Flavien Charlon) used OP_RETURN marker outputs to store asset metadata cleanly.

Multiple competing implementations (ChromaWay, CoinPrism, CoinSpark, Colu) were never made interoperable, and most were discontinued by the early 2020s. The colored coins concept influenced later token standards including Runes and the RGB protocol.

Runes Protocol

Created by Casey Rodarmor (also behind Ordinals), the Runes protocol launched on April 20, 2024, coinciding with Bitcoin's fourth halving. Runes encodes fungible token operations (etching, minting, transferring) in OP_RETURN outputs called "Runestones." Unlike BRC-20 tokens that use Ordinals inscriptions, Runes is UTXO-based and avoids creating unnecessary outputs. The launch caused a tenfold increase in OP_RETURN output volume within weeks.

Sidechain Anchoring and Commitment Schemes

Several sidechain and cross-chain protocols use OP_RETURN to anchor their state to Bitcoin's proof-of-work security. By periodically writing a hash or commitment to the Bitcoin blockchain, these systems inherit a degree of Bitcoin's immutability.

RSK (Rootstock) uses merge mining with Bitcoin, including an OP_RETURN output containing the prefix RSKBLOCK: followed by the RSK block header hash. VeriBlock's Proof-of-Proof protocol publishes blockchain state snapshots as OP_RETURN transactions. At its peak in 2019, VeriBlock accounted for roughly 58% of all OP_RETURN outputs on Bitcoin. Komodo's Delayed Proof-of-Work used 64 elected notary nodes to periodically write block hashes to Bitcoin via OP_RETURN, though it switched to Litecoin for notarizations in June 2021 to reduce costs.

A 2020 study by the Blockchain Research Lab found that between September 2018 and December 2019, 32.4 million OP_RETURN transactions were published on Bitcoin, representing 22% of all transactions in that period. VeriBlock and Omni/Tether together accounted for 98% of that volume.

The 80-Byte Limit and Its Evolution

The OP_RETURN payload size has been governed by relay policy (standardness rules), not consensus. A miner can include non-standard OP_RETURN transactions in a block and the block remains valid. The following table tracks how the default policy has evolved.

The 83-byte figure in Core 0.12.0 refers to the total serialized scriptPubKey size: 1 byte for the OP_RETURN opcode plus 1 to 2 bytes for data push opcodes, leaving up to 80 bytes of actual user payload. The v30.0 change was controversial: Bitcoin Knots (maintained by Luke Dashjr) maintained a restrictive 40-byte policy, and Knots node adoption surged to approximately 20% of the network during the debate. The rationale for the Core change was to channel data embedding into the dedicated OP_RETURN space rather than having it proliferate through workarounds like witness data inscriptions or bare multisig encoding.

For a deeper understanding of how Bitcoin's scripting system handles these operations, see our guide on Bitcoin Script programmability.

OP_RETURN vs. Alternative Data Embedding Methods

OP_RETURN is not the only way to embed data in Bitcoin transactions. Since the Taproot activation in November 2021, several alternatives have gained traction, each with different tradeoffs in cost, capacity, and pruneability.

Ordinals inscriptions, launched by Casey Rodarmor in January 2023, exploit the SegWit witness discount to embed up to ~4 MB of data per transaction at one-quarter the cost per byte compared to non-witness data. The data is stored in a Taproot script-path spend using OP_FALSE OP_IF ... OP_ENDIF envelopes.

Bitcoin Stamps (SRC-20) take the opposite approach: data is encoded in bare multisig UTXO outputs that remain in the UTXO set permanently. This makes Stamps data unpruneable by full nodes, which critics argue imposes an externality on the network. The Stamps protocol is built on top of Counterparty's data encoding infrastructure.

The Taproot annex (defined in BIP 341) is an optional witness field identified by a leading 0x50 byte. It is currently reserved for future upgrades, and transactions containing an annex are not relayed by default. Proposals to standardize annex relay are under discussion but have not been finalized.

How to Inspect OP_RETURN Data

Decoding OP_RETURN payloads requires identifying the protocol that created them. The general process is:

1. Locate the OP_RETURN output in a transaction (it will have a 0-satoshi value and a scriptPubKey starting with 6a).
2. Extract the hex payload after the opcode and push data bytes.
3. Check for known protocol prefixes: 6f6d6e69 for Omni, 52534b424c4f434b3a for RSK, or attempt ASCII decoding for human-readable messages.
4. Apply the protocol-specific decoding rules to interpret the remaining bytes.

The OP_RETURN decoder automates this process. For raw script analysis, the Script debugger can step through the full scriptPubKey. If you are working with timestamps, the timestamp converter can help translate block times to human-readable dates.

Frequently Asked Questions

What is OP_RETURN used for in Bitcoin?

OP_RETURN is used to embed arbitrary data in Bitcoin transactions. Common applications include document timestamping (OpenTimestamps, Proof of Existence), token issuance (Omni Layer, Runes, Counterparty), sidechain anchoring (RSK, VeriBlock), and commitment schemes. The data is stored in a provably unspendable output that does not bloat the UTXO set.

What is the maximum data size for OP_RETURN?

As of Bitcoin Core v30.0 (October 2025), the default relay policy allows up to 100,000 bytes across multiple OP_RETURN outputs per transaction. Previously, the limit was 80 bytes in a single output. These are standardness rules, not consensus rules: miners can include larger payloads in blocks regardless of relay policy. Node operators can configure the limit via the -datacarriersize parameter.

Was USDT originally on Bitcoin?

Yes. Tether (USDT) was first issued on the Bitcoin blockchain via the Omni Layer protocol in October 2014. Omni Layer transactions encode token data in OP_RETURN outputs using the omni ASCII prefix. As volume grew, Tether migrated the majority of supply to Ethereum and Tron. Tether discontinued Omni Layer support in August 2023.

What is the difference between OP_RETURN and Ordinals inscriptions?

OP_RETURN stores data in a transaction output's scriptPubKey at full weight cost (1 vbyte per byte). Ordinals inscriptions store data in the witness field of a Taproot input, benefiting from the SegWit discount (0.25 vbytes per byte). Inscriptions can hold up to ~4 MB per transaction, while OP_RETURN is typically used for smaller payloads. Both methods keep data out of the UTXO set.

Is OP_RETURN data permanent?

OP_RETURN data is stored in the blockchain permanently and can be read by any full node. However, because OP_RETURN outputs are not part of the UTXO set, pruned nodes (which discard old block data) may not retain it. Archival full nodes will always have access to historical OP_RETURN data.

How does OpenTimestamps work?

OpenTimestamps aggregates timestamp requests into a Merkle tree and commits only the root hash to Bitcoin via an OP_RETURN output (under 40 bytes). This allows a single transaction to timestamp millions of documents. Calendar servers batch requests and produce at most one Bitcoin transaction per block. The service is free because the on-chain cost is amortized across all requests.

What happened to colored coins on Bitcoin?

Colored coins were an early attempt (2012 to 2014) to represent non-Bitcoin assets using tagged transaction outputs. Multiple competing implementations (Open Assets, ChromaWay, CoinPrism, Colu) were built but never achieved interoperability. Most were discontinued by the early 2020s. The concept influenced later protocols including Counterparty, Omni Layer, and the modern Runes protocol, which uses OP_RETURN for UTXO-based fungible tokens on Bitcoin.

This tool is for informational purposes only and does not constitute financial advice. Protocol details, relay policies, and usage statistics are based on publicly available information and may change as Bitcoin Core and individual protocols evolve. Always verify current technical specifications against official documentation before building on these protocols.