EOSCommunity.org Forums

Token Discovery Error - Anchor Desktop

I am testing out a product which have two tokens - one for testing and other the real one. Both of these tokens are having the same symbol CETF. I have imported them both manually into Anchor using the separate contract account name and same symbol.

But upon checking the balance only one field is there with CETF and it too have trouble determining which is which. That is the balance is switching back and forth with the test token and real token with each refresh for some time and settles at one.

That means I can only use view one token at a time which should not be the case ideally.

The other balance pops up when refreshing

Leaving the link to my EOS account to check the tokens : https://bloks.io/account/thenewlegend

NEW USER : So only one media per post and 2 links. Any way to bypass this ?

But upon checking the balance only one field is there with CETF and it too have trouble determining which is which. That is the balance is switching back and forth with the test token and real token with each refresh for some time and settles at one.

It looks like the way we have Anchor determining balances doesn’t allow for multiple tokens with the same symbol, as you’ve discovered. We would need to rewrite a few portions of Anchor in order to resolve this issue since the balances themselves in the applications state are just referenced by the symbol. Ideally, the way balances are handled would segregate token symbols by the contract they come from - so you could have two balances with the same token symbol.

I dug into this today and it’s not just a simple change unfortunately. The way the balances are referenced through out a bunch of sections of the app use the symbol as the reference, so we’d need to rewrite how Anchor’s state stores balances, and then update dozens (maybe hundreds) of files to use this new naming structure. Combine that with the fact that we’re migrating all balance related information outside of Anchor (into Unicove) and completely rewriting Anchor desktop (to mirror mobile functionality), and it honestly makes it hard to justify the time investment to resolve this edge case.

If you’re interested in helping to resolve this edge case, the place to start resolve the issue begins here:

It’s the fact that within the array of balances, we’re just storing the straight response from the EOSIO APIs that reference balances by the symbol. This portion would have to be rewritten to mutate the API response into a contract-symbol delimited key in the balances array, and then everywhere the balances state is referenced would also need to be updated to use this new key format. That includes the Manage Tracked Tokens section, the Overview Tracked Tokens table, the transfer interface, the resources pages, and everywhere else a balance is referenced.

Not by default, sadly, not without opening potential spam vectors. I did just bump your “trust” level on the forums though beyond that of a new user, so I think you won’t have that problem anymore?

1 Like

Thanks for the reply. I am not that much knowledgeable in this field but am learning. So maybe I can work on it some time soon. I happened to come across this trouble when I was testing out the site and the transactions , functions etc.

If it is as you say an edge case then it is probably more easy to avoid having the same token symbol for multiple tokens. But is it then possible for someone to disrupt the transfer of an existing token by creating another token with same symbol and sending it to others wallet ?

This issue is also present in bloks.io so for an average user it might become a hefty trouble. Just a thought. I can get rid of the test token by simply using the staking contract in the site. But it can be tough to make the mass of people who uses Anchor and bloks.io aware, that is IF anything like that is possible.

Maybe I am just getting wild. Thanks for your time.

Potentially, but the user themselves would have to go into the Manage Tokens section and add that duplicate token with the same symbol. So it wouldn’t happen out of the box without a user taking action themselves. For example I could deploy a contract with a token named EOS, but it wouldn’t interfere with anyone’s token tracking unless they went in and added my EOS token to their copy of Anchor.

Yeah what you’re identified is certainly something that should be resolved, both in wallets and explorers. If a large amount of users were using two tokens with identical token symbols, there’s probably a lot of things within the ecosystem that will need to be updated to make sure the UX isn’t terrible :sweat_smile:

1 Like

Thanks for the prompt reply. Will simply avoid using same symbol for the time being :handshake:🏻