Broadcasting Transactions

Broadcasting is the final step that hands a fully signed transaction to the Bitcoin network so miners can include it in a future proof-of-work block. On Bitcoin there is no account or smart-contract layer to mutate — a spend is just a self-contained, signed message that moves value from existing unspent outputs to new ones. The usual path is four stages: build an unsigned skeleton from the inputs and outputs you choose, sign it locally, dry-run it against mempool policy, then push the signed hex to https://bitcoin.therpc.io/YOUR_API_KEY with sendrawtransaction. Signing always happens client-side because the transaction commits to your private keys; the public RPC never holds key material and only constructs, validates, and relays the bytes you give it. That separation keeps your keys off the wire while still letting a single endpoint do the heavy lifting of mempool checks and propagation.

The Broadcast Flow

• createrawtransaction takes an explicit list of inputs (each a txid plus vout) and a map of outputs (address to BTC amount) and returns unsigned transaction hex. It does no coin selection, adds no change, and funds nothing — you must already know which UTXOs you are spending and account for the fee yourself by leaving the difference between inputs and outputs unspent.
• Signing is the client's job. A wallet or a library such as bitcoinjs-lib holds the private keys and produces the signatures and witnesses. The TheRPC endpoint is keyless by design, so it can never sign for you; you send it only the finished signed hex.
• testmempoolaccept runs a full policy dry-run on a signed transaction and returns an array whose entry carries allowed (true/false) and, on failure, a reject-reason — all without touching the network. Use it to catch fee, dust, and conflict problems before you commit.
• sendrawtransaction broadcasts the signed hex to peers and returns the 64-character txid on success. Once it returns a txid the transaction is in the mempool and propagating; confirmation follows when a miner includes it in a block.

Validate then Broadcast

1// Dry-run acceptance before broadcasting
2const broadcast = async (signedHex) => {
3  const [check] = await rpc('testmempoolaccept', [[signedHex]]);
4  if (!check.allowed) {
5    throw new Error(`Rejected: ${check['reject-reason']}`);
6  }
7 
8  // Accepted by policy — broadcast for real
9  const txid = await rpc('sendrawtransaction', [signedHex]);
10  return txid;
11};

Handling Rejections

• -26 (rejected by mempool) means the transaction is well-formed but breaks a policy rule — most often a fee below the minimum relay floor, an output below the dust threshold, or an input that conflicts with a transaction already in the mempool. The accompanying text names which rule failed.
• -27 (transaction already in block chain) means an identical transaction has already confirmed. This is not a real failure: treat it as success, because the coins have already moved.
• -22 (TX decode failed) means the hex is malformed or truncated — re-check that you sent fully signed hex and not the unsigned skeleton or a JSON blob.
• The default maxfeerate safety cap is 0.10 BTC/kvB. A deliberately high-fee transaction (for example a fee-bump on a congested mempool) can trip this guard and be rejected. When you genuinely intend the high fee, pass maxfeerate as 0 to sendrawtransaction to disable the cap.
• Read the reject-reason from testmempoolaccept first. It pinpoints the exact policy problem — min relay fee not met, dust, txn-mempool-conflict — so you can raise the fee, drop a dust output, or pick different inputs before you ever broadcast.

Best Practices

• Always dry-run with testmempoolaccept in production before calling sendrawtransaction. A failed broadcast can leave your application unsure whether the transaction propagated; a clean dry-run turns that ambiguity into a deterministic check you can branch on.
• Use opt-in RBF (BIP-125). Set the input sequence below 0xfffffffe so the transaction is replaceable, and you can later broadcast a higher-fee version to unstick it during congestion instead of waiting indefinitely. Without RBF a too-cheap transaction can sit in the mempool for hours.
• A single broadcast endpoint reveals the transaction origin. Because the first node to relay a transaction is observable, broadcasting everything through one endpoint links your spends together at the network layer. After broadcasting, immediately start tracking confirmations against the chain tip rather than assuming the txid alone means settlement.
• Make broadcast idempotent. Retries are normal on flaky networks, so treat a -27 (already in chain) response as success: it proves the transaction is already mined. Persist the txid before you broadcast, and on retry check the chain for that txid instead of blindly re-sending.

See also

• sendrawtransaction - Broadcast a signed raw transaction
• testmempoolaccept - Dry-run mempool acceptance before broadcasting
• createrawtransaction - Build an unsigned raw transaction