You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Just went through an extended period of confusion while implementing resolution of ENS names on L2s in my app.
My goal: If currently connected to an L2, resolve names on ETH mainnet. If there's an explicit address record for the L2 in question, use this. If not, fall back to the address for ETH mainnet, but only if that address is not a contract.
What I discovered the status quo to be:
resolver.getAddress() returns the address for the name on Eth Mainnet. Makes sense.
resolver.getAddress(10) (10 being the chainId for OP mainnet) returns the address for OP mainnet set on the record. Cool, so I can just pass chainId here.
resolver.getAddress(1) (1 being the chainId for Eth Mainnet) however returns nothing, even though getAddress(), which defaults to mainnet, does. Huh?
This has some IMO pretty odd consequences for the API behavior:
As mentioned before, while resolver.getAddress(10) resolves to the OP Mainnet address, resolver.getAddress(1) does not resolve to ETH Mainnet address
resolver.getAddress(60) resolves to the Eth Mainnet address, but 60 is at the same time the chainId for GoChain. If you're not aware of what exactly coinType is but noticed that passing chainId seems to just work, you would 100% expect to receive the address for GoChain when passing 60.
I think that ideally resolver.getAddress would just accept chainId only. I see how changing the behavior of this function now would be tricky though, so maybe deprecating resolver.getAddress and replacing it with two explicit functions getAddressForChain(chainId) and getAddressForCoinType(coinType) would get rid of the implicit conversion and resulting confusion.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Just went through an extended period of confusion while implementing resolution of ENS names on L2s in my app.
My goal: If currently connected to an L2, resolve names on ETH mainnet. If there's an explicit address record for the L2 in question, use this. If not, fall back to the address for ETH mainnet, but only if that address is not a contract.
What I discovered the status quo to be:
resolver.getAddress()
returns the address for the name on Eth Mainnet. Makes sense.resolver.getAddress(10)
(10 being thechainId
for OP mainnet) returns the address for OP mainnet set on the record. Cool, so I can just passchainId
here.resolver.getAddress(1)
(1 being thechainId
for Eth Mainnet) however returns nothing, even thoughgetAddress()
, which defaults to mainnet, does. Huh?I was really confused by this until I learned what a
coinType
actually is, the fact thatENSIP-11
defines a way to derive "legacy"coinTypes
from evmchainId
s, and that Ethers implicitly treats thecoinType
argument as achainId
and converts it to acoinType
if it falls outside the range covered by ENSIP-11 and is not 60.This has some IMO pretty odd consequences for the API behavior:
resolver.getAddress(10)
resolves to the OP Mainnet address,resolver.getAddress(1)
does not resolve to ETH Mainnet addressresolver.getAddress(60)
resolves to theEth Mainnet
address, but60
is at the same time thechainId
for GoChain. If you're not aware of what exactlycoinType
is but noticed that passingchainId
seems to just work, you would 100% expect to receive the address for GoChain when passing60
.coinType
implies that e.g.getAddress(10)
would return the non-EVM address set on the record for Blackcoin, given that acoinType
of10
refers to Blackcoin as per SLIP-0044.I think that ideally
resolver.getAddress
would just acceptchainId
only. I see how changing the behavior of this function now would be tricky though, so maybe deprecatingresolver.getAddress
and replacing it with two explicit functionsgetAddressForChain(chainId)
andgetAddressForCoinType(coinType)
would get rid of the implicit conversion and resulting confusion.Beta Was this translation helpful? Give feedback.
All reactions