Unsigned Transaction

Overview

What it means in plain English

An unsigned transaction is a constructed transaction that lacks one or more cryptographic authorizations required for submission or execution. It can be reviewed, transported to an offline signer, or combined with approvals before broadcast. Because the fields are not yet protected by final signatures, the recipient, amount, fees, nonce, and network context must be verified at signing time. Practical use requires recognizing that nonce, input, fee, or recent-block assumptions can become stale before approval is completed.

How it works and why it matters

An unsigned transaction contains the intended transaction fields but not the complete Transaction Signature set required by the protocol or account policy. It may be a binary message, partially signed object, JSON structure, or hardware-wallet request. The format should clearly indicate which signatures are missing and which fields will be covered by each signer.

Unsigned transactions support separation of duties. An online system can gather chain state and construct the transaction, while an isolated signing device controls the Secret Key. Multisignature workflows can pass the same transaction among participants. However, the construction system remains untrusted: it can insert a malicious recipient, fee, contract call, or network unless the signer independently decodes the payload.

The object can become stale before signing. Its nonce, inputs, recent block reference, fee estimate, or validity window may expire or conflict with another transaction. Rebuilding it can change the signing digest and invalidate existing partial signatures. Workflows should therefore track version, creation time, chain ID, and the exact bytes approved by each participant.

After all required signatures are added, the system should verify the complete Signed Transaction locally before broadcast. Audit records should link the human-approved intent, unsigned bytes, signer approvals, final serialized bytes, and transaction identifier. An unsigned transaction is a proposal for authorization, not proof that funds will move.

For dependable operation, store the construction source, network, expiry conditions, intended fields, and signatures still required. This information is valuable because nonce, input, fee, or recent-block assumptions can become stale before approval is completed. Monitoring and response procedures should revalidate the object before every signature and verify the final signed bytes before broadcast.

Worked example

A corporate wallet prepares a payout to a vendor but must obtain approval from two authorized operators before broadcasting it. The unsigned transaction contains the intended destination, amount and fee conditions. Signing converts authorization into a network-verifiable instruction; it does not guarantee eventual inclusion.

Practical checks and common confusion

Review exact bytes or human-readable intent before signing. If a fee, output or recipient changes, the approved unsigned payload and the eventual signed transaction may no longer be equivalent. Signing is not the same as settlement or receipt by the vendor.

Learn the related concepts

Transaction Recipient Transaction Trace