Signed Transaction
Pronunciation: SYND tran-ZAK-shun
Definition
A signed transaction is a transaction that includes the cryptographic authorization required by its protocol or account policy. The signature proves control of an accepted key over defined transaction data. It does not guarantee that the transaction is valid, will be included, will execute successfully, or will become final; state, fees, nonces, permissions, and consensus still matter.
Overview
How it works and where it fits
A signed transaction is created when one or more authorized parties apply a Signature Scheme to the transaction’s signing payload and attach the resulting Transaction Signature. The signed object can then be serialized and submitted to a node. Depending on the network, authorization may come from one key, several signatures, a smart-account validation rule, or a script that is evaluated when the transaction is spent.
Signing normally commits to critical fields such as recipient, amount, nonce, fee, chain identifier, and contract call data. The exact commitment is protocol-specific. A signature can be mathematically correct while the transaction is rejected because its nonce is stale, funds are insufficient, an input was already spent, the fee is too low, or the transaction violates current protocol rules.
In smart-contract systems, a signed transaction can also be included but revert during execution. It may consume a fee without producing the intended state change. A signature therefore proves authorization of the submitted bytes, not successful business completion. Users should decode the transaction before signing, and applications should check the Transaction Result after inclusion.
Custody and payment systems should retain the unsigned intent, signed bytes, signer identity or policy, broadcast history, and final chain status. They should prevent accidental resubmission across networks by including chain-specific domain information. A signed transaction awaiting broadcast must be protected because anyone possessing it may be able to submit it while its nonce and validity window remain usable.
For dependable operation, store the approved intent, signing payload, signer or policy, complete bytes, and submission history. This information is valuable because a valid signature proves authorization but not current validity, successful execution, or settlement. Monitoring and response procedures should protect unbroadcast signed data and track rejection, replacement, inclusion, and finality.
Related glossary concepts
Raw Transaction; Signature Verification; Transaction Size
Primary reference
Example
A treasurer reviews a payment to a supplier, then a wallet signs the transaction with the appropriate private key or signing system. The resulting payload carries authorization evidence that nodes can validate. It may still be rejected for insufficient balance, wrong nonce, fee policy or an invalid script condition.
Comparison
Signing proves control of an authorized key for specified bytes under protocol rules; it does not prove that the human intended the recipient or that the payment is final. Confirm destination, chain, asset and fees on a trusted signing interface. Keep submission and confirmation as separate events after signing.
Key Takeaway
A valid signature is necessary for authorization but does not guarantee successful settlement.
Sources
- Ethereum Transactions — Ethereum.org (2026-08-02)
- Bitcoin Developer Guide: Transactions — Bitcoin.org (2026-08-02)
- Solana Transaction Structure — Solana Foundation (2026-08-02)