I think there’s a few things here:
-
1-letter
.ethNames- I agree other chains are a good use-case but I’m sure other ideas exist.
-
Cross-chain registrations
- This requires some kind of bridging / paymaster setup for
.eth - As you say, a different basename like
s.eth, can be ENSIP-10 and offchain and only needs trustless gateway infrastructure to be ENS-grade.
- This requires some kind of bridging / paymaster setup for
-
Standardization
- If you store metadata on Solana, I think there should be some design consideration for the most modern-but-backwards compatible storage setup that supports current and potentially-future ENS protocol changes.
- coinless
addr()?pubkey()? resolve()expects EVM ABI-encoded calls- what about native resolution and reverses?
- is there a Solana provider ENS front-end
- will it resolve
addr(solana)ofraffy.ethas expected (eg. Solana-based CCIP-Read)
- coinless
- If you store metadata on Solana, I think there should be some design consideration for the most modern-but-backwards compatible storage setup that supports current and potentially-future ENS protocol changes.
Solana → EVM L2 is probably significantly easier than a native Solana implementation, but the ultimate value of ENS comes from the decentralized qualities of on-chain .eth registrations, which has encouraged wide-spread client and wallet support.
It’s unclear to me how much of “I can register a name on Solana and pay with Sol and it works in ENS” cares about native-storage vs ease-of-use.
Even a native Solana solution would have to bounce all non-native resolution to an Ethereum RPC or some kind of new cross-chain trustless gateway interconnect.