CoinTypes in base-provider are limited and possibly incorrect

[jmrossy]

Describe the bug
This issue is part bug report and part warning for anyone else trying to resolve non-Eth ENS addresses:

As stated in #2495 the static list of cointypes in base-provider as limited to a small set and I believe some (like xDAI) are incorrect.

The TLDR is that ENS' address-encoder lib incorrectly computes cointype using chainId instead of Slip44 id, see this issue for details. That means that XDai's cointype value won't be resolved to 700 but some large random looking number instead.

One solution is to use offload this to address-encoder and just match their bug. But @ricmoo you mentioned in #2495 that it would bloat the ethers bundle so I agree that's not the right approach.

Another solution can be to have the resolver's _getAddress method assume that coins have ilk: "eth" if it doesn't know about them. That way any EVM-compatible chains would just work without the need to keep a list up to date.

Reproduction steps

  const resolver = await provider.getResolver(myEnsName)
  // this uses Celo's actual CoinType, and so will return nothing
  const address = await resolver.getAddress(52752)
  // this uses Celo's incorrect CoinType that matches what ensJs does...
  // ...so it will receive a correct result but then error due to unknown coin
  const address = await resolver.getAddress(2147525868)

Search Terms
ENS CoinType Slip44 coinInfos

[ricmoo]

I don't know how safe it is to just assume ilk is Ethereum-compatible though; there may exist coins which have Ethereum-looking addresses, but which require a transformation first. There are a lot of strange tokens out there, and I'd rather fail to return an address entirely than risk return a wrong address. Returning a wrong address could result in assets being sent to an address that is completely inaccessible.

As a quick aside, in v6 there is a ProviderPlugin class. The core library comes with very common tokens included in its BasicMulticoinPlugin, but supports importing an ancillary package for a more thorough MulticoinPlugin. Or you can easily create a custom Plugin to handle just the tokens you care about. :)

I'm going to move this to Ideas for further discussion. :)

[jmrossy]

@ricmoo Thanks for the response. A ProviderPlugin to extend the core token list would be cool! But maybe feels like overkill just to get Ethers to treat an extra CoinType as ilk of eth ? Maybe not, guess it depends on how easy plugins will be to make.

Another option could be to have the Resolver's getAddress method take an extra optional parameter of ilk which would override the static coinInfos object. Though I understand if you'd rather keep your focus on v6 instead of making changes to v5 method signatures.

[jmrossy]

In case it's helpful to anyone else, I was able to work around the coinInfos limitation with code like this (warning, this uses a 'private' resolver method):

  const encodedCoinType = utils.hexZeroPad(BigNumber.from(coinType).toHexString(), 32)
  const hexBytes = await resolver._fetchBytes('0xf1cb7e06', encodedCoinType)
  if (hexBytes == null || hexBytes === '0x') return null
  const address = provider.formatter.address(hexBytes)
  if (address && isValidAddress(address)) return address
  else return null

[ricmoo]

FYI: that private method is safe to use, I will not be removing it in any future v5 version. :)