When Bitcoin itself became the communication channel

On 6 September 2026 a weakness was exploited in Elements, the software Liquid Network is based on.

According to SideSwap's official report, the flaw made it possible to create roughly 4,000 L-BTC that were not backed by a real Bitcoin deposit. The L-BTC was moved into SideSwap's peg-out mechanism, and at the end of the process roughly 3,996 real BTC were released from the Liquid Federation to an address controlled by the party who performed the operation.

This was not a theft of SideSwap's private keys. According to the company, the transaction passed through a peg-out mechanism that was valid in terms of its own permissions, after the system received L-BTC created through the bug.

That was about 320 million dollars of Bitcoin at the time. But the part that interests us most began afterwards.

Not a chat. Not Telegram. Not Signal. And at significant stages of the event, instead of relying on an ordinary private channel, the parties began talking through Bitcoin itself.

The party holding the bitcoin published an OP_RETURN message from inside a transaction: "contact us on chain".

Blockstream replied with transactions of its own, and a sequence of on-chain messages developed. Some of the communication was carried as text encrypted with PGP inside OP_RETURN.

In one message the party holding the funds demanded that Blockstream first fix the bug and confirm that all the relevant nodes had been updated. Blockstream then published a PGP-signed message announcing that the bridge nodes were fixed and the funds could return safely.

All of this happened through Bitcoin transactions. There was no message server at the centre of the conversation. The messages themselves were written into the blockchain.

On 7 September, one day after the event, exactly 3,400 BTC were returned to a Liquid Federation address. About 598.5 BTC stayed on the other side as change from that same transaction. Roughly 85 percent of the bitcoin came back.

The transaction that returned the funds confirmed in block 965,950.

Here OP_RETURN takes on a much more interesting meaning than a mere data field. In a case where hundreds of millions of dollars were at stake, Bitcoin served at the same time as the settlement layer and as one of the communication channels between the parties. The same system that confirmed the return of the 3,400 BTC also carried the messages that preceded it.

OP_RETURN is a special output in a Bitcoin transaction. Unlike a normal output, it does not send bitcoin to an address that money can be spent from. It marks the output as unspendable and allows a small amount of data to be included inside it.

In the case of a simple message, the transaction has three parts:

• Inputs. Bitcoin from the UTXO you chose funds the transaction.
• OP_RETURN. Holds the message. Its value: 0 sats.
• Change. Everything left after paying the network fee returns to your wallet.

No recipient. No destination address. No person who receives the message. The message belongs to the transaction itself. Its address, in a sense, is the TXID.

This is probably the strangest part the first time you use OP_RETURN. The screen does not ask for a Bitcoin address, because there isn't one.

In TZUR 3.2.9 we are adding the ability to create an On-chain Message directly from the wallet. Not as part of the regular Send. Not as a feature shown to every user. And not as a messaging system. This is a capability for advanced Bitcoin users.

The feature is off by default and can be enabled under Settings, Privacy, Show Advanced Bitcoiner, On-chain Messages (OP_RETURN).

Only after it is enabled does a small pill appear on the wallet's detail screen, below Receive and Send. The regular Send screen is untouched. To prevent accidental entry, an ordinary tap does nothing: you press and hold the Send OP_RETURN button while it fills gradually, and only when the hold completes does the flow open.

This is deliberate. TZUR should stay simple for anyone who only wants to receive and send Bitcoin, while giving advanced users access to deeper capabilities of the protocol.

In the first version of the feature TZUR is deliberately conservative. You can write a UTF-8 message of up to 80 bytes.

Not 80 characters. 80 bytes. The difference matters: Hebrew, Arabic and emoji characters can use more than one byte each. So TZUR shows a live byte counter, for example 42 / 80 bytes.

No images. No files. No inscriptions. No storage layer. No feed. Just a small message inside a standard Bitcoin transaction.

Because there is no destination address, the numbers on the confirmation screen are different from a normal send. The transaction contains an OP_RETURN output worth 0 sats, and the change returns to your wallet.

• Bitcoin sent: 0 sats.
• Network fee: the real cost of the transaction.
• Message: the data about to be written.
• And most importantly: public, permanent, and it cannot be edited or deleted.

OP_RETURN is public. But it is not only the message that is public. The transaction that funded it is on Bitcoin too.

If you use a UTXO already linked to your identity, your company or your previous activity, that link can exist against the message you published as well.

So TZUR combines the feature with its existing Coin Control tools. An advanced user can choose which coin funds the transaction. It is a small detail in the UX, but a large principle in Bitcoin: UTXO selection is information selection. The coin you spend can say something about you.

We do not want to create a private message history inside TZUR. The blockchain is the source of truth.

When TZUR syncs the wallet it can identify a transaction belonging to the wallet, read the raw transaction, find the OP_RETURN output and decode the data. So an On-chain Message can reappear after restarting the app, a resync, clearing the cache, or a full restore of the wallet from the seed on a new device.

In the history screen it does not appear as "Sent 0 BTC". It appears as an action with a meaning of its own: On-chain Message, with the message itself below it and the network fee that was paid to publish it.

The Liquid case is extreme. Almost 4,000 BTC left the system, 3,400 BTC came back, and along the way a chain of public communication was created using OP_RETURN and PGP.

We are obviously not building the feature because the average user needs to negotiate over hundreds of millions of dollars. We are building it because that case illustrates something more basic.

Bitcoin is not only a balance. A transaction can also carry information. That information can be very small. But the moment it enters the chain it takes on the same basic properties as Bitcoin: it is public, it is verifiable, it does not depend on a TZUR server, and it does not disappear if TZUR disappears.

That is exactly why we want to give the advanced user access to it. Not to hide Bitcoin behind a simple interface, but to let anyone who wants to go deeper.