Updated jup token fetch to directly load unverified tokens

[ritrafa]

Created in relation to gib.work request: https://v2.gib.work/tasks/0e250d38-b646-41a6-b5e9-913964701416

The core issue is the lookup for token data is just using jup's strict token list, leaving out metadata for many governance tokens.

I designed three potential fixes:

1. Swap from strict to full token list (this will add some loading time, but could perhaps be further enhanced to cache some of that info instead)
2. Swap to do a direct token metadata lookup instead of using the token list at all
3. Do a hybrid, where the strict list is loaded, and then if any token is missing from it a direct lookup is used instead

I decided that ultimately 3 would be the best solution, but this added the additional need of an async call for getTokenInfo(). If the team would prefer I pursue 1 or 2 instead, I will revise my PR.

To resolve this without making major structural changes, I added a new function in tokenPrice.tsx, getTokenInfoAsync(), which works as follows:

1. Check if the token is on the strict list, and if so load from there
2. Check if the token metadata has been added to the unverified token cache, and if so load from there
3. If not, use jup's api to get the individual token metadata
4. Restructure the response data to match the TokenInfoWithoutDecimals struct
5. Save to the unverified token cache
6. Return the token metadata

This of course also necessitated a new async getTreasuryAccountItemInfoV2Async() in treasuryTools.tsx

These changes together create a simple fallback for tokens not on the strict list to be automatically visible in Realms. I only updated from getTreasuryAccountItemInfoV2 --> getTreasuryAccountItemInfoV2Async on the convertAccountToAsset.tsx file, but the same change can easily be added to other uses of it if it is decided to be implemented.

Also, just to state it, the strict token list are generally accepted tokens, by allowing any token data to be loaded, a bad actor could send a distasteful token to a treasury, then show it as a DAO holding for potentially bad PR. I think this is low probability, and likely would be ignored by web3 people if something like that occurred, but still worthwhile to consider.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
governance-ui	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 23, 2024 2:24pm

[vercel]

@ritrafa is attempting to deploy a commit to the blockworks-foundation Team on Vercel.

A member of the Team first needs to authorize it.