Writing Data to the BSV Blockchain: From OP_RETURN to Application Protocols

BSV transactions can do more than transfer satoshis. Through data outputs, you can record text, hashes, protocol fields, or business events on-chain. The significance of the first Hello BSV! transaction lies exactly in this: it demonstrates that a transaction can both express payment and serve as a verifiable data record.

Data Output vs. Payment Output

A typical payment output expresses “who can spend this money in the future”. Its locking script is commonly in the form of P2PKH or other spendable scripts.

A data output, on the other hand, focuses on “what data is recorded in the transaction”. The common approach is to use OP_RETURN. Such outputs are usually not intended for future spending but to carry data.

Simplified comparison:

In the official first transaction tutorial, the example uses OP_RETURN to write Hello BSV!.

Constructing an OP_RETURN with the SDK

In the SDK, you can create a script from its ASM representation using Script.fromASM():

The code consists of three steps:

1. Convert the text to bytes: Buffer.from(message)
2. Represent the bytes as a hexadecimal string: toString('hex')
3. Combine OP_RETURN and the data into a script, then convert to hex: Script.fromASM(...).toHex()

Then place this script into the outputs of createAction():

This is the minimal path to “write data on-chain”.

Why Convert to Hexadecimal

On-chain transactions are not a document system that stores “human-readable strings”. Transaction scripts process byte data, and hexadecimal is a common way to represent bytes.

Hello BSV! is a string in code, but when placed in a script it must become a sequence of bytes. Block explorers might parse this data back into text, or they might only display the hex representation.

Therefore, beginners need to distinguish three levels:

Understanding this makes it much easier to look at various on-chain protocol fields later.

From Free Text to Application Protocols

Writing Hello BSV! is good for getting started, but real applications should not stop at free text.

If you need to record articles, credentials, orders, supply chain events, or token states on-chain, it’s better to design a structured protocol. A simple data output can include:

• Protocol identifier
• Protocol version
• Content type
• Data hash
• Business fields
• Signature or identity information
• Reference to off-chain large files

Example:

This is not a fixed standard, but it illustrates the idea. On-chain data should be parseable, verifiable, and indexable by others. Protocol design is more important than merely being able to write data.

Position in the BSV Tech Stack

The BSV technical roadmap emphasizes low fees, high capacity, and on-chain data applications. Data outputs are the foundation for many application protocols, including content publishing, credentials, certificates, supply chain events, token metadata, and audit records.

However, on-chain data does not mean blindly stuffing everything into a transaction. Mature applications typically combine:

This article focuses on the simplest data output; later stages will further develop application data protocols.

Privacy and Irreversibility

On-chain data should be treated as public, easily copied, and difficult to retract by default.

Do not write ID numbers, phone numbers, unencrypted private text, trade secrets, or data not authorized by users directly into OP_RETURN.

If you need to prove the existence of certain private data, write a hash instead of the plaintext. A hash can prove that a specific version of the data existed, but it does not directly expose the original content.

If encryption is necessary, carefully design key management. Even if encrypted data on-chain is unreadable now, a future key leak could allow the content to be read.

Common Misunderstandings for Beginners

• Being able to write data does not mean the data has business meaning. Without a protocol identifier and field specification, others will struggle to parse it correctly.
• OP_RETURN data outputs are typically not intended for future spending; their purpose differs from ordinary payment outputs.
• Seeing data in a block explorer does not mean your application has indexed it—you still need your own query mechanism.
• On-chain data is not a private database; prioritize privacy and compliance for public data.
• Writing data does not automatically grant a trusted source; trust comes from signatures, identity, protocols, and verification logic.

References

• First Transaction tutorial
• Script docs
• Overlay Services docs
• Script Templates concept