Possibly there is the same address twice in your contact list from testing

That was it

The issue I can see with this feature is the process of killing a zero is never a one off event. You could have the scenario where we go months on end where the price is constantly killing and reviving a zero, which would result in wallets being inundated with these alerts. One mitigation would be to introduce this with a toggle in General Settings, so users who don't mind frequent alerts can explicitly switch it on. And if they get sick of it then have the option of disabling it.

It allows duplicate contact names to be added (with different addresses). If they have a long contact list this might become hard to manage. It's the case in prod as well but if we want to check on unique contact names it might be fine to do it in this diff.

Manual op_return raw input works well

TokenListItem isn't liking this

• Unit tested helper function to get circulating supply
• Unit tested helper function to get (net) burn or mint
• Implement functions
• Clean up rendering (spinner instead of "Loading..." ?)

Now if you enter in an invalid message (i.e. over length limit), then close the message toggle, the Send button is disabled even though theoretically it should be sending the tx without the message.

Is the following expected behavior?

1. fill in valid address, amount and message
2. close the message toggle indicating the user has changed their mind about sending this with a message
3. click send and observe on the explorer that the message was sent anyway

As per tg chat

This is the same in master.

I'm getting little squares where there would have been -0 XECs. Is this a font thing?

Subject to some material rebases

subject to rebasing to latest changes to txHistory parsing and sendToken UI

version bump and rebase

How do you feel about using a carousel type UI to browse through the list of tokens? It's something that NFT wallets in ethereum uses to great effect because the UI size is ringfenced regardless of how many tokens you have.

In D15810#357697, @emack wrote:

grep -r console.log src/ -- still a few left, but they are removed in D15804

Still seeing two remaining in useImage even though D15804 has since landed

grep -r console.log src/ -- still a few left, but they are removed in D15804

It current enables the Send button when the aggregate send amount is exactly the same as the wallet balance, which shouldn't be the case because then there wouldn't be enough to pay for the txFee.

The switches on the airdrop screen are too large relative to the rest of the UI, should resize to match the ones on config

Accepted, assuming the overall UI here will be improved separately.

In D15804#357425, @bytesofman wrote:

In D15804#357421, @emack wrote:

Testing in incognito solved the issue above, however now when creating a new token with an icon, getting the following:

The token is created regardless.

Based on my previous reviews of the token server I think this is due to the icon being over 500kb? The test png I used was 2mb. In which case the size error here should be clearer to the user so they can adjust it themselves.

Edit: nvm, tested it with a 114kb png and it's still getting rejected as well with the same message and console logs.

is this from localhost:3000 ? could be the whitelist at token server

will check it out

Testing in incognito solved the issue above, however now when creating a new token with an icon, getting the following:

Burning the remaining balance of an eToken results in a blank page rather than being routed back to the token list view (as per master/prod).

Same issue upon startup as D15804, however for reference D15748 loads fine without this issue.

Getting this uncaught exception upon startup. This is after npm ci.

Now consistently getting this uncaught exception upon the creation of a new token, line 593 of useWallet didn't seem to have an obvious cause for this.

computer says no

Error workflow:

1. Open Send and observe the camera auto opens as expected (since the config toggle is true)
2. Toggle the auto open camera config to false
3. Open Send and observe camera does not auto open
4. Toggle the auto open camera config to true
5. Open Send and the camera does not auto open again
6. Despite refreshing app a few times, camera still does not auto open with the config set to true.

Tested ok, just a minor nit in function comments

It's not immediately clear whether each notification is an error, success or warning message at a quick glance. I would suggest using either a green tick/red cross/yellow exclamation mark to accompany each notification (via the icon prop) or customize the background color depending on the nature of the message. White text on black bg can be interpreted in different ways.

Much better

Error workflow:

1. 100 XEC airdrop for 1c6c9c64d70b285befe733f175d0f384538576876bd280b10587df81279d3f5e, which should give you the following:

Tested all ok but it looks really out of place with the thick border

I'm seeing a perma-lock on incognito mode (which has no existing wallet in storage).

• No errors in console.
• Already tried npm ci.
• Reloaded and hard-refreshed multiple times.

Likely the cashtabLoaded state var isn't being set in the onboarding process?

I'll ping you on tg to whitelist my IP. Given the changes it would be good if I can manually test the token creation process in case there's something not obvious to the int tests coverage.

Is there a difference between an unknown token vs an invalid token that does not conform to SLPv1 or ALP standards?