Feature request: Ethereum addresses for most popular tokens

[PaulRBerg]

The idea is to ship the top 20 (or 50, or 100) token addresses according to Etherscan's tracker as constants part of a StdToken contract or stdToken library.

[mds1]

Ohh I like this idea. Addresses would vary by chain, so it seems like this might be a good way to extend the Chain return type. Perhaps we create a new struct like:

struct StdTokens {
  address dai;
  address usdc;
  address weth;
}

then add a StdTokens tokens; field to the Chain struct? If the address is the zero address, that token doesn't exist (or isn't currently defined) on that chain.

Curious to hear thoughts from @hexonaut here since I know you do a lot of cross-chain work and probably deal with a lot of token addresses.

The one wrinkle is the setChain(string, Chain) method, where now (1) it'd be a breaking change, and (2) you'd have to provide values for all tokens to use that method. @hexonaut can you remind me why someone would use that over the simpler setChain(string, ChainData) variant? Wonder if we can just leave it exposed but document it's not really intended to be used, that way breaking changes to it are ok. I'd have to look closer to see if editing Chain has other side effects, but IIRC we wanted the ability to modify that struct to add chain data

[hexonaut]

We use the chainlog at 0xdA0Ab1e0017DEbCd72Be8599041a2aa3bA7e740F to look up tokens by name (JSON dump).

The setChain(string, Chain) is useful if you want to get a chain definition then override one of the fields. An example was added in that PR.

Personally I think this may be trying to jam too much stuff into forge-std, but I see the use. We don't really need this at Maker because of the chainlog lookup table.

[PaulRBerg]

then add a StdTokens tokens; field to the Chain struct?

Works for me.

The one wrinkle is the setChain(string, Chain) method

I am agnostic about this point, because I have never used this method.