Signing a message with a crypto wallet proves you control a private key. It does not, by itself, move funds or touch the blockchain – no gas is paid, nothing is broadcast. But whether that signature can later be replayed to authorize an action depends entirely on which signing format was used, and the specifications for Ethereum, Bitcoin and Cardano each define more than one.
Ethereum: three version bytes, three different guarantees
Ethereum’s ERC-191 standard, published as EIP-191, defines signed data as a fixed structure: the byte 0x19, followed by a version byte, followed by version-specific data, followed by the data being signed. EIP-191 says the leading 0x19 byte is chosen deliberately so the result can never be parsed as a valid RLP-encoded Ethereum transaction – a signed message and a signed transaction are structurally kept apart.
Within that structure, EIP-191 registers three version bytes. Version 0x00 is for data with an “intended validator” – a specific contract address baked into what gets signed. EIP-191 gives a worked Solidity example: a multisig wallet function that reconstructs a hash from byte(0x19), the version byte, address(this), the transaction value, a nonce and a payload, then calls ecrecover on that hash to check who signed it before executing the payload. That is a signature designed from the outset to be handed to a contract and turned into an action – the whole point of the intended-validator field, per EIP-191, is to stop a signature made for one wallet being replayed against another.
Version 0x01 is EIP-712 structured, typed data – the format shown in Reown’s documentation as an example where a user signs a domain-scoped object (with fields like name, version, chainId and a verifying contract) rather than a raw string. Version 0x45 covers personal_sign messages, where the prefix "\x19Ethereum Signed Message:\n" + length is added before hashing. Reown’s docs and EIP-191 both describe this prefix as existing to stop a malicious dApp from getting a signature over what is actually transaction-shaped data and reusing it to impersonate the signer.
One integration detail worth flagging: Reown’s own RPC reference shows personal_sign taking parameters in the order (message, account), while eth_sign takes them in the reverse order (account, message). This detail comes from Reown’s docs alone.
Bitcoin: the header byte tells you which address type signed
Bitcoin message signatures, per BIP-137 and the Bitcoin Wiki, are 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 does two jobs at once. Its low bits encode a “recovery ID” needed to reconstruct the correct public key from the signature. The rest of the byte’s numeric value tells a verifier which address format produced the signature: 27-30 for uncompressed P2PKH addresses, 31-34 for compressed P2PKH, 35-38 for P2SH-wrapped segwit, and 39-42 for native bech32 addresses, according to BIP-137.
BIP-137 frames the practical uses of this kind of signing as inert by design: proving funds for collateral or credit-worthiness, gaining entry to an event, qualifying for an airdrop, or supporting an audit. In each case the signature is a proof of key control at a point in time – it is not consumed by a contract the way an Ethereum intended-validator signature can be.
Two limits worth noting. According to the Bitcoin Wiki, there is no message-signing support for Taproot addresses, because Schnorr signatures – unlike ECDSA – don’t allow the public key to be recovered from the signature, so a Taproot signature can’t be matched back to an address. Separately, as an aside on signature construction rather than security, BIP-137 notes ECDSA signatures come out to 71, 72 or 73 bytes with roughly 25%, 50% and 25% probability respectively – a detail about DER encoding, not about what a signature authorizes.
Cardano: CIP-8 and the CIP-30 signData() call
Cardano’s message-signing standard, CIP-8, was proposed by developer SebastienGllmt on the Cardano Forum on 5 October 2020. As the forum post states, the document “tries to set a standard for how to represent and verify signed messages” for Cardano, separately from transaction signing. Wallets implementing CIP-30 expose this through a signData() method, which – as shown in a forum example posted 24 October 2022 – returns a COSE_Sign1 structure paired with a COSE_Key needed to verify it. Forum contributors, including a message posted by user ATADA on 18 December 2022, note that CIP-30 relies on CIP-8 as its underlying signature and key format. Like Bitcoin’s scheme, CIP-8 message signing is a proof-of-key-control mechanism distinct from a transaction; the forum thread does not document a Cardano equivalent of Ethereum’s intended-validator execution pattern.
The common misreading
Because a message signature costs no gas and never appears on a block explorer, it’s tempting to treat every “sign this message” prompt as harmless – closer to a login than a transaction. The specifications don’t support that as a blanket rule. EIP-191’s version 0x00 exists specifically so a signed message can be handed to a contract that executes on the strength of it, per EIP-191’s own example. EIP-712 typed data (version 0x01) similarly ties a signature to a specific domain and verifying contract, as shown in Reown’s example, though the evidence here does not extend to documenting how EIP-712 signatures get used to move funds in production. Bitcoin’s and Cardano’s message-signing formats, by contrast, were built as standalone proofs-of-ownership with no built-in execution path. Which category a given signing prompt falls into depends on the version byte and the payload, not on whether a fee was charged.
What this page does not tell you
This page describes what the specifications define a signature format to do. It does not describe how any specific wallet interface – MetaMask or otherwise – currently labels, warns about, or restricts eth_sign, personal_sign or EIP-712 signing requests, because no wallet UI documentation was available as evidence. It cannot cite real-world cases where a signed message was replayed into a contract to move funds, including cases involving EIP-712 “permit” approvals, because no incident report or audit was supplied here – only the specifications that make such replay possible in principle. It covers only Ethereum, Bitcoin and Cardano, because those are the three chains for which primary specifications were in evidence; it says nothing about Solana, Tron or other ecosystems’ message-signing conventions. Finally, the claim that Taproot addresses have no message-signing support, and the mechanics of Cardano’s CIP-8/CIP-30 flow, each rest on a single source in this evidence set – the Bitcoin Wiki for the former, the Cardano Forum thread for the latter – and are flagged here rather than treated as independently confirmed.
Sources
Every fact above is attributed to one of these reports. Where they disagree, the article says so.
