Write a permanent message to the Bitcoin blockchain. Type it below, then follow the steps for your wallet. Nothing you type is sent anywhere.
That looks like hex, not text. Entered as text it gets encoded a second time, which doubles the size and publishes the wrong bytes. The command would still look correct.
That looks like base64, not hex. This field takes hex, so the two need converting first.
Both are self-custody. You hold the keys and sign the transaction either way. The full node path adds privacy and verification: your own node builds and broadcasts the transaction instead of a company server doing it for you.
Too long for this path. Your message is 0 bytes and Trezor Suite will not send more than 80. Shorten it, or use a full node instead.
Everything here happens in Trezor Suite, the desktop app for your Trezor device. The message rides along on a normal payment. Simplest version: send a small amount to a fresh receive address in your own account, so the coins come right back to you and you only pay the miner fee.
In Trezor Suite, open your Bitcoin account and start a send like any normal transaction.
Click the small three-dot button in the top-right corner of the Send screen, above the Total panel, and choose Attach message. It is easy to miss. Not the Add label pencil next to the address field. That one is a private note stored on your computer only and never touches the blockchain.
Use the left box, the plain text one. Emoji work fine, Suite converts them for you. The hex box on the right fills automatically, and it will match the hex encoding shown above. Copy your message from below.
Enter the recipient address and amount, review the transaction, and confirm on the device screen. The amount can be tiny. Around 1,000 sats to your own fresh receive address works well, and the network minimum is a few hundred sats. Your only real cost is the miner fee, since the coins come back to you.
Search the transaction ID on mempool.space. The explorer decodes the OP_RETURN output back to readable text on the transaction page.
This path needs a wallet inside Bitcoin Core itself, created with createwallet and holding some bitcoin. That wallet is separate from any hardware wallet. If your node just verifies blocks and your coins live on a Trezor or other signing device, send a small amount to a Core wallet address first, since Core needs coins it controls to fund and sign the transaction. Your message is already substituted into the commands below.
No terminal needed. The Bitcoin Core app has a built-in console: Window menu, then Node window, then the Console tab. Pick below where you'll run the commands and they reformat to match, so what you copy is exactly what you run. The console shows a red warning about scammers who trick people into pasting commands. That warning is right, and the rule it implies is the one to follow: never run commands you don't understand. Each step below says what its command does, so read before you run.
Core picks an unspent output from your wallet to fund the transaction, adds the OP_RETURN output with your message, and sends change back to you. It returns a PSBT, a partially signed bitcoin transaction. That is a draft transaction waiting for a signature.
Payload: 0 bytes
Paste the psbt value from step 1 between the quotes. Your wallet signs the transaction.
Paste the psbt value from step 2. Core converts the signed PSBT into raw transaction hex ready for broadcast.
Paste the hex value from step 3. This sends the transaction to the network and returns your transaction ID.
Search the transaction ID on mempool.space, or in your own explorer if you run one. The OP_RETURN output decodes back to readable text on the transaction page.
An OP_RETURN output attaches a small piece of data to a Bitcoin transaction. Once that transaction confirms, the data is copied to every full node on Earth, stamped with a block time nobody controls, and it stays there. Public, timestamped, and beyond anyone's reach to alter. That combination is the whole reason people use it.
Publish the hash of a document (instructions below), and you have proof that the exact file existed before that block was mined. Useful for manuscripts, designs, research data, and disclosures, without revealing the contents.
Contracts, audit logs, and records can be anchored to a block. Anyone can later verify the anchor themselves. There is no notary to trust, and no service that can go out of business and take the record with it.
Certificates, credentials, and supply-chain events can be committed on-chain so their history is checkable by anyone, forever, rather than living in one company's database.
A statement written into a block cannot be taken down, edited, or de-platformed. No host, registrar, or moderator sits between the message and the people reading it.
Other systems use OP_RETURN as a machine-readable tag: asset issuance, sidechain pegs, layer-two commitments, and cross-chain proofs all ride on it.
Memorials, dedications, and messages people simply want kept. It costs a few cents and it outlives every website you could otherwise put it on.
A hash is a short fingerprint of a file. Publishing the fingerprint instead of the file proves you had that exact file on that date, while revealing nothing about what is in it. Anyone can run the same command on their copy years later and see whether it still matches.
shasum -a 256 yourfile
That works on macOS and Linux. On Windows it is certutil -hashfile yourfile SHA256. Either way it prints 64 characters. Paste those into the Hex tab at the top and you are publishing the fingerprint of the file, not the file itself.
It is a tiny, permanent, public noticeboard. Almost every mistake people make with it comes from expecting one of these six things to be otherwise.
80 bytes is the safe limit. That is about one sentence. Watch out for accented letters and emoji, which use several bytes each: a plain emoji costs four, and one with a skin tone or built from several joined together can cost eight or more. The counter above shows the real cost as you type. You can go longer, but only by sending with Bitcoin Core v30 or newer, and even then some of the computers that make up the Bitcoin network may refuse to pass your message along, and nothing will tell you it happened. Trezor Suite will not send more than 80 bytes at all.
There is no delete. Once it confirms, it is on every node forever. It cannot be edited, retracted, or taken down by you or anyone else. Read your message twice before you broadcast it.
It is not encrypted. Anyone can read it in any block explorer, and it is permanently linked to the transaction that carried it, which may connect it to your other addresses. Never write anything private, identifying, or regrettable.
It stores a fingerprint, not a file. You cannot put an image, a PDF, or a contract on-chain this way. The normal pattern is to publish a hash on-chain and keep the actual file elsewhere. The chain proves the file has not changed, but it does not host it.
Nothing can ever be spent from it. The part of the transaction that carries your message holds no bitcoin, and no key exists that could unlock it. The network does not even keep it on the list of coins that can be spent. Any bitcoin sent there is destroyed for good. Your own money travels in the other parts of the same transaction and comes back to you as normal.
One message per transaction, and it costs a fee. Assume one. That is the rule older nodes enforce, so it is what travels reliably. Bitcoin Core v30 and newer allow several in a single transaction, the same change that raised the size limit, but older nodes may not pass those on. Either way you pay the normal Bitcoin fee for the extra bytes, and it takes just as long to confirm as any other transaction.