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. Practical use requires recognizing that opaque hexadecimal can hide a different recipient, fee, or contract call from the operator.
Overview
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.
Key Takeaway
A raw transaction is the exact protocol payload used for signing or broadcast, so it should always be decoded and verified before authorization.
Sources
- Bitcoin Transaction Reference — Bitcoin.org (2026-08-02)
- Ethereum Transactions — Ethereum.org (2026-08-02)
- Solana Transaction Structure — Solana Foundation (2026-08-02)