Understanding Ethereum Signatures: ECDSA, RLP, EIP155, EIP191, and EIP712

Ethereum signatures are a cornerstone of blockchain security and decentralized identity. Whether authorizing transactions or proving ownership off-chain, understanding how digital signatures work is essential for developers, auditors, and users alike. This comprehensive guide breaks down the core concepts—ECDSA, RLP encoding, chain replay protection via EIP155, and structured signing standards like EIP191 and EIP712—into digestible, practical knowledge.

We'll explore both transaction and message signing processes, uncover the cryptographic principles behind them, and demonstrate real-world implementations such as NFT whitelist minting and gas-efficient token approvals using Uniswap’s permit function.

What Is an Ethereum Signature?

At its core, a digital signature in Ethereum serves the same purpose as a handwritten signature on a physical contract: it verifies identity, ensures non-repudiation, and guarantees data integrity.

Imagine signing a lease agreement. If damage occurs, the landlord uses your signature to prove you agreed to the terms. Similarly, in Ethereum, a signature proves that:

✅ You own the private key associated with an address (identity verification),
✅ You approved a specific action, such as sending funds or minting an NFT (non-repudiation),
✅ The message or transaction hasn’t been altered after signing (integrity).

Unlike pen-and-paper signatures, Ethereum signatures are generated using cryptography—specifically, the Elliptic Curve Digital Signature Algorithm (ECDSA).

👉 Discover how secure digital asset management starts with robust signature protocols.

The Role of ECDSA in Ethereum

ECDSA is the cryptographic algorithm used to generate and verify digital signatures across Ethereum and Bitcoin. While traditional ECDSA outputs two values (r, s), Ethereum extends this with a third component: v. This triplet (r, s, v) uniquely identifies a valid signature.

How ECDSA Works

The process can be summarized in two steps:

1. Signing Process (Forward Operation)

Given:

A message (or transaction data),
A private key,
A cryptographically secure random number,

The ECDSA forward algorithm produces a signature:
signature = ECDSA(message + private key + random number) → (r, s, v)

2. Verification Process (Reverse Operation)

Given:

The original message,
The signature (r, s, v),

The ECDSA reverse algorithm recovers the signer’s public key:
public key = ECDSA(message + signature)
From the public key, the Ethereum address is derived.

This allows anyone—nodes, contracts, or users—to confirm that a message was indeed signed by the holder of a specific private key without ever exposing that key.

Signing Ethereum Transactions

Every Ethereum transaction must be signed before being broadcast to the network. Let’s walk through the full lifecycle.

Step 1: Constructing the Transaction Object

A raw transaction includes these fields:

Field	Purpose
`nonce`	Ensures transaction order and prevents replay attacks
`gasPrice`	Price per unit of gas (in Wei)
`gasLimit`	Maximum gas allowed for execution
`to`	Recipient address or contract address
`value`	Amount of ETH to send
`data`	Optional payload (e.g., function call parameters)
`chainId`	Prevents cross-chain replay attacks (via EIP-155)

Step 2: Signing the Transaction

Here’s how you sign a transaction using ethers.js:

const ethers = require("ethers");
require("dotenv").config();

async function signTx() {
  const provider = new ethers.providers.JsonRpcProvider(process.env.RPC_URL);
  const wallet = new ethers.Wallet(process.env.PRIVATE_KEY, provider);

  const tx = {
    nonce: await wallet.getTransactionCount(),
    gasPrice: 100000000000,
    gasLimit: 1000000,
    to: "0x...",
    value: 0,
    data: "0x",
    chainId: 1
  };

  const signedTx = await wallet.signTransaction(tx);
  console.log("Signed Transaction:", signedTx);
}

But what happens under the hood?

Behind the Scenes: RLP Encoding & Keccak256 Hashing

RLP Encode the transaction fields (excluding v, r, s):
(nonce, gasPrice, gasLimit, to, value, data, chainId, 0, 0)
Hash the encoded result using Keccak256.
Sign the hash with ECDSA (private key) → output: (r, s, v)
RLP Encode Again, now including (nonce, gasPrice, gasLimit, to, value, data, v, r, s) → final serialized transaction.

🔍 Why does chainId disappear in the final encoding? Because it's embedded in the v parameter during signing to prevent cross-chain replay attacks—a mechanism defined in EIP-155.

Preventing Replay Attacks with Nonce and ChainID

Replay attacks occur when a signed transaction is reused maliciously. Ethereum mitigates this with two mechanisms:

Nonce: Each account has a counter that increments with every transaction. Nodes reject transactions with invalid nonces.
ChainID: Introduced in EIP-155, it binds transactions to a specific blockchain (e.g., Ethereum Mainnet uses chainId = 1, Ethereum Classic uses 61). Without matching chain IDs, signatures cannot be replayed across chains.

👉 Learn how modern wallets protect against replay attacks automatically.

Signing Messages: Beyond Transactions

While transaction signing moves assets on-chain, message signing enables off-chain authentication and authorization—ideal for reducing gas costs.

There are three main approaches:

1. Generic Message Signing

Uses MetaMask’s personal_sign or ethers.js’s toEthSignedMessageHash. It prepends:

\x19Ethereum Signed Message:\n32

to the message hash before signing.

Use case: NFT whitelist verification.

Example: NFT Whitelist with Off-Chain Signatures

Instead of storing all whitelisted addresses on-chain (costly), projects sign access off-chain.

Smart Contract Logic:

function mintNft(address account, uint256 tokenId, bytes memory signature) public {
    require(verify(account, tokenId, signature), "Invalid signature");
    _safeMint(account, tokenId);
}

function verify(address account, uint256 tokenId, bytes memory signature) public view returns (bool) {
    bytes32 msgHash = keccak256(abi.encodePacked(account, tokenId));
    bytes32 ethHash = ECDSA.toEthSignedMessageHash(msgHash);
    address signer = ECDSA.recover(ethHash, signature);
    return signer == i_signer;
}

This method saves significant gas compared to on-chain storage solutions like Merkle trees.

2. EIP-191: Signed Data Standard

Defines a versioned format for signed data:

Prefix: \x19\x00 — indicates version 0
Optional contract address inclusion to prevent cross-contract replay

Though foundational, EIP-191 is largely superseded by more advanced standards.

3. EIP-712: Typed Structured Data Signing

The gold standard for user-friendly and secure message signing. It enables human-readable prompts in wallets like MetaMask.

Why Use EIP-712?

✅ Shows users exactly what they’re signing (e.g., “Approve 100 DAI until June 30”)
✅ Prevents phishing attacks where malicious dApps alter intent
✅ Supports complex data types via typed structures

Core Components

An EIP-712 digest is computed as:

digest = keccak256("\x19\x01" || domainSeparator || hashStruct(message))

Domain Separator

Identifies the signing context:

{
  name: "Uniswap V2",
  version: "1",
  chainId: 1,
  verifyingContract: "0x...",
}

Message Structure

Defines typed data:

types: {
  Permit: [
    { name: 'owner', type: 'address' },
    { name: 'spender', type: 'address' },
    { name: 'value', type: 'uint256' },
    { name: 'nonce', type: 'uint256' },
    { name: 'deadline', type: 'uint256' }
  ]
}

Signing is done via:

const signature = await signer._signTypedData(domain, types, value);

Real-World Use Case: Uniswap Permit

Uniswap uses EIP-712 to let users approve token spending off-chain via permit(), saving one entire transaction and cutting gas fees by ~50%.

FAQ Section

Q1: What is the difference between transaction and message signatures?

Transaction signatures authorize on-chain state changes (like transfers), while message signatures authenticate off-chain actions (like login or whitelist access). Both use ECDSA but differ in structure and use case.

Q2: Why is RLP encoding used instead of JSON?

RLP (Recursive Length Prefix) ensures deterministic encoding, critical for hashing. Unlike JSON, RLP doesn't allow variations in formatting (whitespace, field order), making it ideal for consensus-critical operations.

Q3: How does EIP-712 improve security over generic signing?

EIP-712 displays structured data in wallets, so users see exactly what they're approving. Generic signing only shows raw hashes—making it vulnerable to spoofing if malware alters the message.

Q4: Can a signature be reused?

No—if protections like nonce, chainId, or unique message parameters are used. However, poorly implemented contracts may allow signature replay unless each signature is marked as used (e.g., via a usedSignatures mapping).

Q5: What happens if I lose my private key?

You lose control of your address and cannot sign new messages or transactions. There is no recovery mechanism—private keys must be securely backed up.

Q6: Is ECDSA quantum-resistant?

No. ECDSA relies on elliptic curve cryptography, which is vulnerable to quantum computing attacks. Post-quantum alternatives are under research but not yet standardized in Ethereum.

Final Thoughts

Understanding Ethereum signatures goes beyond knowing algorithms—it's about grasping how trust is established in decentralized systems. From securing transactions with ECDSA and RLP to enabling safe off-chain interactions via EIP-712, these tools empower developers to build secure, efficient dApps.

As blockchain evolves, so too will signing standards. But the fundamentals—integrity, authenticity, and non-repudiation—remain unchanged.

👉 Secure your next dApp interaction with industry-leading wallet infrastructure.