Consider standardized representation of bridged asset relationships (L1 -> L2 or L1 -> L1)

[moodysalem]

Token lists may contain tokens on multiple chains, for example Ethereum Mainnet, Rinkeby and Optimism. These tokens can be 'bridged' versions of each other, e.g. DAI might be bridged from Ethereum Mainnet to Optimism. There could be a standard way to represent the relationship between these tokens.

One option for extending the schema:

 {
    "chainId": 1,
    "address": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
    "symbol": "USDC",
    "name": "USD Coin",
    "decimals": 6,
    "otherChainAddresses": { "420161": "0xAAAA...AAAA" }
}

Other things we may want to include in the token list specification:

• bridge function ABI
• bridge contract address on layer 1 and/or layer 2

How we do this depends on the intended usage in the interface. For now, since there is not an obvious way for us to use it as with other token metadata, it's may be ok to use extensions.

[DannyDelott]

It might be possible to address this with tags as well.

In your example, a consumer would have to know the mainnet token first before they could get at the otherChainAddresses. A tag-based alternative might look a bit flatter/easier to access depending on the consumer.

 {
    "chainId": 1,
    "address": "0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48",
    "symbol": "USDC",
    "name": "USD Coin",
    "decimals": 6,
    "tags": ["USDC", "L1"],
},
{
    "chainId": 420161,
    "address": "0xAAAA...AAAA",
    "symbol": "USDC",
    "name": "USD Coin",
    "decimals": 6,
    "tags": ["USDC", "L2"],
},

[moodysalem]

@uniswap/token-lists was updated to allow objects to be nested 2 levels deep as of 1.0.0-beta.26

here is a proposed schema for representing the cross chain token info in the extensions:

bridgeInfo is an extension that contains a map of other chain ID to an object containing other token info, like so

"tokens": [
  {
    // ...
    "chainId": "<source chain id>",
    "extensions": {
      "bridgeInfo": { 
        "<destination chain id>": {
          "tokenAddress": "<token address on destination chain id>",
          "originBridgeAddress": "<optional address of the bridge contract on the source chain id>",
          "destBridgeAddress": "<optional address of the bridge contract on the destination chain id>"
        }
      }
    }
  }, 
  {
    // ...
    "chainId": "<destination chain id>",
    "extensions": {
      "bridgeInfo": { 
        "<source chain id>": {
          "tokenAddress": "<token address on source chain id>",
          "originBridgeAddress": "<optional address of the bridge contract on the destination chain id>",
          "destBridgeAddress": "<optional address of the bridge contract on the source chain id>"
        }
      }
    }
  }, 
  // ...
]

e.g.:
https://github.com/Uniswap/token-lists/blob/e2a796f3f021949b986b9ac9f84a17be92498702/test/schema/example-crosschain.tokenlist.json

[DZGoldman]

@moodysalem I like it! One thing to consider is the (inevitable) representation of one to many relationships for a bridged token between 2 given chains (i.e., USDC bridged from Ethereum to Arbitrum via the Arbitrum bridge vs. USCD bridged from Ethereum to Arbitrum via the Celer bridge). In the current proposal, to list both, you'd need 2 different entries of USDC w/ Chain ID 1 at the top level (I think), which doesn't spark joy. An alternative would be something like:

  "tokens": [
    {
      "chainId": "<source chain id>",
      "extensions": {
        "bridgeInfo": {
          "originBridgeAddress-1": {
            "tokenAddress": "<token address on destination chain id via bridge-1>",
            "destBridgeAddress-1": "<optional address of the bridge contract on the destination chain id>",
          },
          "originBridgeAddress-2": {
            "tokenAddress": "<token address on destination chain id via bridge-1>",
            "destBridgeAddress-2": "<optional address of the bridge contract on the destination chain id>",
          }
        }
      }
    }
  ]

Not sold on this either, and maybe there's a case that a given list should be opinionated towards a particular bridge, but just a thought.