Since I last wrote “ How to Support ENS for Multi-Chain Dapps “, multiple apps integrated with ENS following our suggestion including defi giant like Aave.
It’s great to see my primary ENS name regardless of which EVM compatible chain I connect to. The increasing number of other blockchains now supports EVM and its hexadecimal with checksum.
However, our recommendation leaves out one important edge case, Contract wallet addresses.
Contract wallets such as Argent and Gnosis Safe do not usually use the same contract address across different chains. If you send funds from a side chain to mainnet smart contract addresses, but the recipient cannot access the address on the side chain because the smart contract wallet was not deployed with the same address, then you end up losing funds.
One way to prevent this which we suggested before 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).
Currently, over 17 EVM address compatible chains are supported though it is relatively underutilized.
Symbol Cointype # of Records
OPT 614 1
GO 6060 3
POA 178 1
NRG 9797 0
FTM 1007 8
THETA 500 11
XDAI 700 44
TT 1001 1
EWT 246 3
CELO 52752 9
CLO 820 1
TOMO 889 1
ETC 61 118
We would like to add as many EVM compatible chains fast but one of the bottlenecks against doing so is the need to register a SLIP44 to obtain the coin type.
To solve this problem, we decided to allocate all EVM cointype in the range of 0x800000000 which is currently reserved at SLIP44 as msb (most significant bit) and hence no coin types exist in that range.
To compute the new coin type for EVM chains, you have to do 0x800000000 | chainId
or call convertEVMChainIdToCoinType(chainId)
, a function provided by @ensdomains/address-encoder npm module.
> const encoder = require('@ensdomains/address-encoder') > encoder.convertEVMChainIdToCoinType(61)2147483709
You can also use existing functions formatsByName
and formatsByCoinType
to derive these chain IDs
> encoder.formatsByName['XDAI']
{
coinType: 2147483748,
decoder: [Function (anonymous)],
encoder: [Function (anonymous)],
name: 'XDAI'
}
> encoder.formatsByCoinType[2147483748]
{
coinType: 2147483748,
decoder: [Function (anonymous)],
encoder: [Function (anonymous)],
name: 'XDAI'
}
As part of the change, the following coins will have their coin id changed to the new with the number of existing records set.
NRG 0 records
POA 1 record
TT 1 record
CELO 13 records
CLO 1 record1
TOMO 2 records
EWT 5 records
THETA 13 records
GO 4 records
FTM 15 records
XDAI 47 records
ETC 125 records
As you can see, most of the chain ids only have a few records except for a few (eg: ETC has 125 records set).
If you have set one of these coins, you can still see your old record under _LEGACY
coin type but you can no longer update so you have to set records to the new one.
Credit: Source link