EIP-191

EIP-191 is a specification for a versioned, structured data format for signed messages on Ethereum. Its primary purpose is to prevent a critical security flaw where a user might unknowingly sign a raw transaction that could be maliciously submitted for execution. By introducing a standard preamble, it ensures a signature is explicitly bound to a specific, intended context, making signatures non-malleable and context-specific. This is a foundational security primitive for user interactions.

The standard defines a simple structure: 0x19 <version byte> <version-specific data> <data to sign>. The initial 0x19 byte is a deliberate guard, as this byte would rarely appear in a raw RLP-encoded Ethereum transaction, preventing accidental transaction replay. The version byte dictates how the subsequent data is interpreted. Version 0x00 is for data with an optional validator address, 0x01 is for structured data as defined by EIP-712, and 0x45 ("E") is for personal_sign messages, which is the most common implementation used by wallets like MetaMask.

The most widespread application of EIP-191 is in wallet signature requests for login and authentication, often via the personal_sign method (version 0x45). When a dapp asks you to "Sign in with Ethereum," it is typically using this standard to generate a cryptographic proof of ownership of an address without requiring a transaction or paying gas. This signature can then be verified off-chain by the service. The structured format prevents the signed message from being misinterpreted as a transaction or used in a different dapp's context.

Beyond simple logins, EIP-191 is the essential precursor to EIP-712, which enables signing of complex, human-readable structured data. While EIP-191 provides the versioned envelope, EIP-712 defines a schema for the data inside that envelope, allowing users to see a clear breakdown of what they are signing. Together, these standards form the backbone of secure, user-consent mechanisms for meta-transactions, delegated approvals, and gasless transactions in the Ethereum ecosystem.

For developers, implementing EIP-191 verification is crucial for security. A contract must replicate the exact same data formatting on-chain that was signed off-chain. This involves prepending the 0x19 byte, the version, any length prefixes, and finally the intended message data, then using ecrecover to check the signature against the signer's address. Failing to adhere precisely to the standard can create signature malleability vulnerabilities, where a valid signature for one purpose could be reused for another.

EIP-191 is a standard for signed data with intended validator that defines a structured data format for creating verifiable signatures on arbitrary messages. It specifies a version byte and a domain separator to prevent signature reuse across different contexts, a problem known as a replay attack. This standard is foundational for secure off-chain interactions like meta-transactions, login requests, and vote delegation, as it allows a user to sign a message with their private key, which can later be verified on-chain without submitting a full transaction.

The standard defines a specific encoding format, beginning with a 0x19 byte, followed by a version-specific identifier. The most common version, 0x45 (E), is for Ethereum Signed Messages used by wallets like MetaMask for simple text. The version 0x00 is for structured data with an intended validator address, which prepends the signer's address to the message before hashing. This structure ensures a signature created for one smart contract cannot be replayed on another, even if the message data is identical, by binding the signature to a specific contract address.

For developers, implementing EIP-191 involves hashing the message according to the standard's rules: \x19Ethereum Signed Message:\n + length + message for version 0x45, or \x19\x00 + validator address + data for version 0x00. The resulting hash is then signed using ecrecover. Smart contracts verify these signatures using the ecrecover precompile, which returns the signer's address from the signature and hash. This mechanism is the backbone of systems like EIP-712 for typed structured data and ERC-2771 for meta-transactions, providing a secure and standardized method for trust-minimized off-chain agreement.

EIP-191 is a standard for a structured data format for signed messages on Ethereum, designed to prevent the signing of raw, arbitrary data which can be replayed or misinterpreted by different applications. Prior to its adoption, signing a plain text string like "Send 100 ETH" was dangerous, as the same signature could be valid for a different contract expecting a different meaning. EIP-191 introduces a version byte and specific formatting to create domain separation, ensuring a signature is only valid within its intended context. This prevents signature replay attacks across different smart contracts and dApps.

The proposal defines three distinct version structures, each prefixed with the byte 0x19. Version 0x00 is for data with an intended validator, where the format is 0x19 || 0x00 || validator_address || data. This is commonly used by personal_sign methods in wallets, where the validator is implicitly the signer's own address. Version 0x01 is for structured data as defined by EIP-712, which enables human-readable signing in wallets. Its format is 0x19 || 0x01 || domainSeparator || hashStruct(message), providing a robust framework for signing complex, typed data.

Version 0x45 ("E" in ASCII) is designated for Ethereum Signed Messages, formalizing the common pattern used by wallets like MetaMask for personal_sign. The format is 0x19 || "Ethereum Signed Message:\n" || message.length || message. This version explicitly includes the message length to prevent ambiguity, making it the standard for simple message signing where no specific validator or complex structure is required. The 0x19 prefix was chosen as it is an unused opcode in the Ethereum Virtual Machine (EVM), making it unlikely to appear in valid transaction data.

Implementing EIP-191 requires developers to correctly prefix their message hashes before signing. For example, a contract verifying a Version 0x45 signature must reconstruct the prefixed message \x19Ethereum Signed Message:\n32 followed by the 32-byte Keccak-256 hash of the original message. This process is abstracted by libraries like OpenZeppelin's ECDSA library, which provides functions for recovering signer addresses from EIP-191 compliant signatures. Failure to use the correct prefix and version makes signatures invalid and contracts insecure.

The primary use cases for EIP-191 are meta-transactions (via ERC-2771), login authentication (Sign-In with Ethereum), token permit functions (ERC-2612), and off-chain agreement signing. By providing a clear versioning system, EIP-191 ensures interoperability and security across the ecosystem. It is a foundational standard that enables trust-minimized interactions by allowing users to sign messages off-chain that can be reliably verified and executed on-chain, forming the basis for more complex signature-based protocols.

EIP-191 specifies a versioned, structured data format for Ethereum signed messages. Before its adoption, signing messages lacked a standard, leading to security risks where a signature for one application could be replayed in another. The standard introduces a version byte and optional domain separator to prevent such signature replay attacks and ensure the signed data's intent is unambiguous. This is crucial for meta-transactions, login authentication (like Sign-In with Ethereum), and off-chain agreements.

The standard defines several version structures. The most common, version 0x45 (E), is the legacy \x19Ethereum Signed Message:\n prefix used by personal_sign. Version 0x00 is for data with a verifier-specific validator address, while version 0x01 is the structured data format defined by EIP-712, which enables human-readable signing. Each version byte ensures signatures are context-bound, meaning a signature for a login cannot be misinterpreted as authorization for a token transfer.

Implementing EIP-191 involves hashing the data with the appropriate version-specific prefix before signing. For example, to sign a plain text message, a developer would prepend the \x19Ethereum Signed Message:\n prefix and the message length before hashing with Keccak-256. The resulting hash is then signed with the user's private key using ecdsa recovery. Contracts verify these signatures using the ecrecover precompiled function, which returns the signer's address from the signature and the hash.

A primary use case is gasless transactions or meta-transactions. A user can sign a transaction message off-chain (following EIP-191) and send the signature to a relayer. The relayer pays the gas to submit the transaction to a smart contract, which uses ecrecover to validate the user's signature and execute the intended logic. This pattern is fundamental to systems like OpenZeppelin's Defender Relayer and many decentralized application (dApp) user experiences.

EIP-191's true power is realized with EIP-712: Typed Structured Data Hashing. This extension (version 0x01) allows signing human-readable, typed data structures instead of opaque hex strings. The signer's wallet can display a clear representation of the data being signed (e.g., "Sign this order to trade 100 DAI for 1 ETH"), vastly improving security and user experience for complex agreements like decentralized exchange orders or DAO votes.