By chain and version bytes, what does the message signature actually authorize

The act of signing a message with a crypto wallet proving that you control a private key

does not in itself transfer funds and does not touch the blockchain-there is no need to pay for Gas and nothing will be broadcast. However, whether the signature can be replayed later to authorize an operation depends entirely on the signature format used; Ethereum, Bitcoin and Cardano each define multiple formats.

Ethereum: Three version bytes, three different guarantees

Ethereum's ERC-191 standard (released as EIP-191) defines signature data as a fixed structure: byte 0x19 , followed by version bytes, followed by version-specific data, and finally the data being signed. EIP-191 states that the leading byte 0x19 was chosen deliberately so that the result could never be resolved into a valid RLP-encoded Ethereum transaction-signed messages are structurally distinguished from signed transactions.

In this structure, EIP-191 registers three version bytes. Version 0x00 is used for data with the "intended verifier"-that is, a specific contract address where the signature content is embedded. EIP-191 gives an example of Solidity: the multi-signature wallet function reconstructs the hash by combining byte(0x19), version byte,address(this), transaction amount, random number, and payload, and then calls ecrecover on the hashTo verify the identity of the signer and then execute the payload. This signature is designed from the beginning to be handed over to a contract and translated into an operation-according to EIP-191, the entire meaning of the expected verifier field is to prevent a signature created for one wallet from being replayed for another wallet.

Version 0x01 corresponds to the format example shown in the EIP-712 Structured, Typed Data--Reown document: the user signs a domain-scope object (containing fields such as name, version, chainId, and verification contract) instead of the original string. Version 0x45 covers personal_sign messages, whose hash is preceded by a prefix "\x19Ethereum Signed Message:\n" + length . Both the Reown document and EIP-191 point out that this prefix exists to prevent malicious dApps from obtaining a signature that is actually shaped like transaction data and reuse it to impersonate the signer.

A noteworthy integration detail: Reown's own RPC reference shows that the parameter order of personal_sign is (message, account), while the parameter order of eth_sign is (account, message). This detail comes only from the Reown documentation.

Bitcoin: The header byte tells you which address type is signed

According to BIP-137 and Bitcoin Wiki, Bitcoin messages are signed as 65 bytes: a 1-byte header followed by a 32-byte r value and a 32-byte s value from the underlying ECDSA signature. The header byte performs two functions at the same time. Its low-order bits encode a "recovery identifier" that is used to reconstruct the correct public key from the signature. The values of the remaining bytes tell the verifier which address format the signature was generated from: according to BIP-137, 27-30 correspond to uncompressed P2PKH addresses, 31-34 correspond to compressed P2PKH, 35-38 correspond to P2SH-encapsulated SegWit, and 39-42 correspond to native bech32 addresses.

BIP-137 defines the actual use of such signatures as design inertia: proving funds are used for collateral or credit evaluation, eligibility for entry into activities, eligibility for airdrops, or supporting audits. In each case, the signature is a proof of control of the key at some point in time-it is not consumed by the contract like Ethereum's expected verifier signature.

There are two noteworthy limitations. According to the Bitcoin wiki, Taproot addresses do not support message signing because Schnorr signatures (unlike ECDSA) cannot recover the public key from the signature, so Taproot signatures cannot match addresses. In addition, as a marginal note in signature construction (rather than security), BIP-137 points out that ECDSA signatures have approximately 25%, 50%, and 25% probability of producing 71, 72, or 73 bytes, respectively-this is a detail about the DER encoding, regardless of what the signature is authorized.

Cardano: signData() call for CIP-8 and CIP-30

Cardano's message signing standard CIP-8 was proposed by developer Sebastien Gllmt at the Cardano Forum on October 5, 2020. As the forum post states, the document "attempts to set a standard for Cardano to represent and verify signed messages," distinguishing it from transaction signatures. Wallets that implement CIP-30 expose this functionality through the signData() method-as shown in the forum example released on October 24, 2022, this method returns a COSE_Sign1 structure with a COSE_Key required for verification. Forum contributors (including a message released by user ATADA on December 18, 2022) pointed out that CIP-30 relies on CIP-8 as its underlying signature and key format. Similar to Bitcoin's solution, CIP-8 message signing is a key control attestation mechanism that is different from transactions; the forum discussion does not document the features in Cardano that correspond to Ethereum's expected verifier execution pattern.

Common misconceptions

Since message signing requires no Gas and never appears on a blockchain browser, it is easy to treat every "sign this message" prompt as harmless-closer to login than a transaction. However, relevant norms do not support using it as a general rule. Version 0x00 of EIP-191 is designed to allow signed messages to be handed over to contracts and executed accordingly (based on EIP-191's own example). EIP-712 Typed Data (Version 0x01 Also binding signatures to specific domains and verifying contracts (as shown in the Reown example), although the existing evidence does not extend to document how EIP-712 signatures are used to transfer funds in a production environment. In contrast, Bitcoin and Cardano's message signature formats are designed as independent proof of belonging and have no built-in execution path. The category that a signature tip belongs to depends on the version bytes and payload content, not whether a fee is charged.

What is not stated on this page

This page describes the specification's definition of the signature format. It does not describe how any specific wallet interface (including MetaMask or others) currently flags, warns or restricts eth_sign,personal_sign, or EIP-712 signature requests because there is no wallet UI documentation available as evidence. It cannot cite real-world cases where signed messages are re-posted to contracts to transfer funds (including cases involving EIP-712 "permit" approvals) because no incident reports or audits are provided here-only the specification itself makes this re-posted theoretically possible. It only covers Ethereum, Bitcoin and Cardano because the main specifications for these three chains are well documented; it makes no mention of the message signing conventions of Solana, Tron or other ecosystems. Finally, the Taproot address does not support message signing, and the mechanism of the Cardano CIP-8/CIP-30 process, each based on a single source in this evidence set (the former comes from the Bitcoin Wiki, the latter comes from the Cardano Forum discussions), are noted here rather than as independently confirmed facts.