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.

[moodysalem]

Thanks for the input @DZGoldman! Definitely a valid consideration. I think most tokens will avoid fragmenting across multiple bridges but it may happen if one bridge supports features that another does not (e.g. voting with tokens held on layer 2)

Brought it up with one team and they said they only expect one bridge per token combo. Will bring it up again.

I think an array might be more appropriate than a key that combines bridge address and chain ID like that

The other option is having one entry for each layer 2 bridged token, that references the layer 1 token, but the layer 1 token only references the 'canonical' layer 2 token. We wouldn't want to have multiple token entries for the same token on chain ID 1.

[CAMP1973]

Muy e

[wallet001]

Verified

[foxweba3]

רשימות אסימונים עשויות להכיל אסימונים במספר רשתות, למשל Ethereum Mainnet, Rinkeby ו-Optimism. האסימונים הללו יכולים להיות גרסאות 'מגושרות' זה של זה, למשל DAI עשוי להיות מגושר מ-Ethereum Mainnet לאופטימיות. יכולה להיות דרך סטנדרטית לייצג את הקשר בין האסימונים הללו.

אפשרות אחת להרחבת הסכימה:

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

דברים נוספים שאולי נרצה לכלול במפרט רשימת האסימונים:

• פונקציית גשר ABI
• כתובת חוזה גשר בשכבה 1 ו/או שכבה 2

האופן שבו נעשה זאת תלוי בשימוש המיועד בממשק. לעת עתה, מכיוון שאין דרך ברורה עבורנו להשתמש בו כמו במטא נתונים אחרים של אסימון, ייתכן שזה בסדר להשתמש בהרחבות.