Los datos firmados son 0x19 ‖ version ‖ version-specific data ‖ data. Versiones: 0x00 (datos con la dirección de un validador previsto), 0x01 (datos estructurados, es decir, EIP-712) y 0x45, la letra E, para personal_sign: 0x19 seguido de Ethereum Signed Message: y un salto de línea, la longitud del mensaje en ASCII decimal y el mensaje. Las transacciones codificadas en RLP no pueden empezar por 0x19, y esa es precisamente la razón del prefijo.
La billetera calcula el hash Keccak-256 del resultado y firma con secp256k1; la firma son 65 bytes r ‖ s ‖ v, con v 27 o 28. Para el mensaje hello, el resumen es 0x50b2c43fd39106bafbba0da34fc430e1f91e3c96ea2acee2bc34119f92b37750. Los verificadores recuperan la dirección con ecrecover (o con el verifyMessage de una biblioteca) y la comparan; las cuentas inteligentes necesitan ERC-1271 en su lugar.
personal_sign muestra a los usuarios un texto opaco y no vincula la firma a ningún dominio ni cadena, así que las aplicaciones deberían incluir esos datos en el mensaje (como hace Sign-In with Ethereum) o preferir EIP-712 para cualquier cosa con estructura o valor.