What Is a Raw Transaction? The Basics of BSV Transaction Serialization, TXIDs, and Signatures

In BSV development, a raw transaction is the original byte representation of a transaction after it has been serialized according to protocol rules. It is usually displayed as a hexadecimal string.

In one sentence: the transaction object you work with in code must eventually be serialized into deterministic byte data before its TXID can be calculated, signatures can be generated, and the transaction can be broadcast to the network.

Why Raw Transactions Are Needed

Developers usually prefer to work with structured objects in code, such as:

This format is easy for humans to read and convenient for organizing program logic. However, the blockchain network does not transmit objects with field names. Nodes transmit and process bytes arranged according to protocol rules.

A raw transaction is the hexadecimal representation of that byte sequence.

Serialized transaction data typically includes:

• Version
• Input count
• The outpoint for each input
• The unlocking script for each input
• The sequence for each input
• Output count
• The amount for each output
• The locking script for each output
• Locktime

Different transaction formats and protocol upgrade details may vary, but the core requirement remains the same: a transaction must have a deterministic serialized representation. This allows different nodes and tools to parse the same transaction, verify signatures, and derive the same transaction identifier consistently.

The Relationship Between Raw Transactions and TXID

A TXID is usually calculated from the serialized transaction data. At a high level, the process can be understood as:

In other words, the TXID depends on the underlying byte data. If the serialized result changes, the TXID may change as well.

This is why field order, byte encoding, script content, and signature data all matter. Even if something appears to be “the same payment” from a business perspective, different underlying bytes may make it a different transaction.

The Relationship Between Raw Transactions and Signatures

Transaction signatures also depend on the serialized form of the transaction.

When signing, a wallet or SDK constructs the data digest to be signed according to protocol rules. This digest is derived from the transaction content and relevant information about the output being spent.

Therefore, if you manually modify the output amount, script, or input reference inside a raw transaction, the original signature will very likely become invalid. A signature is not a decorative field attached independently to a transaction; it is bound to specific transaction content.

For this reason, a raw transaction is not a string that should be freely spliced together or edited by hand. When constructing or modifying transactions, use the serialization and signing logic provided by an SDK or wallet.

How to View a Raw Transaction

Block explorers, wallet tools, and SDKs can usually display the raw transaction for a given transaction.

When learning, it is useful to inspect the same transaction in two ways:

1. Human-readable view: Review the parsed fields such as inputs, outputs, fees, and scripts.
2. Raw transaction hex: Review the actual network-encoded form.

This helps build an important understanding: what a block explorer page shows is a parsed view, while what is actually stored, propagated, and verified on-chain is serialized transaction data.

A Raw Transaction Is Not JSON

This is a common source of confusion for beginners.

JSON is a widely used application-layer data format. It has clear field names and is easy to read and debug. Bitcoin/BSV transaction serialization, however, is not JSON. It is a compact binary protocol format.

For example, the following is incorrect:

Calling JSON.stringify on a transaction object does not produce a raw transaction. The correct approach is to use the BSV SDK, a wallet, or protocol-compliant serialization logic to encode the transaction into the byte format specified by the protocol.

Common Debugging Scenarios for Raw Transactions

In day-to-day development, you usually do not need to write raw transactions by hand. But when transaction construction, signing, or broadcasting fails, the raw transaction becomes essential debugging material.

Common scenarios include:

• The TXID does not match expectations
• Signature verification fails
• An input references the wrong outpoint
• An output amount or script is incorrect
• Fees are abnormal
• Transaction broadcast is rejected
• Endian display causes confusion
• SDK results differ from service responses

In these cases, structured objects or page views may not be enough to identify the cause. The raw transaction lets you return to the byte level and confirm exactly what the transaction is.

Practical Advice for BSV Development

For new developers, it is best to use an official SDK or a mature wallet to construct raw transactions rather than writing serialization logic by hand.

However, you should still understand what a raw transaction is, because:

• Broadcast APIs commonly submit a raw tx
• Services such as ARC process actual transaction data
• The blockchain stores transaction bytes
• TXIDs and signatures both depend on the serialized result
• SPV proofs ultimately bind to a specific transaction

Understanding raw transactions helps you move from “I can call the SDK” to “I can explain what the SDK is doing.” This is especially useful when troubleshooting signatures, broadcasting, scripts, and transaction structure.

Common Beginner Misconceptions

Use the following points as a quick self-check:

• A raw transaction is not JSON
• A raw transaction is not a block explorer page
• Modifying transaction fields may affect the TXID and signatures
• When copying a raw tx, confirm the network, status, and source
• Writing a raw tx by hand is error-prone; prefer using an SDK
• When debugging low-level issues, the raw tx is one of the most important materials

References

• Transaction Inputs and Outputs
• Advanced Transaction Construction
• BSV TypeScript SDK