OP_RETURN

OP_RETURN refers to a standard locking script type that can be used to store data inside transactions.

The OP_RETURN opcode itself immediately ends the execution of the script and marks it as invalid.

Whilst this is an opcode on its own and can be used in a variety of different scripts, the name "OP_RETURN" is also used to refer to a standard script pattern used for storing arbitrary data inside transactions.

This page covers the OP_RETURN locking script pattern.

This locking script cannot be unlocked. Do not lock up any amount of bitcoins using this script pattern.

This is sometimes referred to as a "nulldata" script. But whilst that's the technically correct term, it's not commonly used, which is why I refer to this locking script as "OP_RETURN" instead.

Usage

How does an OP_RETURN script work?

ScriptPubKey

The OP_RETURN standard locking script just contains the OP_RETURN opcode followed by one or more data pushes.

OP_RETURN
OP_PUSHBYTES_11
68656c6c6f20776f726c64

6a0b68656c6c6f20776f726c64

These data pushes can contain any bytes of data you like.

They are commonly used for storing ASCII-encoded text strings (see examples).

ASCII

tool-686993fb84318

ASCII

Convert between bytes (in hexadecimal) and ASCII characters.

Example Hex

0 bytes

Bytes

 

ASCII

0 characters

• The hex bytes between 0x20 and 0x7f contain the printable characters.
• Anything 0x1f or below is a control character (will not display, or will display a weird character).
• Anything 0x80 or above will show nothing.

See the ISO 646 encoding standard for details.

0 secs

ScriptSig

An OP_RETURN locking script is unspendable, so there's no ScriptSig that can unlock it.

So ultimately outputs with the OP_RETURN locking script only exist to store arbitrary bytes of data, and can never be used as inputs in future transactions:

Limits

How much data can you store in an OP_RETURN?

The total maximum size for a standard OP_RETURN script is 83 bytes.

Within this limit you can include multiple data pushes. For example:

OP_RETURN
OP_PUSHBYTES_15
6c6561726e6d6561626974636f696e

6a0f6c6561726e6d6561626974636f696e

OP_RETURN
OP_PUSHBYTES_15
6c6561726e6d6561626974636f696e
OP_1
OP_2
OP_3
OP_4

6a0f6c6561726e6d6561626974636f696e51525354

OP_RETURN
OP_PUSHBYTES_1
a0
OP_PUSHBYTES_1
a1
OP_PUSHBYTES_1
a2
OP_PUSHBYTES_1
a3
OP_PUSHBYTES_1
a4
OP_PUSHBYTES_1
a5
OP_PUSHBYTES_1
a6
OP_PUSHBYTES_1
a7
OP_PUSHBYTES_1
a8
OP_PUSHBYTES_1
a9
OP_PUSHBYTES_1
b0
OP_PUSHBYTES_1
b1
OP_PUSHBYTES_1
b2
OP_PUSHBYTES_1
b3
OP_PUSHBYTES_1
b4
OP_PUSHBYTES_1
b5
OP_PUSHBYTES_1
b6
OP_PUSHBYTES_1
b7
OP_PUSHBYTES_1
b8
OP_PUSHBYTES_1
b9
OP_PUSHBYTES_1
c0
OP_PUSHBYTES_1
c1
OP_PUSHBYTES_1
c2
OP_PUSHBYTES_1
c3
OP_PUSHBYTES_1
c4
OP_PUSHBYTES_1
c5
OP_PUSHBYTES_1
c6
OP_PUSHBYTES_1
c7
OP_PUSHBYTES_1
c8
OP_PUSHBYTES_1
c9
OP_PUSHBYTES_1
d0
OP_PUSHBYTES_1
d1
OP_PUSHBYTES_1
d2
OP_PUSHBYTES_1
d3
OP_PUSHBYTES_1
d4
OP_PUSHBYTES_1
d5
OP_PUSHBYTES_1
d6
OP_PUSHBYTES_1
d7
OP_PUSHBYTES_1
d8
OP_PUSHBYTES_1
d9
OP_PUSHBYTES_1
e0

6a01a001a101a201a301a401a501a601a701a801a901b001b101b201b301b401b501b601b701b801b901c001c101c201c301c401c501c601c701c801c901d001d101d201d301d401d501d601d701d801d901e0

So as long as the total OP_RETURN ScriptPubKey size remains within the 83-byte limit, you can include as many data pushes as you like.

Single Data Push

A 1-byte data push opcode (i.e. OP_PUSHBYTES_X) can only push up to 75 bytes at a time. For example:

OP_RETURN
OP_PUSHBYTES_75
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006c6561726e6d6561626974636f696e

6a4b0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006c6561726e6d6561626974636f696e

So if you want to use a single data push of 76 bytes or more, you need to use the OP_PUSHDATA1 opcode instead:

OP_RETURN
OP_PUSHDATA1
50
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006c6561726e6d6561626974636f696e

6a4c5000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000006c6561726e6d6561626974636f696e

Therefore, the largest single data push you can include in an OP_RETURN output is 80 bytes.

This is because it requires 3 bytes of overhead (i.e. 6a4c50), which takes us up to the 83-byte limit for a OP_RETURN standard script.

History

How has the maximum data storage size of OP_RETURN changed over time?

The OP_RETURN script was first introduced as a standard script in Bitcoin v0.9.0.

• Bitcoin v0.9.0 (March 2014) — Allowed for a single data push of up to 40 bytes.
  • The limit was initially set to 80 bytes (pull request #2738), but was reduced to 40 bytes (pull request #3737) shortly before the v0.9.0 release.
• Bitcoin v0.11.0 (July 2015) — Allowed for a single data push of up to 80 bytes.
  • See pull request #5286
• Bitcoin v0.12.0 (February 2016) — Allowed for multiple data pushes, but with a maximum total script size of 83 bytes.
  • Although the limit was changed to a total script size of 83 bytes, due to the overhead of preceding data push opcodes the maximum size for a single data push was still limited to 80 bytes.
• Bitcoin v0.30.0 (October 2025) — Limit removed. The size of OP_RETURN scripts is now only limited by the maximum size of a standard transaction.
  • Multiple OP_RETURN outputs are now allowed per transaction.
  • See pull request #32406

Examples

Where can you find OP_RETURN scripts?

Anyone can use an OP_RETURN script to store some data in a transaction, and you can find them scattered around the blockchain:

ASCII

tool-686993fb8482b

ASCII

Convert between bytes (in hexadecimal) and ASCII characters.

Example Hex

0 bytes

Bytes

 

ASCII

0 characters

• The hex bytes between 0x20 and 0x7f contain the printable characters.
• Anything 0x1f or below is a control character (will not display, or will display a weird character).
• Anything 0x80 or above will show nothing.

See the ISO 646 encoding standard for details.

0 secs

Example 1 — hello world

OP_RETURN
OP_PUSHBYTES_11
68656c6c6f20776f726c64

6a0b68656c6c6f20776f726c64

Example 2 — charley loves heidi

OP_RETURN
OP_PUSHBYTES_19
636861726c6579206c6f766573206865696469

6a13636861726c6579206c6f766573206865696469

Example 3 — Amazing!

OP_RETURN
OP_PUSHBYTES_8
416d617a696e6721

6a08416d617a696e6721

Example 4 — First OPReturn Message I was here :)

OP_RETURN
OP_PUSHBYTES_36
4669727374204f5052657475726e204d6573736167652049207761732068657265203a29

6a244669727374204f5052657475726e204d6573736167652049207761732068657265203a29

Example 5 (wTXID Commitment)

Since the Segregated Witness upgrade, the OP_RETURN locking script is used within the coinbase transaction to store the wTXID Commitment:

OP_RETURN
OP_PUSHBYTES_36
aa21a9ed6502e8637ba29cd8a820021915339c7341223d571e5e8d66edd83786d387e715

6a24aa21a9ed6502e8637ba29cd8a820021915339c7341223d571e5e8d66edd83786d387e715

This data push is not ASCII-encoded text. It's just a bunch of bytes, so there's nothing interesting to be found by converting it to ASCII.

If you want to find OP_RETURN scripts in the blockchain, look for outputs with zero amount values. This is because OP_RETURN scripts are unspendable, so they're almost always placed on "empty" outputs.

Purpose

Why do we have OP_RETURN scripts?

OP_RETURN was introduced as a standard locking script in Bitcoin 0.9.0 as a compromise to allow people to include arbitrary data inside transactions.

You see, before OP_RETURN was available, people were adding data to transactions by using the existing standard locking scripts. For example, here's how I could store the text string "learnmeabitcoin" in the place where the public key hash would go in a standard P2PKH locking script:

OP_DUP
OP_HASH160
OP_PUSHBYTES_20
00000000006c6561726e6d6561626974636f696e
OP_EQUALVERIFY
OP_CHECKSIG

76a91400000000006c6561726e6d6561626974636f696e88ac

ASCII

tool-686993fb84902

ASCII

Convert between bytes (in hexadecimal) and ASCII characters.

Example Hex

0 bytes

Bytes

 

ASCII

0 characters

• The hex bytes between 0x20 and 0x7f contain the printable characters.
• Anything 0x1f or below is a control character (will not display, or will display a weird character).
• Anything 0x80 or above will show nothing.

See the ISO 646 encoding standard for details.

0 secs

This works, but the problem with this approach is that there's no way for a Bitcoin node to know that it is unspendable, so the output would be stored in the UTXO database forever (which is a permanent waste of RAM).

So this is where the OP_RETURN locking script comes in:

OP_RETURN
OP_PUSHBYTES_15
6c6561726e6d6561626974636f696e

6a0f6c6561726e6d6561626974636f696e

This script contains OP_RETURN, which means it provably unspendable and therefore does not need to be stored in the UTXO database (which saves on precious RAM space when Bitcoin is running).

Using the blockchain for data storage isn't ideal, but you can't stop people from doing it. Therefore, the OP_RETURN script acts as a more reasonable alternative for data storage than previous methods.

Notes

Resources

• Bitcoin Developer Guide — Null Data
• Explanation of what an OP_RETURN transaction looks like
• OP_RETURN marks transaction or output as invalid
• OP_RETURN 40 to 80 bytes