Transaction Signature

Overview

A transaction signature is produced by applying a private or threshold signing process to a protocol-defined digest of transaction data. The network performs Signature Verification using the corresponding public key or account rule. A correct signature proves authorization of the covered bytes, not that the signer understood them, owned the funds legitimately, or will obtain the intended business outcome.

Coverage is crucial. Different signature-hash modes and transaction formats can commit to different fields. Chain identifiers and domain separation prevent signatures from being replayed across networks or action types. A signature generated for one Serialized Transaction becomes invalid if a covered recipient, amount, nonce, or fee field changes.

Some transactions contain several signatures, while Threshold Signature systems can produce one signature from multiple participants. Smart accounts may use custom validation data instead of one conventional signature. The format, signer order, public-key recovery, and canonical encoding must all follow the selected Signature Scheme.

Wallets and custody systems should decode the exact signing payload, display security-relevant fields, enforce policy before signing, and retain an audit link between intent and signed bytes. Nodes should reject malformed or non-canonical signatures consistently. After signing, applications still need to verify broadcast, execution success, and finality; the signature is only the authorization stage.

Implementations should keep the scheme, public key or account policy, signing preimage, domain, encoded signature, and verification result. That context supports investigation because a signature can verify mathematically while authorizing an unintended network, payload, or business action. Controls also need to decode before signing, reject non-canonical forms, and link the signature to the final submitted bytes.