Unsigned Transaction

Overview

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.