Why Ethereum Uses Keccak, Not SHA-3

Figure 1: Keccak-256 and SHA3-256 share a core but produce different hashes

The mix-up that catches every new Ethereum developer

Reach for a standard SHA3-256 library to reproduce an Ethereum address or a function selector, and the numbers will never line up. The function Ethereum relies on is Keccak-256, and although it grew from the same design as SHA3-256, the two are not interchangeable. One small change made during standardization split them apart, and knowing that change saves hours of confused debugging.

This post explains what Keccak is, how it differs from the official SHA-3, and why Ethereum stuck with the original.

What Keccak is

Keccak is the sponge-based hash family that won the SHA-3 competition that NIST ran from 2007 to 2012. The sponge design absorbs your input into a large internal state, stirs it through a fixed permutation, then squeezes out a digest of the length you ask for. Keccak-256 squeezes out 256 bits, written as 64 hexadecimal characters.

The algorithm was praised for a clean structure that looks nothing like the older SHA-1 and SHA-2 line, which matters because a fresh design does not inherit their weaknesses. You can try it in the browser with the Keccak-256 tool.

Keccak-256 is not SHA3-256

Here is the heart of the confusion. After Keccak won, NIST adjusted one detail before publishing it as SHA-3 in 2015: the padding rule. The finalized standard inserts a different marker byte into the input before hashing, which changes every output. Same sponge, same rounds, one altered byte of padding, completely different result.

The gap is easy to see on the empty string:

Keccak-256("")  =  c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470
SHA3-256("")    =  a7ffc6f8bf1ed76651c14756a061d662f580ff4de43b49fa82d80a4b80f8434a

Both are valid 256-bit hashes of nothing at all, yet they do not match. If your code expects one and the chain produced the other, this padding difference is almost always the reason. Our SHA3-256 tool returns the second value, while the Keccak tool returns the first.

Why Ethereum froze on the original

The timing explains it. Ethereum's design work happened in 2014 and early 2015, drawing on the Keccak submission as it stood. NIST did not publish the adjusted SHA-3 standard until August 2015, by which point Ethereum had already built addresses, selectors, and storage layout on the original padding. Switching afterward would have broken every address and contract in existence, so the ecosystem kept Keccak-256 and never looked back.

The lesson for tooling is simple: when you work with Ethereum, pick a library function named keccak256, not sha3_256, even though people loosely call it SHA-3 in conversation.

Where Keccak shows up in Ethereum

Keccak-256 is woven through the protocol far more widely than most newcomers realize:

• Addresses come from the Keccak-256 of a public key, keeping the final 20 bytes.
• Function selectors, the four bytes that tell a contract which method you are calling, are the first four bytes of the Keccak-256 of the function signature.
• Storage slots for mappings and dynamic arrays are located by hashing keys with Keccak-256.
• Event topics, Merkle Patricia trie nodes, and CREATE2 addresses all lean on it too.

In short, almost every identifier you see on-chain traces back to this one function.

A worked example

Take the most common call in all of Ethereum, an ERC-20 transfer. Its signature is transfer(address,uint256). Hash that text with Keccak-256 and read the first four bytes:

keccak256("transfer(address,uint256)")  ->  a9059cbb...
selector                                 =  0xa9059cbb

That 0xa9059cbb is the selector every wallet and explorer shows at the front of a token transfer, and you can reproduce it by hashing the signature in the Keccak-256 tool and taking the first eight hex characters. Hash the same text with standard SHA3-256 and the four bytes come out different, which is exactly the trap this article is about.

The takeaway

Keccak-256 and SHA3-256 are close cousins separated by a single padding byte that NIST changed during standardization. Ethereum locked in the original before that change, so every address, selector, and storage slot on the network uses Keccak-256. When your hashes refuse to match the chain, reach for the Keccak function rather than SHA-3, and confirm the value above in a click.