A transaction with a 77 bytes OP_RETURN is refused, but with shorter data (e.g. 74 bytes) is accepted, although up to 80 bytes should work.

What is the safe limit to be used?

Per these references the maximum length is 80 bytes (83 for whole script) (since v 0.11):

https://stackoverflow.com/questions/24845429/maximum-size-of-data-bitcoin-op-return-tx-can-handle https://developer.bitcoin.org/devguide/transactions.html#null-data

The below transaction produces error: {"error":"-26: scriptpubkey"}. Similar transactions with slightly shorter OP_RETURN are fine.


    "data_hex": "535741503a ...",
    "script": "6a4d535741503a ...",
    "script_type": "null-data",
    "value": 0

Note: use case is client for thorswap.finance cross-chain DEX.

  • This OP_RETURN contains 78 bytes in one push, however, it seems the max length for a push is 75 bytes. See en.bitcoin.it/wiki/Script . Therefore this is in fact an invalid script, the byte 78 following OP_RETURN in fact is interpreted as OP_PUSHDATA4, not as length 78.
    – Adam B
    Nov 22, 2022 at 10:20

1 Answer 1


UPDATE: The first version of this answer suggested using two data pushes, updated to use OP_PUSHDATA1.

Further research has clarified the issue:

  • OP_RETURN max data length is 80 bytes, however
  • Maximum bytes in one push data is 75 bytes.
  • Therefore data of sizes between 76 to 80 need to be encoded with OP_PUSHDATA1!

The script in this transaction is in fact invalid, 6a 4d 53 57 should be interpreted as OP_RETURN OP_PUSHDATA2 53 57, after which 22355 (0x5753) bytes are expected.

Correct encoding would be to use OP_PUSHDATA1 for data of length 76 to 80 bytes.

50 6a 4c 4d <77 bytes> OP_RETURN OP_PUSHDATA1 4d <77 bytes>

  • 2
    Can't you use the 2-byte push OP, e.g. 6a 4c 4e data_78_bytes ? Nov 22, 2022 at 14:00
  • 2
    Right, probably the correct solution is to use OP_PUSHDATA1. This is probably better than 2 separate pushes. OP_PUSHDATA2 is not supposed to be used with len<256 (I've removed my previous misleading comment).
    – Adam B
    Nov 22, 2022 at 14:27
  • 1
    Looks like the block explorer has a bug, it's assuming a 1-byte push op and decoding the length byte as the 1st character of your message :) Here's how it should look like: 6a 4c 50 4d 454d4f5f35363738395f3132333435363738395f3132333435363738395f3132333435363738395f3132333435363738395f3132333435363738395f3132333435363738395f313233343536373839 == OP_RETURN OP_PUSHDATA1 0x4e "EMO_56789_123456789_123456789_123456789_123456789_123456789_123456789_123456789" Nov 23, 2022 at 5:43
  • 1
    I think in this case it shows correctly. 4c is OP_PUSHDATA1, 50 is length (=80), and 4d (=M) is the first character of the data. I don't know of other explorers supporting testnet.
    – Adam B
    Nov 23, 2022 at 10:13
  • 1
    You're right, sorry for the confusion, I had read it wrong and thought I saw an error while it was actually correct, the message is "MEMO..." I mixed up the "M" for the length. Yeah I noticed this with blockchair - it decodes the push op to ASCII, too. Nov 24, 2022 at 9:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.