EIP-55 Checksum Addresses: What Mixed-Case Ethereum Addresses Verify

One capital letter in an Ethereum address can be the difference between a useful warning and a silent typo. That does not make mixed case a proof of who owns the destination. EIP-55 checksum addresses add an error-detection signal to the familiar 0x address without changing its 20-byte value. Understanding that boundary belongs in any practical crypto wallet security routine.

What Is an EIP-55 Checksum Address?

An Ethereum address is commonly displayed as 0x followed by 40 hexadecimal characters. The same underlying address can be written with letters a through f in lowercase or uppercase because hexadecimal values are case-insensitive.

ERC-55, historically known as EIP-55, uses that otherwise-unused letter case to carry check bits. A correctly checksummed address mixes uppercase and lowercase letters according to a hash of the lowercase address. Software can recompute the pattern and reject mixed-case input when one or more letters do not match.

Think of it like folding a lightweight spell-check pattern into the address itself. The capitalization does not change the account, just as capitalization in a printed tracking number need not change the parcel. It gives the reader's software extra evidence that the string was copied as intended.

This format is backward compatible with hex parsers that accept mixed case and does not make the address longer. The final ERC-55 specification estimates about 15 check bits on average and a 0.0247% chance that a randomly mistyped address will accidentally pass its check. That is useful error detection, not certainty.

How the Mixed-Case Pattern Is Calculated

The algorithm is short enough to follow without being a cryptographer:

1. Remove the 0x prefix and convert all 40 hexadecimal characters to lowercase.
2. Hash that lowercase ASCII string with Keccak-256.
3. Walk through the address one character at a time.
4. Leave digits 0 through 9 unchanged.
5. For each letter a through f, uppercase it when the corresponding hash nibble is 8 or higher; otherwise leave it lowercase.
6. Add 0x back to the result.

The hash acts like a deterministic capitalization stencil. Change an address character and the expected stencil changes too. If a mixed-case input no longer matches, a validating library can stop the workflow before a transaction is signed.

The ERC-55 page includes reference implementations and test vectors. Developers should use a maintained library rather than rewriting the algorithm for production, then verify their library behavior with those official vectors.

Lowercase, Uppercase, and Checksummed Inputs

Three strings can represent the same 20-byte destination:

This distinction is easy to miss. Lowercase input can be structurally valid even though it carries no EIP-55 case check. A tool that accepts lowercase and returns a checksummed form has normalized the input; it has not proved the lowercase source was typo-free.

The current ethers v6 address documentation demonstrates this behavior. getAddress adds a checksum to lowercase input, accepts valid checksummed input, and throws when a supplied mixed-case pattern is wrong. That last case is the actual validation signal.

import { getAddress } from 'ethers';
 
const normalized = getAddress('0x8ba1f109551bd432803012645ac136ddd64dba72');
 
console.log(normalized);
// 0x8ba1f109551bD432803012645Ac136ddd64DBA72

Do not force an invalid mixed-case address to lowercase merely to make an error disappear. That bypasses the warning instead of resolving whether the source string is correct.

A Safer Validation Workflow for Developers

Address validation should answer several separate questions. Treating one boolean as the whole security decision is the common design mistake.

1. Validate syntax and checksum

Require exactly 20 address bytes in the format your application supports. If the user supplies mixed case, reject a checksum mismatch. Normalize known-good input to one canonical display format for later comparison.

The viem getAddress documentation likewise returns a checksum-encoded address. It also supports an optional chain-aware variant, while warning that this mode may be incompatible with software expecting ordinary EIP-55.

2. Preserve the user's source context

Record whether an address came from a connected wallet, a verified allowlist, an ENS resolution, pasted text, or transaction history. Normalizing two strings to the same address proves equality. It does not prove that either source belongs to the intended person.

3. Confirm the network separately

Standard EIP-55 does not encode a chain ID. The same 20-byte string may exist on Ethereum mainnet and many EVM-compatible networks, with unrelated balances, code, or meaning. Ethereum.org's network documentation notes that an account can work across networks while balances and histories do not carry over.

ERC-1191 proposes adding the chain ID to the checksum calculation. It remains a separate proposal, and ecosystem support is not universal. Never assume ordinary EIP-55 case identifies a network.

4. Show the destination at the decision point

Display the normalized address, selected network, asset, amount, and action immediately before authorization. On a hardware wallet, compare the trusted device screen as well. Do not hide the destination behind a label the user cannot inspect.

5. Fail closed on conflicting evidence

If checksum validation fails, an ENS result changes unexpectedly, the network differs, or the trusted device shows another destination, stop. Do not offer “continue anyway” as the prominent path for a value transfer.

What EIP-55 Cannot Protect You From

A checksum catches a class of accidental changes. It is not an identity or security certificate.

• Address poisoning: An attacker can generate a different address with its own perfectly valid checksum. A familiar beginning and ending can still fool a shortened display.
• Wrong recipient: A correctly copied attacker address remains correctly checksummed.
• Wrong network: Ordinary EIP-55 contains no mainnet, L2, or testnet identifier.
• Compromised source: Malware can replace clipboard content and provide a valid checksum for the replacement.
• Unsafe contract: The checksum says nothing about contract code, proxy upgrades, permissions, or token behavior.
• Irreversible intent errors: The network executes the signed destination. It does not know which person you meant to pay.

That is why our address-poisoning guide recommends comparing the full destination from an independently verified source. Checksumming strengthens that process; it never replaces it.

A Practical Check Before Sending

Use this sequence for a new or high-consequence destination:

1. Retrieve the address from an independently trusted source, not recent transaction history.
2. Let reputable wallet or library software validate and display the EIP-55 form.
3. Compare the entire address, not only the first and last four characters.
4. Confirm the selected chain and token with the recipient.
5. Verify the destination, value, and network again on the signing device.
6. For an appropriate transfer, consider a small test and obtain recipient confirmation before reusing the exact verified destination.

Transaction previews can help reveal asset movements and contract effects, but they solve a different problem. A crypto transaction simulation can accurately preview a transfer to the wrong person. Identity and intent still need independent checks.

Frequently Asked Questions

Does changing capitalization change the Ethereum address?

No. Hexadecimal address values are not case-sensitive. EIP-55 uses capitalization as display-layer check information for the same 20-byte value.

Is every lowercase Ethereum address invalid?

No. Many libraries accept a 40-character lowercase hex address and can convert it to EIP-55 form. The limitation is that lowercase input does not itself carry the mixed-case checksum signal.

Does a valid checksum prove an address is safe?

No. It indicates that the case pattern matches the address characters. It does not authenticate the owner, network, contract, website, or purpose.

Can EIP-55 stop address poisoning?

Not by itself. A lookalike attacker's address can have a valid checksum. Use a trusted address source, compare all characters, verify on the signing device, and confirm important destinations through a second channel.

Should an application store checksummed addresses?

Store the underlying address consistently and display a standard checksum form where your stack supports it. Equality checks should operate on normalized address values, while audit records should preserve relevant source and network context.

Use the Checksum as One Layer

EIP-55 makes Ethereum's existing hexadecimal format better at detecting accidental edits without adding characters. The clever part is also the limitation: letter case can check the string, but it cannot tell you who controls it or where you should use it.

Validate mixed-case input, preserve source context, confirm the network, compare the full destination, and stop on discrepancies. This article is educational and not financial advice. Crypto transactions can cause total loss; verify current tooling, use only funds you can afford to lose, and DYOR.

Primary Sources

• ERC-55: Mixed-case checksum address encoding
• Ethereum.org: Ethereum accounts
• Ethereum.org: Networks
• ethers v6: Addresses
• viem: getAddress
• ERC-1191: Add chain ID to mixed-case checksum address encoding