Unique symbols for tokens about sdk

[bleaker0x]

With a few exceptions, I try to keep the symbol field of tokens populated with the result of the .symbol() contract call. It's not super helpful as a unique identifier in general; one example is UST: there are several UST wrappers which are used almost interchangeably by the Terra bridge, all of which have the symbol "UST".

Your point about having a unique identifier available is well taken, though. In terms of your usage of such a field within the API, does it matter to you whether or not the unique ID is human-readable as well as unique, or just that it's unique? No matter what, I'll most likely generate and hard-code ids to provide consistency.

[trenchawr]

Right now, all the BaseToken keys, eg DFK_USDC are acting as the unique identifier for the token so I've been able to work my way around this in the API.

Ideally something that is human readable and unique, like what you're using above would be best. I think it's worth thinking about what id/hash would be natural to a multi chain token.

[bleaker0x]

@metagabbar do you think it makes sense to have a unique ID per-chain? For example, nETH would have a "prefix" of "neth" and a suffix per-chain? Ie. "neth_AVAX", "neth_BOBA"`, etc.

The Wrapped Ether token for Avalanche is WETH_E with no indication it's avalanche other than it's addresses array

To this point, do you have any suggestions for how to address this from a code perspective? I can (and should, and plan to) considerably improve JS/TSDoc for tokens, but are there any helper properties/methods that could be exposed?

[trenchawr]

@metagabbar do you think it makes sense to have a unique ID per-chain? For example, nETH would have a "prefix" of "neth" and a suffix per-chain? Ie. "neth_AVAX", "neth_BOBA"`, etc.

The Wrapped Ether token for Avalanche is WETH_E with no indication it's avalanche other than it's addresses array

To this point, do you have any suggestions for how to address this from a code perspective? I can (and should, and plan to) considerably improve JS/TSDoc for tokens, but are there any helper properties/methods that could be exposed?

I think this is a decent approach, but it somehow doesn't sit well with me because we're effectively augmenting the object with an attribute which has redundant data. We know the token symbol, and we know the chains it's available on and you already mentioned that you're effectively naming the symbol token the same as the .symbol() contract call

I was thinking something more id-ish, like a dumb but working solution would be to have a hash of JSON.stringify(Tokens[Tokens.AVAX]) or something like that. Thoughts ?

[bleaker0x]

like a dumb but working solution would be to have a hash of JSON.stringify(Tokens[Tokens.AVAX])

I don't like this but it might be the best immediate option, and I can't think of anything better.

[bleaker0x]

@metagabbar Install @synapseprotocol/[email protected]. With commit 28846fc, the Token interface now has a hash property which is -- for now? -- calculated at object initialization time by taking the MD5 sum of a few key properties of the token object.

Going to leave this issue open for now, but please let me know if the above solution works for you.

[trenchawr]

@metagabbar Install @synapseprotocol/[email protected]. With commit 28846fc, the Token interface now has a hash property which is -- for now? -- calculated at object initialization time by taking the MD5 sum of a few key properties of the token object.

Going to leave this issue open for now, but please let me know if the above solution works for you.

Yes, _hash property lgtm. Focusing on indexer project right now, so I'm not going to migrate the API to use this attribute just yet, but this is a much needed addition. WIll get back when I integrate it! Feel free to close out tho

[trenchawr]

@bleaker0x unrelated, but if you can take a look at support channel #ticket-01003 on discord and see if there's something you can /contribute would be great