以太坊在 NIST 最终确定 SHA-3 之前就采用了 Keccak。随后，FIPS 202 在消息填充中加入了域分隔位（SHA3-256 的第一个填充字节是 0x06，Keccak-256 则是 0x01），因此两个函数虽然共用同一个置换和同一组参数，生成的摘要却毫无关联。空字符串的 Keccak-256 哈希是 c5d2460186f7233c927e7db2dcc703c0e500b653ca82273b7bfad8045d85a470，而同一输入的 SHA3-256 哈希是 a7ffc6f8…f8434a。
以太坊在以下地方使用它：地址（64 字节公钥哈希的最后 20 字节）、ABI 函数选择器（transfer(address,uint256) 哈希的前 4 字节为 a9059cbb）、事件主题、存储槽、EIP-191 和 EIP-712 的待签名哈希，以及 ecrecover 的输入。Solidity 的 keccak256 和 RPC 方法 web3_sha3 计算的都是 Keccak-256，尽管后者的名称容易让人误以为是 SHA-3。
典型的错误是在以太坊要求 Keccak-256 的地方调用了库中的 sha3_256（FIPS 版本）：每个摘要、地址和签名检查的结果都会出错，而且没有任何报错。应使用名为 keccak256 或 keccak_256 的函数。