🧵  1/6
A story of ENS name collision.
Or: Why 2 porn.eth names exist on Ethereum, owned by 2 different users.

This on-chain, verifiable flaw is caused by ENS failing to normalize names at the smart contract level👇

🧵 2/6
Here are 2 different ENS tokens for porn.eth:

🔹 https://etherscan.io/nft/0x57f1887a8bf19b14fc0df6fd9b2acc9af147ea85/112949967429184082454739782909889739131486107998301027276068349562904797016486

🔹 https://etherscan.io/nft/0x57f1887a8bf19b14fc0df6fd9b2acc9af147ea85/14387534913093838064957895154418352368986145059760662886925566701940372781735

2 separate ENS NFTs. 2 different owners.

A decentralised cooperative for impactful projects ✨ app.0xname.foo - *free*, *various*, *yours* web3 names on Ethereum | faucet.0xname.foo - Sep $ETH faucet

🧵 3/6

Why did this happen?
ENS uses Keccak-256 hashing, and hashing is case-sensitive.
ENS failed to enforce lowercase normalization at the smart contract level, so:

✅ porn.eth ≠ Porn.eth

✅ Both names were allowed to be registered separately.

🧵 4/6

Wait… but how did Porn.eth get registered?  🤔

1️⃣ ENS did NOT enforce basic string normalization (AAA → aaa) in smart contracts.

2️⃣ The second user called ENS contracts directly, bypassing front-end rules.

The ENS off-chain UI prevents this, but the smart contracts allowed it.

🧵 5/6

But why does Etherscan show both names as porn.eth?

Seems Etherscan follows ENS’s off-chain normalization rules and lowercases names before displaying them.

Other platforms, like Rarible, probably just call ens api to resolve:

🔹 https://rarible.com/token/0x57f1887a8bf19b14fc0df6fd9b2acc9af147ea85:112949967429184082454739782909889739131486107998301027276068349562904797016486

🔹

🧵 5/6

But why does Etherscan show both names as porn.eth?

Seems Etherscan follows ENS’s off-chain normalization rules and lowercases names before displaying them.

Other platforms, like Rarible, probably just call ens api to resolve:

🔹 https://rarible.com/token/0x57f1887a8bf19b14fc0df6fd9b2acc9af147ea85:112949967429184082454739782909889739131486107998301027276068349562904797016486

🔹 https://rarible.com/token/0x57f1887a8bf19b14fc0df6fd9b2acc9af147ea85:14387534913093838064957895154418352368986145059760662886925566701940372781735

🧵6/6

Is basic string normalization hard to do in smart contracts?  No!!!

🔹 Uppercase A-Z (ASCII 65-90) → Lowercase a-z (ASCII 97-122)

🔹 Simple math: A (65) + 32 = a (97)

ENS could have enforced this on smart contracts before hashing —but they didn’t.
Hope, this will be fixed.