Raw Transaction
Pronunciation: RAW tran-ZAK-shun
Definition
A raw transaction is a transaction represented in its protocol-native serialized form before or after signatures are added. It is commonly displayed as hexadecimal, base64, or binary-encoded data suitable for signing, decoding, or broadcasting. Raw transactions are powerful for APIs and offline workflows, but a user should decode and verify every field before authorizing them.
Overview
How it works and where it fits
A raw transaction is the machine-readable transaction object used by a node or signing system. It contains the fields required by the network, such as inputs or sender, outputs or recipient, amounts, fees, nonce, instructions, and optional signatures. The representation is usually a Serialized Transaction encoded as bytes and then displayed in hexadecimal or base64 for transport through tools and APIs.
“Raw” does not necessarily mean unsigned. Some software uses the term for an unsigned template, while other APIs return a fully signed transaction ready for broadcast. The status must be determined from the format and the presence of valid transaction signatures. A raw transaction can also be validly encoded but invalid under current chain state because its inputs are spent, nonce is wrong, or fee conditions are no longer acceptable.
Offline signing workflows often construct raw transactions on an online system, transfer them to an isolated signer, and return the signed bytes for submission. This reduces private-key exposure, but only if the signer independently displays and verifies the decoded recipient, amount, network, contract call, and fee. Signing an opaque byte string without trusted decoding can authorize a malicious transaction.
Developers should store both the original raw bytes and a normalized Decoded Transaction for audit and reconciliation. They should avoid mutating the payload after signatures are produced, because even a one-byte change usually invalidates them or changes the transaction identifier. Broadcast systems must handle duplicate submission safely and record node responses, replacements, and the eventual on-chain result.
Useful operational records include the exact raw bytes, chain identifier, decoder output, signing state, and broadcast response. They are necessary because opaque hexadecimal can hide a different recipient, fee, or contract call from the operator. Systems should also compare the reviewed bytes with the signed and submitted bytes before accepting the audit trail.
Related glossary concepts
Transaction Size; Signed Transaction; Transaction Sequence
Primary reference
Example
A wallet builds an unsigned Bitcoin transaction containing version, inputs, outputs, sequences and locktime. After proper signing, it serializes the transaction to bytes for broadcast. The hexadecimal representation is commonly called a raw transaction; it is data encoding, not proof that nodes have accepted or confirmed the transfer.
Comparison
Raw does not mean unsigned: it can describe either unsigned or fully signed serialized data depending on tooling. Decode and inspect chain-specific fields, especially destinations, values and fees. Do not publish secrets or private keys; raw transactions normally contain public transaction data, but some workflows may embed sensitive application information.
Key Takeaway
Serialized transaction data is not proof that a transfer was broadcast, accepted or confirmed.
Sources
- Bitcoin Transaction Reference — Bitcoin.org (2026-08-02)
- Ethereum Transactions — Ethereum.org (2026-08-02)
- Solana Transaction Structure — Solana Foundation (2026-08-02)