As an increasing number of dapps start to support multiple chains, you have started noticing that ENS names are usually shown when you’re connected to Ethereum mainnet, but not when connected to different chains.
This is because the ENS registry contracts are only deployed to Ethereum mainnet and some testnets (Rinkeby, Ropsten, and Goerli).
Our recommendation is simple: always refer to the ENS name on Ethereum mainnet (networkId 1).
On the event ticketing application called Kickback (run by me and my ENS co-worker Jeff), we have a function called
getEnsAddress that connects to mainnet and simply gets data from there despite the application itself is deployed to Polygon network (and xDai).
One of the well-known issues when it comes to L2/sidechains is that the addresses of contract wallets (such as Argent and Gnosis Safe) are mostly not compatible (unless you take extra steps). Many people send funds from the sidechain to mainnet smart contract addresses, but the recipient cannot access the address on the sidechain because the smart contract wallet was not deployed with the same address, and people end up losing funds.
One way to prevent this is for each user to set an address for each side chain in their ENS records.
Then dapps can lookup the address with a specific coin address (if you don’t specify any cointype to,
addr() function, it defaults to coin type 60, which is ETH) such as ETC(61) and xDAI(700).
The more pragmatic approach is to check if the address is EOA (Externally Owned Account) or contract account by checking the bytesize of the address and show warning message when users try to send to that address.
What happens when ENS registry contracts are deployed to the L2/sidechains you deployed your app in future? That’s still the same.
We are going to employ a secure off-chain data retrieval method called “Durin” which is drafted by Nick Johnson, our ENS lead developer. Using Durin, users still do the lookup on Ethereum mainnet to get a “Gateway URL” which retrieves data from the specific chain.
To support the Durin model, dapps developers will have to update js libraries (which is not released yet), but they should not need to change the network endpoint so this approach is future compatible.