Bitcoin Core createrawtransaction RPC: Unsigned Construction Guide

This guide explains Bitcoin Core createrawtransaction RPC in plain English. It shows what the command does, what its result means and what it cannot prove.

Input outpoints

Each input specifies a txid and output index, with an optional sequence. Verify that every outpoint exists on the intended network, is unspent under the required confirmation policy and belongs to the authorised funding source. Record value and script from an independently validating node because the raw constructor does not retrieve or confirm them for business approval.

Address and data outputs

The output object maps destination addresses to BTC amounts and may include a data key containing hex. Validate network, decoded script and exact amount before construction. Data outputs are provably unspendable and consume block space; enforce a narrow organisational policy and reject arbitrary customer-supplied payloads, secrets or personal information.

Amount and fee arithmetic

Historical help labels payment amounts in BTC and accepts numeric or string values. Convert authorised integer satoshis with fixed decimal arithmetic and never depend on binary floating-point. Sum known input values minus output values to derive the fee, then divide by final virtual size. A raw transaction can encode an accidental excessive fee without warning.

Locktime and sequence

A non-zero locktime also activates locktime behaviour on inputs, while explicit sequence values can alter relative lock semantics and replaceability. Model block-height versus timestamp locktime and validate every sequence. Incompatible explicit sequences cause an error when replaceable is requested; implicit defaults should still be decoded and reviewed.

BIP 125 signalling

replaceable defaulted to false in the historical interface and could mark the transaction for opt-in replacement. Signalling does not guarantee replacement acceptance, while unconfirmed replaceable ancestors can affect practical replacement. Decide policy before signing, not after broadcast, and show it in the approval summary.

Unsigned lifecycle

The returned hex contains no signatures and is not automatically recorded or broadcast. Give it a unique request identifier, hash the unsigned fields and pass it through authenticated signing channels. Keep construction, signing and broadcast credentials separate so compromise of a stateless builder cannot spend funds.

How specialists test it

Operators test the command on a non-production node first. They check a normal reply, an invalid request, a timeout and a restart. This shows what the response means and prevents one local result from being mistaken for a network-wide outcome.

Conclusion

createrawtransaction is an unsigned serialisation tool, not a wallet or fee safety system. Secure use requires independently verified inputs, exact output arithmetic, explicit sequence policy and a separate signing and broadcast approval chain.