I’m puzzled by the choice using an array, which has to be traversed, when a mapping could be used instead.
Why not replace
In the resolver ?
In order to query an address, you would just have to lookup the value of a specific coinType for a given node, without having to translate the cointype into an index.
And then why stop here ? Just have a generic
function setMetadata(bytes32 node, bytes32 key, bytes memory value) public onlyOwner(node);
function metadata(bytes32 node, bytes32 key) public view returns(bytes memory);
Which could be used for ANY metadata (similar to what ERC725 proposes) and use specific keys to store addresses. For exemple
metadata(node, keccak256("multicoin.litecoin")). The result would either be empty (nothing here) or be interpreted according to the key.
This would not only solve the multicoin issue but could also be used for other projects. An ID project could just as well use
metadata(node, keccak256("DID.photo")) to store the ipfs hash of a picture. A message service could also use
metadata(node, keccak256("cryptography.publi.RSA")) … posssibility are endless.
Why always adding very specific fields to the resolver which call for constant redeployment when something like that could be (mostly) future proof.
Basically just like the
text / setText entry but with bytes instead of string so we can store non-ascii arrays without encoding/decoding issues