A checksum, similar to its use in Bitcoin addresses, can primarily prevent mistyped or invalid addresses from being used, before a transaction with an invalid address is constructed.

Why don't Ethereum addresses have checksums? Was it an oversight that was overlooked by the designers, auditors, and the community until after Frontier was launched? (This question is more about the history, than ongoing and future efforts to rectify.)

4 Answers 4


Edited to add: As predicted, with the launch of the Ethereum Name Service (ENS), users and wallets have gradually begun switching over to using strings like "mywallet.eth" instead of the raw hex addresses. Because that name was not known at the time this answer was written, it refers to the same concept as a "namereg".

I can elaborate on this a little bit, because it's not just the fact that end users are eventually expected to use human-readable strings for normal day to day transactions. It's that the raw hexadecimal string that you're calling an "Ethereum address" wasn't even intended to be the standard way of representing that information.

You may or may not know that when you send a bitcoin transaction to a "bitcoin address" such as 1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3, the actual transaction itself doesn't contain the string "1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3". Instead, it decodes that representation into the real address 0xfc916f213a3d7f1369313d5fa30f6168f9446a2d, a pure hexadecimal representation that doesn't waste space on checksums and version bits. Look familiar?

It's true that the pure hexadecimal address itself doesn't contain any checksums. But there's nothing stopping you from writing software which uses the exact same method that Bitcoin does to create an encoding of that string in base 58 with a built-in version number and checksum. It would interoperate perfectly with the network by silently decoding the new "Ethereum address" into raw hexadecimal form. It could even accept both types of formats as long as you were careful to always include the "0x" on the front of the raw ones (which you should be doing anyways). Then you could send and receive with the exact same experience you have in Bitcoin. Perhaps with a different version number so that you don't accidentally mix up the addresses, though.

Vitalik has already pointed out one reason nobody bothered to do this for most Frontier apps. But there's another one, much more relevant. Ethereum apps don't take the Bitcoin approach because there is an even more featureful way of representing raw Ethereum addresses, called the ICAP, which looks like this: "XE7338O073KYGTWWZN0F2WZ0R8PX5ZPPZS". Like the standard Bitcoin address representation, it uses a wider range of alphanumeric characters to save space and includes a checksum. But that's not all, folks!

For one thing, the ICAP is a fully valid International Bank Account Number (or IBAN). That means that existing bank software can understand it and interact with it.

For another, the ICAP doesn't have to use hexadecimal addresses. Instead, once we all do switch over to using namereg contracts it can just use your actual human readable string to end up with something like "XE81ETHXREGJEFFCOLEMAN", which still matches bank formats but might be possible to actually remember!

Support for the ICAP is gradually growing, including within the official Ethereum clients. Perhaps one day soon, it will no longer be the case that the most common representation of an Ethereum address lacks a checksum!

Edit: As of February 2016, Vitalik has also implemented a transitional checksumming method where capitalisation of the otherwise case-insensitive hex address is used to provide some additional protection against accidental errors while remaining backwards compatible with software that doesn't support the checksum (and will ignore the case differences). Anyone developing software that supports inputting or displaying a raw hexadecimal encoding is strongly advised to implement this "capitals-based checksum" method.

With Vitalik's method, the address:


is compared against the raw binary keccack-256 hash of the address bytes, and where there are letters in the same corresponding place as a "1" bit the letter is capitalised (letters which correspond to the place of a "0" bit are left in lowercase form, and numbers are unchanged). This results in:


Almost all non-checksum aware code will simply ignore the case differences above and interpret this representation identically to the first one, so there is very little disadvantage to implementation of the capitals-based checksum.

  • 1
    "your" code would have to "silently decoding the new "Ethereum address" into raw hexadecimal form" right? Can you clarify because "you from writing software" seems to be different from the "it" in "it would interoperate..."
    – eth
    Commented Jan 22, 2016 at 23:09
  • 1
    It's not quite clear to me what you're asking. The "it" refers to the software that "you" could create. What part is it that I should clarify? Commented Jan 23, 2016 at 16:12
  • 2
    Thanks your comment is enough clarification for me. (Your answer was possible to interpret that Ethereum itself already handles base58 encoded addresses, if one encoded it themselves. Maybe clarifying the part that one would have to write both the encoding and decoding parts.)
    – eth
    Commented Jan 23, 2016 at 19:29
  • Wow, what an incredible archeological record of overengineering. I'm glad that they have now settled on the somewhat convoluted capitals based checksum.
    – Jehan
    Commented Jul 20, 2018 at 23:18

Here's the answer from V:


seriously? there's no checksum? you typo one character wrong and your ether is lost forever? Damn.... TIL Ethereum has a massive design oversight permalink


You're not meant to use ether addresses; you're meant to use the namereg and equivalents of things like bip70.

Source: https://www.reddit.com/r/ethereum/comments/33l08f/do_ethereum_address_not_have_a_checksum_like/

Straight from the developers - it appears checksums may be developed in future versions:


I think everyone wants checksums and understands the benefits, but delivering a stable network protocol upgrade is of chief importance right now and has been since the beginning. Additional functionality in the clients themselves will hopefully follow soon after the Homestead hard-fork. :)



Ethereum addresses do, now, have a checksum.

See EIP55 for the specification and updates about implementation.

It is optional for use, but if you see a mixed-case address it should be validated according to the following rule:

Convert the address to hex, but if the ith digit is a letter (ie. it's one of abcdef) print it in uppercase if the 4*ith bit of the hash of the lowercase hexadecimal address is 1 otherwise print it in lowercase.

Not everyone requires this: for example, Coinbase won't reject invalid mixed-case addresses so you can still send funds from Coinbase into the void for a typo.

Of those that do use the checksum, entering an all-lowercase (or sometimes all-uppercase) address will sometimes skip the checksum process.


NO, no , they dont and I just lost £75 because they dont. Wow, it could have been 75k! What you say may be true one day, but as of now its a lie. They do not have checksums in the common implementations and mis-copying a single character will result in silent loss of funds, This is amateurish in the extreme. Aaagh!

  • 1
    I'm sorry about your loss. There is an optional checksum implemented under EIP-55, but it's up to the exchange or wallet to implement it, and many don't. Originally, raw addresses weren't meant to be used by people, hence the lack of checksum in the original design. (Never, ever type an raw address by hand. Humans aren't good with hexidecimal. Always copy+paste where you can. If you can't copy and paste, look for wallets that allow the use of QR codes or 24-word mnemonics.) Commented Jan 19, 2018 at 10:14

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.