Bitcoin is primarily designed to transfer and secure value, but the Bitcoin blockchain can also contain small amounts of information that aren’t directly related to transferring BTC.
One of the Bitcoin features that makes this possible is OP_RETURN.
If you’ve explored Bitcoin transactions, block explorers, Ordinals, or Bitcoin Runes, you may have come across the term. OP_RETURN can look confusing at first because it involves Bitcoin Script, transaction outputs, and data embedded into blockchain transactions.
So what exactly is OP_RETURN?
In simple terms, OP_RETURN is a Bitcoin Script operation that allows a transaction output to contain a small amount of arbitrary data while making that output unspendable.
That last part is particularly important.
Bitcoin doesn’t treat OP_RETURN as a way to create another wallet balance. Instead, it provides a mechanism for placing limited data into a Bitcoin transaction without creating a normal spendable output.
In this guide, we’ll explain what OP_RETURN means, how it works, why the output is unspendable, how much data it can contain, what people use it for, and how it relates to Bitcoin’s broader transaction system.
What Does OP_RETURN Mean?
OP_RETURN is the name of a Bitcoin Script opcode.
The word OP stands for “operation,” while RETURN describes what the operation does.
When Bitcoin’s scripting system encounters OP_RETURN, the script immediately fails when someone attempts to spend the associated output.
As a result, an output containing OP_RETURN is considered provably unspendable.
This gives OP_RETURN a useful property.
Instead of creating an output that someone might later try to spend, Bitcoin can recognize that the output is intentionally unspendable.
The transaction can therefore carry a small amount of data without creating another ordinary Bitcoin output that needs to be spent later.
A Quick Introduction to Bitcoin Script
To understand OP_RETURN, you first need a basic idea of Bitcoin Script.
Bitcoin doesn’t simply record:
“Alice sent Bob 0.01 BTC.”
Transactions also contain instructions that determine how the Bitcoin associated with an output can be spent.
These instructions are written using Bitcoin Script, a specialized scripting language designed for Bitcoin’s transaction system.
Bitcoin Script is intentionally limited compared with general-purpose programming languages.
It is primarily used to define conditions under which a Bitcoin output can be spent.
For example, a typical Bitcoin payment requires the spender to provide the appropriate cryptographic proof.
This system is one of the reasons Bitcoin transactions can be validated independently by nodes across the network.
If you’d like to understand the scripting system in greater detail, our guide to What Is Bitcoin Script? explores how Bitcoin uses scripts to control spending conditions.
How Does OP_RETURN Work?
An OP_RETURN output is a special type of transaction output.
A simplified Bitcoin transaction might contain:
- Inputs
- Outputs
- Amounts
- Scripts
- Witness data, depending on the transaction type
An OP_RETURN output contains a script that begins with OP_RETURN and can be followed by a small piece of data.
Conceptually, it looks something like:
OP_RETURN + data
The data could represent information chosen by whoever created the transaction.
However, the output isn’t designed to be spent later.
That makes OP_RETURN fundamentally different from a normal Bitcoin payment output.
Why Is an OP_RETURN Output Unspendable?
This is one of the most important things to understand.
When Bitcoin nodes evaluate a script containing OP_RETURN, the operation causes script execution to fail.
Because a valid Bitcoin spend requires the spending conditions to be satisfied, an output containing OP_RETURN cannot be normally spent.
This makes the output provably unspendable.
Bitcoin users sometimes describe this as “burning” the BTC attached to the output.
However, modern OP_RETURN outputs generally carry zero BTC.
That means the purpose isn’t usually to destroy Bitcoin.
Instead, OP_RETURN is primarily used to attach data to a transaction while explicitly creating an output that cannot be spent.
Does OP_RETURN Store Data on the Bitcoin Blockchain?
Yes, but there is an important distinction.
The data associated with an OP_RETURN output becomes part of the Bitcoin blockchain’s transaction history.
Because Bitcoin blocks are replicated across the network, that information can remain available as part of the blockchain record.
However, OP_RETURN should not be thought of as a general-purpose database.
Bitcoin’s blockchain is a globally replicated system.
Every full node that stores the relevant blockchain data has to process and retain that information according to its storage and policy rules.
For this reason, OP_RETURN is intentionally limited and isn’t designed for storing large files.
How Much Data Can OP_RETURN Store?
The amount of data that can be carried in an OP_RETURN output depends on Bitcoin’s consensus rules and relay policy, as well as how the transaction is constructed.
This distinction is important because there is often confusion about a single universal “OP_RETURN limit.”
Historically, Bitcoin Core’s standard relay policy commonly restricted OP_RETURN outputs to relatively small data sizes, such as 80 bytes.
However, relay policy is not the same thing as a consensus rule.
A consensus rule determines what blocks and transactions are valid under Bitcoin’s protocol rules.
A relay policy determines what a particular node is willing to relay under its default settings.
This means the practical amount of OP_RETURN data that can be accepted or relayed can depend on the software version and configuration involved.
This is an important concept when discussing Bitcoin.
Not every rule users encounter is a blockchain-wide consensus rule.
Consensus Rules vs. Relay Policy
This distinction deserves its own explanation because it prevents a lot of confusion.
Consensus Rules
Consensus rules determine whether Bitcoin nodes consider a block or transaction valid.
If a transaction violates a consensus rule, nodes following the relevant rules will reject it as invalid.
Relay Policy
Relay policy is different.
A node can choose not to relay certain transactions even when those transactions aren’t necessarily invalid under Bitcoin’s consensus rules.
Bitcoin Core has default policies designed to limit spam and discourage inefficient use of network resources.
Therefore, an OP_RETURN transaction might be:
Valid under consensus
but
Not relayed by a particular node’s default policy.
This distinction becomes especially important when discussing changes to OP_RETURN policy over time.
Why Did Bitcoin Introduce OP_RETURN?
OP_RETURN wasn’t created so people could turn Bitcoin into a general-purpose data-storage platform.
Its development was closely connected to the need for handling data-bearing outputs in a more explicit and efficient way.
Before OP_RETURN became the standard mechanism for provably unspendable data outputs, people experimented with other ways of embedding information into Bitcoin transactions.
Some approaches could create outputs that appeared spendable even though they were effectively being used only for data.
That creates unnecessary UTXOs.
OP_RETURN provides a cleaner alternative.
Instead of creating another output that might have to be tracked as though it contains spendable Bitcoin, an OP_RETURN output can explicitly indicate:
This output cannot be spent.
OP_RETURN and the UTXO Set
This is where OP_RETURN connects directly to another important Bitcoin concept: the UTXO set.
Bitcoin nodes maintain a database of unspent transaction outputs.
These UTXOs represent Bitcoin that can potentially be spent in future transactions.
If someone creates a normal output, it becomes part of the set of spendable outputs until it is spent.
An OP_RETURN output is different because it is provably unspendable.
This means it doesn’t need to be treated like an ordinary spendable UTXO.
That can reduce unnecessary growth of the UTXO set compared with methods that create outputs that appear spendable.
If you want a deeper explanation of the UTXO model, see our article What Is a Bitcoin UTXO?.
Why Does UTXO Set Growth Matter?
The UTXO set is important because Bitcoin nodes need to use it when validating transactions.
A transaction that spends an existing output needs to prove that the output exists and has not already been spent.
As the number of UTXOs grows, nodes need more resources to maintain and access that information.
This is different from blockchain history.
The blockchain contains the historical record of transactions, while the UTXO set represents the currently unspent outputs relevant to transaction validation.
OP_RETURN’s ability to create provably unspendable outputs therefore has an important technical advantage.
It avoids unnecessarily adding those outputs to the set of spendable Bitcoin.
What Kind of Information Can Be Stored With OP_RETURN?
OP_RETURN doesn’t inherently require the data to have a particular meaning.
The creator of the transaction can encode information according to the application using it.
For example, data could potentially represent:
- A short identifier
- A hash
- A timestamp-related record
- An application-specific message
- Metadata
- A reference to information stored elsewhere
- Proof that a particular piece of data existed at a certain time
The important limitation is size.
OP_RETURN is intended for small pieces of data, not large documents, photographs, videos, or databases.
OP_RETURN and Proof of Existence
One interesting use of OP_RETURN is creating a timestamped proof that some information existed at a particular point in time.
Imagine a company has a document.
Instead of putting the entire document on Bitcoin, it can calculate a cryptographic hash of the document.
A hash produces a fixed-length digital fingerprint of the input data.
The company can then place that hash into an OP_RETURN output.
Later, someone can hash the original document again.
If the resulting hash matches the one recorded on the blockchain, it provides evidence that the same data existed when the transaction was created.
The blockchain therefore acts as a timestamped public record.
This doesn’t necessarily prove who originally created the document.
It demonstrates that matching data was associated with a particular blockchain transaction at a particular point in the chain’s history.
Why Use a Hash Instead of the Entire File?
Because blockchain storage is expensive in terms of network and node resources.
A large document could require far more space than a small OP_RETURN output is intended to carry.
A cryptographic hash solves this problem by representing the original data with a compact fingerprint.
For example:
Document
↓
Cryptographic hash
↓
Small hash recorded through OP_RETURN
The original document can remain stored somewhere else.
The blockchain only needs to preserve the fingerprint.
This approach is sometimes described as anchoring data to the blockchain.
OP_RETURN vs. Normal Bitcoin Payments
A normal Bitcoin payment output is designed to be spent.
For example:
Alice → Bob
Alice’s transaction creates an output that Bob’s wallet can later spend.
An OP_RETURN output has a completely different purpose:
Transaction → OP_RETURN → Data
There is no recipient who can later unlock and spend that output.
This distinction makes OP_RETURN unsuitable for ordinary Bitcoin payments.
It is primarily a mechanism for attaching small amounts of information to transactions.
Does OP_RETURN Cost Bitcoin?
Creating an OP_RETURN transaction can involve a Bitcoin transaction fee.
The fee isn’t normally a payment for “renting blockchain storage.”
Instead, the transaction competes for limited block space, and the sender may need to pay miners a fee based on the transaction’s effective size and the prevailing fee market.
The OP_RETURN data itself also contributes to the transaction’s size.
Therefore, larger data-bearing transactions can require more block space and potentially higher fees.
This connects OP_RETURN directly to the Bitcoin fee market.
Our guide to Bitcoin Transaction Fees explains why transaction size and network demand influence the fees users pay.
Is OP_RETURN the Same as Bitcoin Ordinals?
No.
OP_RETURN and Bitcoin Ordinals are different technologies and approaches.
OP_RETURN stores data in an unspendable transaction output.
Ordinals use Bitcoin’s transaction structure and witness data to associate information with individual satoshis under the Ordinals protocol.
This difference is important.
If you’re researching Bitcoin data storage, you may encounter both concepts because both can be used to place information into Bitcoin transactions.
However, they work very differently.
Our guide to Bitcoin Ordinals explains the Ordinals approach in more detail.
OP_RETURN and Bitcoin Runes
Bitcoin Runes are another example of a protocol that uses Bitcoin transaction data to represent information about assets.
Runes are not simply another name for OP_RETURN.
They are a separate protocol with their own rules for interpreting Bitcoin transaction data.
A Rune transaction can use an OP_RETURN output to carry protocol-specific information.
This is a useful example of why OP_RETURN is best understood as a data-carrying mechanism, rather than an application by itself.
OP_RETURN provides a place where certain protocols can put information.
The application or protocol determines what that information means.
You can read more about the concept in our Bitcoin Runes beginner’s guide.
OP_RETURN Is Not a Bitcoin Wallet
Another common misunderstanding is that OP_RETURN represents a special type of Bitcoin address.
It doesn’t.
An OP_RETURN output is a transaction output containing a script that makes it provably unspendable.
It isn’t a wallet.
It doesn’t hold a balance that can be transferred later.
It also doesn’t provide private-key-based ownership in the same way as a conventional Bitcoin payment output.
This is why you shouldn’t think of OP_RETURN as another Bitcoin address format like a legacy address, native SegWit address, or Taproot address.
Why Doesn’t Bitcoin Simply Allow Unlimited Data?
The answer comes down to decentralization and resource costs.
Bitcoin’s blockchain is maintained by a large network of independent participants.
Those participants need to download, validate, relay, and potentially store blockchain data.
If users could freely add unlimited amounts of arbitrary data at negligible cost, Bitcoin could become an inefficient data-storage system.
That could increase the resource requirements of running nodes and potentially make participation more difficult.
Bitcoin therefore treats block space as a scarce resource.
This is why data storage through mechanisms such as OP_RETURN is limited and subject to the network’s rules and policies.
What Does an OP_RETURN Transaction Look Like?
A Bitcoin transaction can contain several inputs and outputs.
A simplified transaction might look like this:
Input → Transaction → Output
A normal payment output might contain a Bitcoin amount and a script that defines how those coins can later be spent.
An OP_RETURN output works differently.
Conceptually, its script looks something like:
OP_RETURN + data
The OP_RETURN opcode tells Bitcoin Script that execution should immediately fail.
The bytes following it can contain the application’s data.
For example, an application might encode a short identifier and place it inside an OP_RETURN output.
The Bitcoin network doesn’t necessarily understand what that identifier means.
Instead, the application that created the data knows how to interpret it.
This distinction is important.
Bitcoin provides the transaction and data-carrying mechanism. The application determines what the data represents.
What Is the 0x6a You Sometimes See?
If you inspect raw Bitcoin transactions, you may see something such as:
6a …
The hexadecimal byte 6a represents OP_RETURN.
Hexadecimal is simply a convenient way of representing binary data.
For example:
6a= OP_RETURN- Additional bytes = the data or instructions following OP_RETURN
So when a block explorer displays an OP_RETURN output, you’re often seeing a human-readable interpretation of underlying transaction bytes.
This is one reason learning a little about Bitcoin’s transaction structure can make block explorers much easier to understand.
If you’re unfamiliar with block explorers, our guide on How to Read a Bitcoin Block Explorer explains how transaction details, inputs, outputs, confirmations, and other information are displayed.
How Is the Data Encoded?
Bitcoin transactions contain binary data, not ordinary sentences written in a text box.
Applications therefore need to decide how their information should be represented.
Data could be encoded as:
- Text
- Hexadecimal values
- Binary values
- Hashes
- Application-specific identifiers
- Structured protocol messages
For example, a simple piece of text might first be converted into bytes.
Those bytes can then be included after OP_RETURN.
However, Bitcoin itself generally doesn’t need to know whether those bytes represent text, a hash, an identifier, or something else.
The application interpreting the transaction needs to understand the format.
This is similar to how a file can contain bytes that only make sense when interpreted according to a particular file format.
What Happens When a Node Receives an OP_RETURN Transaction?
When a Bitcoin node receives a transaction, it performs a series of validation checks.
The node doesn’t simply trust the transaction because another computer sent it.
It checks whether the transaction follows Bitcoin’s rules and whether its inputs can legitimately be spent.
For an OP_RETURN transaction, the node recognizes the special output script.
Bitcoin Core has historically treated outputs beginning with OP_RETURN as provably unspendable data-carrier outputs.
This has an important consequence.
The output isn’t treated like an ordinary UTXO that someone will later need to unlock.
Instead, the node can recognize that the output cannot be spent.
That is one of the key reasons OP_RETURN is preferable to disguising data inside an apparently spendable output.
OP_RETURN and the UTXO Set
Remember the difference between blockchain history and the UTXO set.
The blockchain contains historical transactions.
The UTXO set tracks outputs that remain available to be spent.
An ordinary Bitcoin output might remain in the UTXO set until another transaction spends it.
An OP_RETURN output is provably unspendable.
Therefore, it doesn’t need to become a normal spendable UTXO.
This is one of OP_RETURN’s biggest technical advantages.
It allows data to be associated with a transaction without unnecessarily creating another spendable output.
A Bitcoin Core BIP discussing zero-value OP_RETURN outputs specifically highlights this advantage, noting that provably unspendable OP_RETURN outputs can be pruned from the UTXO pool.
What Is the Difference Between OP_RETURN and a “Burn Address”?
At first glance, these concepts can look similar.
Both can be associated with Bitcoin that cannot be recovered.
But technically, they’re different.
A burn address is an address for which nobody is expected to have the private key.
If someone sends BTC there, those coins may effectively become inaccessible.
An OP_RETURN output is different.
Its script is deliberately constructed so that it cannot be spent.
The important difference is that OP_RETURN is provably unspendable from the script itself.
That’s why Bitcoin software can identify it as a data carrier rather than treating it as an ordinary payment destination.
Can You Put Bitcoin in an OP_RETURN Output?
Technically, OP_RETURN outputs can have a value field, but modern use generally favors zero-value OP_RETURN outputs.
The reason is straightforward.
If the purpose is to attach data, sending BTC to an output that cannot be spent would permanently destroy those coins.
That’s unnecessary.
A zero-value OP_RETURN output allows the transaction to carry the data without deliberately assigning Bitcoin to an unspendable output.
Bitcoin’s BIP 74 discusses this design and explains why allowing zero-value OP_RETURN outputs avoids unnecessarily destroying Bitcoin while still providing the metadata functionality.
Is There Still an 80-Byte OP_RETURN Limit?
This is one of the most confusing parts of older Bitcoin articles.
You will often see statements such as:
“OP_RETURN has an 80-byte limit.”
That statement needs context.
Historically, Bitcoin Core’s standard relay policy commonly limited OP_RETURN data to a small size. Bitcoin Core 0.12, for example, documented an 83-byte maximum for the entire serialized scriptPubKey, corresponding to the older 80-byte data-carrier policy plus script overhead.
However, that old policy should not be presented as a permanent Bitcoin consensus limit.
Bitcoin Core 30.0 changed the default policy substantially.
According to the Bitcoin Core 30.0 release notes, the default -datacarriersize was increased to 100,000 bytes, effectively removing the previous practical cap because the transaction size limit is reached first. Bitcoin Core 30.0 also allows multiple OP_RETURN outputs in a transaction by default.
That means a modern explanation needs to distinguish between:
Historical relay policy
and
Current Bitcoin Core policy.
It is also important to remember that Bitcoin’s network isn’t controlled by one computer program with one mandatory configuration.
Different nodes and miners can run different software versions and policies.
So you should never treat a default relay policy as though it were automatically a universal consensus rule.
Consensus Rules Are Not the Same as Relay Rules
This distinction is one of the most important concepts in Bitcoin.
Suppose a node’s default configuration refuses to relay a particular transaction.
That doesn’t automatically mean the transaction violates Bitcoin’s consensus rules.
Relay policy is largely about what a node is willing to pass through its mempool and relay to other peers.
Consensus rules determine what the network considers valid.
This is why Bitcoin developers and users often discuss standardness separately from consensus validity.
A transaction can potentially be valid under consensus while still being rejected by the default policy of a particular node.
Bitcoin Core’s OP_RETURN policy has changed over time, which demonstrates exactly why you should be careful when reading older explanations online.
Why Did OP_RETURN Policy Change?
Bitcoin’s developers and users have debated data storage on Bitcoin for years.
There are competing concerns.
On one side, OP_RETURN provides a relatively clean mechanism for applications that genuinely need to attach small amounts of information to transactions.
On the other side, Bitcoin’s blockchain and network resources aren’t unlimited.
Every additional transaction consumes block space.
That transaction needs to be:
- Relayed across the network.
- Validated by nodes.
- Included in a block by a miner.
- Downloaded by other nodes.
- Stored as part of blockchain history.
This creates a real resource cost.
Bitcoin Core’s changing policy reflects an ongoing debate over how the software should handle data-carrying transactions while still maintaining reasonable network behavior.
Can One Transaction Have Multiple OP_RETURN Outputs?
Under current Bitcoin Core 30.0 default relay and mining policy, yes.
The release notes specifically state that multiple data-carrier outputs are permitted for relay and mining. The -datacarriersize limit applies to their aggregate scriptPubKey data-carrier size.
This is another reason older articles can become misleading.
Someone reading an article written several years ago might encounter rules that no longer describe the default behavior of modern Bitcoin Core.
The underlying OP_RETURN concept remains the same, but the surrounding policy can change.
How Do Applications Know What OP_RETURN Data Means?
Bitcoin doesn’t automatically understand every OP_RETURN payload.
Applications can create their own formats.
For example, an application might define:
First few bytes → application identifier
Next bytes → version
Remaining bytes → application data
Another protocol can use a completely different structure.
This is why OP_RETURN can support multiple applications without Bitcoin itself needing to understand every protocol built around it.
The application reads the transaction and interprets the payload according to its own rules.
OP_RETURN as a Protocol Layer
This leads to a useful way of thinking about OP_RETURN.
OP_RETURN is not really an application.
It is closer to a primitive that applications can use.
Think of it like a small notice attached to a Bitcoin transaction.
Bitcoin provides the mechanism for recording the notice.
A separate protocol decides what the notice means.
This is why OP_RETURN has appeared in different Bitcoin-related projects and specifications.
For example, BIP 351 describes a private-payment notification system that uses a 40-byte OP_RETURN payload containing structured information.
The same basic Bitcoin mechanism can therefore be interpreted differently by different applications.
OP_RETURN and Bitcoin Runes
This becomes especially interesting when looking at Bitcoin Runes.
Runes use Bitcoin transactions to encode protocol-specific information.
The OP_RETURN output can act as the place where that protocol information is carried.
But OP_RETURN itself doesn’t create a Rune.
The Rune protocol defines how the data should be interpreted.
This distinction is similar to the difference between:
A container
and
the information inside the container.
OP_RETURN provides part of the container.
The application determines the meaning of the contents.
OP_RETURN and Proof-of-Existence Applications
Another important application is proving that information existed at a particular point in time.
Imagine a photographer creates an original photograph.
They could calculate a cryptographic hash of the file.
The hash is then recorded in an OP_RETURN output.
The actual photograph doesn’t need to be placed on Bitcoin.
Later, the photographer can provide the original file and calculate its hash again.
If the hash matches the blockchain record, the photographer can demonstrate that identical data was committed to the blockchain at or before the time associated with that transaction.
This can be useful for:
- Digital documents
- Intellectual property records
- Research data
- Certificates
- Audit trails
- Document timestamping
However, the blockchain record doesn’t automatically prove every fact surrounding the document.
It doesn’t necessarily prove who created it.
It doesn’t prove that the information was truthful.
It provides a cryptographic commitment that can later be checked.
Why Not Store the Entire Document?
Because Bitcoin is not designed to be a file-hosting service.
Suppose a document is several megabytes.
Putting that entire document into Bitcoin would consume far more block space than storing a compact cryptographic hash.
A hash allows the blockchain to commit to the document without storing the complete document itself.
The basic concept is:
Original data → Hash → OP_RETURN → Bitcoin blockchain
The document can remain somewhere else.
Bitcoin preserves the cryptographic commitment.
This is one of the strongest arguments for using blockchain data storage selectively rather than treating a blockchain as a conventional database.
What Happens to OP_RETURN Data After a Transaction Confirms?
Once an OP_RETURN transaction is included in a confirmed block, it becomes part of Bitcoin’s blockchain history.
As more blocks are added after it, the transaction gains additional confirmations.
The data itself doesn’t move into a wallet.
It doesn’t become a Bitcoin balance.
Instead, it remains associated with the transaction output contained in the historical blockchain record.
This is why a block explorer can later display OP_RETURN information even though nobody can spend the output.
The transaction is part of Bitcoin’s history, while the output itself is unspendable.
Can OP_RETURN Data Be Changed Later?
Not directly.
Once a transaction has been confirmed and buried under additional blocks, changing the transaction would require changing the blockchain history containing it.
That is extremely difficult because Bitcoin’s proof-of-work chain and decentralized network make rewriting confirmed history costly.
However, “immutable” should not be interpreted as meaning absolutely impossible under every imaginable circumstance.
Bitcoin’s security comes from economic and technical incentives, proof of work, network consensus, and the accumulated work behind the chain.
The deeper the transaction is buried, the stronger the practical assurance becomes.
Is OP_RETURN Private?
No.
This is an extremely important warning.
OP_RETURN data is not a private storage mechanism.
If you put information into a Bitcoin transaction and it becomes part of the blockchain, other people may be able to inspect it.
Anyone with access to the blockchain can potentially see the transaction and its associated data.
Therefore, you should never place sensitive information such as:
- Passwords
- Private keys
- Recovery phrases
- Personal identification documents
- Confidential messages
- Authentication secrets
into an OP_RETURN output.
Even if the data is encoded, encoding isn’t automatically encryption.
For example, converting text into hexadecimal doesn’t make it private.
Someone can simply decode it.
OP_RETURN vs. Encryption
Suppose someone wants to store a confidential message.
They might think:
“I’ll encode the message and put it into OP_RETURN.”
That doesn’t provide meaningful privacy if the encoding can easily be reversed.
Encryption is different.
Encrypted information requires a secret key to recover the original message.
Even then, storing encrypted personal information permanently on a public blockchain has its own risks.
A cryptographic system that is secure today may face different threats in the future.
Therefore, OP_RETURN should generally be viewed as a public data-commitment mechanism, not a secure private database.
OP_RETURN and Blockchain Permanence
There is another reason to be careful about what you publish.
Bitcoin transactions can remain part of blockchain history for a very long time.
You should therefore think carefully before placing information on-chain.
A social media post can potentially be deleted.
A website can disappear.
A database can be modified.
But information committed to a public blockchain can become much harder to remove.
This creates an important principle:
Don’t put sensitive information on a public blockchain simply because you can.
The ability to record information permanently doesn’t mean every piece of information should be recorded permanently.
Advantages of OP_RETURN
OP_RETURN has several useful properties.
1. Provably unspendable
The output is deliberately designed so it cannot be spent.
2. Doesn’t create a normal spendable UTXO
This avoids treating the data output like ordinary Bitcoin that needs to remain in the UTXO set.
3. Transparent
The information can be independently verified from the blockchain.
4. Timestamped by the blockchain
Once confirmed, the transaction provides a historical reference point.
5. Useful for protocols
Applications can define their own data structures and interpret OP_RETURN payloads.
6. Doesn’t require a special Bitcoin address
The data can be associated directly with a transaction output.
Disadvantages of OP_RETURN
There are also important limitations.
1. Blockchain space is scarce
Every additional byte has a network and storage cost.
2. Data is public
Anyone able to inspect the blockchain can potentially see the payload.
3. It isn’t designed for large files
OP_RETURN is much better suited to small pieces of structured information.
4. Policy can change
The default relay behavior around data carriers can change between Bitcoin Core releases.
5. Permanent publication can create privacy risks
Once information is recorded publicly, removing it later may be difficult or impossible.
6. Bitcoin isn’t a general-purpose database
Using Bitcoin for arbitrary data storage can impose costs on the broader network.
Should You Use OP_RETURN to Store Data?
For ordinary Bitcoin users, probably not.
Most people buying or sending Bitcoin have no reason to create OP_RETURN transactions themselves.
However, developers, researchers, businesses, and protocol designers may have legitimate reasons to use them.
The key question isn’t:
“Can I put this data on Bitcoin?”
The better question is:
“Does this information genuinely benefit from being recorded on Bitcoin’s decentralized blockchain?”
If the answer is yes, OP_RETURN may provide a straightforward mechanism.
If the information could simply live in a normal database, cloud-storage system, or other conventional infrastructure, putting it permanently on Bitcoin may provide little benefit while consuming scarce blockchain resources.
Practical Examples, Use Cases, Risks, and FAQs
So far, we’ve covered what OP_RETURN is, how it works, why its outputs are unspendable, and how it relates to Bitcoin Script and the UTXO set.
Now let’s make the concept more practical.
If you’ve never inspected an OP_RETURN transaction before, the easiest way to understand it is to imagine a normal Bitcoin transaction with an additional piece of information attached to it.
The transaction still moves Bitcoin normally.
The OP_RETURN output simply carries data alongside the transaction.
How to Find OP_RETURN Data in a Bitcoin Transaction
You don’t need to run a Bitcoin node to inspect an OP_RETURN transaction.
A public Bitcoin block explorer can display transaction outputs and their scripts.
When examining a transaction, look for the outputs section.
A normal output may show:
- Bitcoin amount
- Address
- Script type
- ScriptPubKey
An OP_RETURN output may instead be identified as:
OP_RETURN
or
Null Data
The exact presentation depends on the block explorer.
You may also see the underlying hexadecimal data.
For example, an explorer could display something conceptually like:
OP_RETURN
6a…
The 6a is the hexadecimal representation of the OP_RETURN opcode. Bitcoin Core’s current source defines OP_RETURN as opcode 0x6a.
The bytes following it can represent the data carried by the output.
A Simple Example
Imagine a fictional application wants to record the hash of a document.
The process could look like this:
Step 1: Create the document
A company creates an electronic contract.
Step 2: Calculate its hash
The company calculates a cryptographic hash of the file.
Step 3: Create a Bitcoin transaction
The hash is included in an OP_RETURN output.
Step 4: Broadcast the transaction
The transaction is sent to the Bitcoin network.
Step 5: Wait for confirmation
A miner includes the transaction in a block.
Step 6: Verify later
The company can calculate the hash of the original contract again.
If it matches the value recorded in the Bitcoin transaction, the company can demonstrate that the same data was committed to the blockchain.
The entire document never needed to be placed on Bitcoin.
What Does “Data Commitment” Mean?
A data commitment is essentially a way of publishing evidence that you had specific information at a particular time without necessarily publishing all of the original information.
A cryptographic hash is particularly useful for this.
Imagine that the original document is:
Document A
You calculate:
Hash(Document A) = X
You then record X in an OP_RETURN output.
Later, someone gives you another document.
You calculate its hash.
If the result is also X, you know that the underlying data matches the original data used to produce that hash.
This is powerful because even a tiny change to the original file normally produces a completely different cryptographic hash.
What Can OP_RETURN Be Used For?
OP_RETURN has been used or proposed for a variety of applications.
Some examples include:
Timestamping
A hash can be recorded to provide evidence that information existed by a certain point in blockchain history.
Protocol Messages
A Bitcoin-based protocol can encode information that other software knows how to interpret.
Digital Asset Protocols
Some Bitcoin protocols use transaction data to communicate information about asset operations.
Payment Notifications
Certain protocols can use OP_RETURN data to communicate information between participants.
Application Identifiers
A protocol may use a short identifier to distinguish its own transaction data from unrelated OP_RETURN outputs.
Research and Experiments
Developers can use OP_RETURN to experiment with applications that require blockchain-anchored information.
The important point is that OP_RETURN itself doesn’t define the application.
It provides the mechanism.
The protocol defines the meaning.
Why Applications Often Use an Identifier
Imagine thousands of applications are using OP_RETURN.
How would software know which data belongs to which protocol?
One solution is to include an application-specific identifier in the payload.
Conceptually:
OP_RETURN + Protocol ID + Version + Data
The protocol ID tells software:
“This payload belongs to me.”
The version can tell the software which format is being used.
The remaining bytes can contain application-specific information.
This approach allows multiple protocols to share the same underlying Bitcoin transaction mechanism.
OP_RETURN and Bitcoin Runes
Bitcoin Runes provide a useful real-world example of this concept.
A Rune transaction can contain protocol information that tells Rune-aware software what operation is being performed.
The OP_RETURN output is part of the mechanism used to carry that information.
But the distinction remains important:
OP_RETURN is not the Rune protocol.
Instead:
OP_RETURN = data-carrying mechanism
Runes = protocol that interprets specific data
This is similar to how an envelope isn’t the same thing as the letter inside it.
The envelope provides the container.
The message provides the meaning.
If you’re interested in how this works in the context of Bitcoin-based fungible assets, see our guide to What Are Bitcoin Runes?.
OP_RETURN vs. Bitcoin Ordinals
OP_RETURN and Ordinals are frequently mentioned together because both can be used in discussions about putting information on Bitcoin.
However, they work differently.
OP_RETURN
OP_RETURN places data in an unspendable transaction output.
Ordinals
The Ordinals protocol uses Bitcoin’s transaction and witness structure to associate inscriptions with individual satoshis.
This means the two systems have different technical designs.
OP_RETURN is naturally suited to relatively small pieces of structured metadata.
Ordinals introduced a different approach that enabled much larger inscriptions and new types of Bitcoin-based applications.
You can learn more about that system in our Bitcoin Ordinals guide.
OP_RETURN vs. Storing Data in a Normal Transaction Output
Another possible approach would be to create a normal-looking output containing information in its script.
The problem is that such an output could potentially look like a spendable UTXO.
That creates unnecessary state for Bitcoin nodes.
OP_RETURN provides a cleaner signal.
The script itself indicates that the output is unspendable.
Bitcoin Core’s current documentation explicitly describes a data-carrying output as an unspendable output containing data. Its blockchain statistics also separately track unspendable outputs such as OP_RETURN.
This is one of the reasons OP_RETURN is technically preferable for this particular purpose.
Does OP_RETURN Increase Bitcoin’s Blockchain Size?
Yes.
The data still occupies space in the transaction.
That means it contributes to the blockchain’s overall historical data.
This is important because blockchain storage isn’t free.
When someone adds data to Bitcoin, that information needs to be propagated through the network and eventually becomes part of blockchain history if the transaction is confirmed.
This creates costs for:
- Network bandwidth
- Transaction processing
- Block space
- Blockchain storage
Therefore, even though OP_RETURN outputs don’t normally create ordinary UTXOs, the data itself still consumes blockchain resources.
This is an important distinction:
OP_RETURN can reduce unnecessary UTXO growth, but it doesn’t make data free.
Why Bitcoin Block Space Matters
Bitcoin blocks have limited capacity.
Transactions compete for that capacity.
When demand increases, users may compete by offering higher fees to get their transactions confirmed sooner.
A data-heavy transaction can therefore have an economic cost.
This is one reason Bitcoin’s fee market matters.
If someone wants to publish information on-chain, they aren’t simply using an unlimited public storage system.
They’re consuming part of a scarce global resource.
That is why responsible Bitcoin applications should minimize unnecessary data.
Can OP_RETURN Be Used for Spam?
Yes.
Any mechanism that allows data to be recorded on a public blockchain can potentially be used for unwanted or low-value data.
This is one reason Bitcoin Core has historically maintained policies around data-carrying outputs.
The purpose of relay policy isn’t necessarily to declare every possible use of OP_RETURN invalid.
Instead, policy can determine what transactions a node will normally accept into its mempool and relay to peers.
Current Bitcoin Core source code includes configurable settings for data-carrier acceptance and the maximum amount of data allowed under standard relay policy.
This provides an important layer of control without changing the fundamental meaning of the OP_RETURN opcode.
Is Putting Data on Bitcoin Bad for Bitcoin?
There isn’t a simple yes-or-no answer.
It depends on the data and the reason for recording it.
A small cryptographic commitment that provides genuine value can be very different from filling blocks with unnecessary information.
Supporters of on-chain data applications argue that Bitcoin’s block space should be available for legitimate uses as long as users pay the market price for the resources they consume.
Critics may argue that excessive data usage can increase costs for node operators and distract from Bitcoin’s primary monetary purpose.
This debate is ultimately connected to a larger question:
What should Bitcoin’s scarce block space be used for?
There isn’t universal agreement on that question.
Is OP_RETURN a Database?
No.
This is perhaps the most important practical distinction.
A database is designed to:
- Store large amounts of information
- Search information efficiently
- Update records
- Delete records
- Organize complex datasets
- Serve applications
Bitcoin’s blockchain is designed for something very different.
It provides a decentralized, globally replicated record of transactions secured by a consensus system.
OP_RETURN can attach data to that record.
But it doesn’t transform Bitcoin into a database.
If your application needs millions of records, large files, frequent updates, or complex queries, a conventional database will usually be much more appropriate.
Is OP_RETURN Permanent?
Once an OP_RETURN transaction is confirmed, its data becomes part of the blockchain’s historical record.
However, it’s better to say that it becomes extremely difficult to alter rather than simply claiming that nothing can ever change.
Bitcoin’s security comes from its decentralized network and proof-of-work consensus.
As more blocks are built on top of a transaction, rewriting that portion of history becomes increasingly difficult and expensive.
This is why users generally wait for confirmations when they need stronger assurance that a transaction is deeply embedded in the chain.
Can You Delete OP_RETURN Data?
Normally, you shouldn’t expect to be able to delete it from Bitcoin’s blockchain history.
If the transaction is confirmed and remains part of the accepted chain, the data is part of that historical record.
Individual node operators may use different storage and pruning configurations, so not every node necessarily keeps every piece of historical blockchain data locally forever.
But that doesn’t mean the information has been removed from Bitcoin’s history.
Other nodes, archives, block explorers, and historical copies may still retain it.
Therefore, you should treat public blockchain publication as effectively permanent.
Is OP_RETURN Anonymous?
No.
OP_RETURN itself does not provide anonymity.
The data may be public, and the transaction containing it can be analyzed alongside its inputs and outputs.
If a particular OP_RETURN payload is connected to an identifiable Bitcoin transaction or entity, blockchain analysis may help connect the data to that activity.
This is another reason not to put personal or confidential information directly into an OP_RETURN output.
Can OP_RETURN Store a Private Key?
Technically, arbitrary data can potentially be encoded into transaction data, but you absolutely should not publish a private key this way.
A Bitcoin private key is a secret that controls access to funds.
If you place it on a public blockchain, anyone who discovers it could potentially use it.
The same applies to:
- Seed phrases
- Passwords
- API credentials
- Recovery codes
- Authentication tokens
Never treat OP_RETURN as a secure vault.
It is the opposite of private storage.
What About Encrypted Data?
Encrypted data is different from plain-text data.
Someone could encrypt information before recording it.
However, this doesn’t automatically make permanent blockchain storage a good idea.
If the encryption key is compromised in the future, the permanently recorded ciphertext could potentially become readable.
For sensitive information, consider whether you genuinely need permanent public publication before putting anything on-chain.
In many cases, the safest choice is simply not to publish the information.
OP_RETURN and Bitcoin Developers
OP_RETURN is particularly useful for developers building systems that interact with Bitcoin transactions.
A developer can create a transaction containing:
- Normal Bitcoin inputs.
- Normal payment outputs.
- An OP_RETURN output.
- Application-specific data.
The receiving application can then inspect the transaction and interpret the payload.
This allows Bitcoin to act as a settlement and timestamping layer for certain applications without requiring every piece of application logic to become part of Bitcoin’s consensus rules.
That separation is important.
The Bitcoin network doesn’t need to understand every application built on top of it.
Why OP_RETURN Doesn’t Require a New Bitcoin Address
A normal Bitcoin payment requires a destination output that specifies how the recipient can spend the funds.
OP_RETURN doesn’t represent a person receiving Bitcoin.
It represents data.
Therefore, there isn’t a conventional “OP_RETURN wallet address” that someone owns.
This is another reason why OP_RETURN transactions can look strange to beginners when they first appear in a block explorer.
You’re looking at an output, but there may be no normal recipient address associated with it.
A Simple Mental Model for OP_RETURN
If you’re still confused, remember this:
Normal Bitcoin output
“Here is Bitcoin that someone can spend later.”
OP_RETURN output
“Here is information associated with this transaction that isn’t meant to be spent.”
That’s the core idea.
Everything else—protocols, hashes, metadata, Runes, timestamping, and applications—builds on that basic concept.
Frequently Asked Questions About Bitcoin OP_RETURN
What does OP_RETURN do in Bitcoin?
OP_RETURN creates a provably unspendable transaction output that can carry data.
Is OP_RETURN a Bitcoin address?
No. It is a Bitcoin Script opcode and is used in a special type of transaction output.
Can OP_RETURN hold Bitcoin?
It can have an output value, but modern use generally favors zero-value OP_RETURN outputs because sending BTC to a provably unspendable output would destroy those coins.
Is OP_RETURN data public?
Yes. Data included in a confirmed Bitcoin transaction should be treated as public.
Can OP_RETURN data be deleted?
You should generally assume that confirmed OP_RETURN data cannot be removed from Bitcoin’s historical record.
Does OP_RETURN create a UTXO?
A provably unspendable OP_RETURN output isn’t treated as an ordinary spendable UTXO.
Bitcoin Core’s own statistics distinguish unspendable outputs from actual unspent outputs.
Is OP_RETURN the same as Ordinals?
No. They use different parts of Bitcoin’s transaction structure and have different designs.
Is OP_RETURN the same as Bitcoin Runes?
No. Runes are a separate protocol. OP_RETURN can be used to carry protocol-specific Rune information.
Can OP_RETURN store images?
The mechanism can carry data, but OP_RETURN is not intended to function as general-purpose image storage. The practical suitability depends on the transaction’s size and applicable policy.
Is there an 80-byte OP_RETURN limit?
The commonly quoted 80-byte figure refers to historical Bitcoin Core relay policy, not a permanent universal consensus rule. Current Bitcoin Core policy is configurable and has evolved substantially.
Does OP_RETURN cost money?
Creating a transaction containing OP_RETURN data can require a transaction fee because the data contributes to the transaction’s resource usage and size.
Can OP_RETURN make Bitcoin private?
No. OP_RETURN data is public blockchain data and does not provide anonymity.
Final Thoughts: Why OP_RETURN Matters
OP_RETURN may seem like a small technical feature, but it reveals something important about Bitcoin.
Bitcoin isn’t simply a digital balance sheet.
Its transactions are programmable within the limits of Bitcoin Script, and those transactions can carry information in addition to transferring value.
OP_RETURN provides a standardized way to associate data with a transaction while making the corresponding output provably unspendable.
That makes it useful for applications such as:
- Data commitments
- Timestamping
- Protocol messages
- Metadata
- Digital asset protocols
- Blockchain-based applications
At the same time, OP_RETURN comes with real limitations.
Bitcoin block space is scarce.
The data is public.
Permanent publication can create privacy concerns.
And Bitcoin isn’t designed to replace conventional databases or cloud storage.
The most useful way to think about OP_RETURN is therefore not:
“Bitcoin lets you store anything you want.”
Instead, think of it as:
“Bitcoin provides a decentralized and highly durable place to commit small amounts of information to transaction history.”
That distinction explains both the usefulness of OP_RETURN and the debate surrounding blockchain data storage.
For someone learning Bitcoin, OP_RETURN is also a great example of how different parts of the system fit together.
Bitcoin Script determines what transaction outputs mean.
Transactions carry the information.
The UTXO model tracks spendable outputs.
Blocks organize confirmed transactions.
And Bitcoin’s decentralized consensus system provides the security that makes the historical record valuable.
Once you understand those relationships, OP_RETURN stops looking like a strange piece of Bitcoin jargon and starts looking like what it really is:
A small but powerful building block for applications that want to anchor information to Bitcoin’s blockchain.
