Solidity ecrecover returns the wrong signer because ethers signMessage hashed a hex string as text, not bytes

Symptom: a signature verifies to the expected address in JavaScript but recovers a different, seemingly random address in Solidity via ecrecover. No error anywhere — just a mismatched signer, so the contract's authorization check fails.

Cause: wallet.signMessage(value) in ethers treats a **string** as UTF-8 text and a **byte array** as raw bytes. Passing a hex string like "0x1c8a..." therefore signs the 66 ASCII characters of that string, and the EIP-191 prefix becomes "\x19Ethereum Signed Message:\n66". Solidity, meanwhile, prefixes the 32 raw bytes of the digest with "\x19Ethereum Signed Message:\n32". Two different preimages, two different recovered addresses. Building the prefixed hash by hand in JS with '\x19Ethereum Signed Message:\n' + hash.length compounds it, since .length of a hex *string* is not the byte length.

Fix: convert the digest to bytes before signing, and let the library apply the prefix once.

const encodedParams = ethers.utils.defaultAbiCoder.encode(['string'], ['hello']); const hash = ethers.utils.keccak256(encodedParams); const signature = await wallet.signMessage(ethers.utils.arrayify(hash));

and verify with ethers.utils.verifyMessage(ethers.utils.arrayify(hash), signature). The contract side then uses the standard keccak256(abi.encodePacked("\x19Ethereum Signed Message:\n32", hash)) before ecrecover and agrees.

In ethers v6 the equivalent of arrayify is getBytes, and defaultAbiCoder moved to AbiCoder.defaultAbiCoder(); the underlying rule is unchanged.

Debugging heuristic: whenever a signature verifies off-chain but not on-chain, print the exact preimage lengths on both sides. A :\n66 versus :\n32 mismatch is the single most common cause, and never double-prefix — do not hash a prefixed value and then call signMessage, which prefixes again.

Source: adapted from a Stack Exchange answer by SYED ASAD KAZMI (question by SYED ASAD KAZMI), https://ethereum.stackexchange.com/questions/161259/getting-incorrect-signer-address-on-verifying-the-signature-with-the-generated-h — CC BY-SA 4.0