The decision: do the boring thing, faithfully

There’s a temptation, when you’re building something that overlaps with an established standard, to “improve” it. Add a twist. Make it yours.

I did not do that.

For text records, I implemented EIP-634 exactly as ENS does. Same function signature. Same event signature. Same indexed-and-non-indexed key pattern (so logs are filterable by hash but readable for the original string).

For contenthash, I implemented EIP-1577 exactly. Raw multicodec-prefixed bytes. No on-chain validation of the codec format — let frontends parse, like every other resolver does.

For ERC-165 supportsInterface, I returned true for all four standard interface IDs:

• 0x01ffc9a7 — ERC-165 itself
• 0xf1cb7e06 — ENSIP-9 multi-coin addr(node, coinType)
• 0x59d1d43c — EIP-634 text(node, key)
• 0xbc1c58d1 — EIP-1577 contenthash(node)
• 0x691f3431 — ENS name(node) reverse

The reason for this conservatism is not laziness. It’s strategy.

If I implement these standards exactly, then every wallet that already integrated with ENS works with .dex automatically. MetaMask doesn’t need a .dex plugin. OpenSea doesn’t need a partnership. The official ENS app — running on Ethereum mainnet, completely unaware that .dex exists — could in principle resolve a .dex name if pointed at my resolver, because the interface is identical.

That’s the real prize. Not the feature itself, but the inheritance of nine years of ENS tooling work.