LGTM.
My only other feedback is to have a back button to navigate from the NFT back to the Collection otherwise it's a whole lot of clicks when viewing each NFT, but that can be done as part of the NFT child implementation.
Also the fan out tx seems to cost around 300-500 XEC each tx, incl fees. Should this be mentioned anywhere in case the user fans out a dozen times and is surprised by the cost. (this is in the context of a few people recently even complaining about the 5.5 XEC fee =) )

After fan out tx, the Mint NFT UI should indicate the total number of NFT mint inputs available. I can see this info is already available on Tx.js, so tracking it here would also be useful.

version bump

Per tg chat, here's the trace:

Move off master branch

Tested fine, just a nit on code pattern

The sha256 hash matches all ok.
Is it intended that the collection NFT is rendered in amongst the standard slp1 eTokens with no differentiation? Is this just a staging area until you do the next diff to implement NFTs? That carousel styling would be good, one for each type of token.

As per tg chat

The button changes to the timer all ok, and the reward is received all ok as well. However clicking on the received CACHET throws this:

Accepted post TG chat

accepted with minor nits

In D15981#361661, @bytesofman wrote:

In D15981#361647, @emack wrote:

The effects of D15972 seems to have regressed here, allowing scrolling down when there is no content below.

could you show an example?

but also, imo the flickering is much worse than the extra scrolling. The extra scrolling situation still needs another patch anyway to deal with the size of other non-footer elements.

Minor nit not for this diff, but should add "XEC" to the Airdrop label, otherwise it looks like it was an eToken airdrop.

On a related note, are we sticking with the whole parent vs child terminology all the way through to the frontend? I recall back in 2021 there was discussion on using more user friendly terminology in the frontend, like using "Collection" for parent and "NFT" for child. This way it'll be a smoother experience for users who are used to NFT terminology from other chains.

The effects of D15972 seems to have regressed here, allowing scrolling down when there is no content below.

Can you send some ALP and NFT parent tokens to ecash:qzz0p9yux89uvgnq86u5qnztver6u7g0vqc65920xr pls? thx.

It still scrolls, albeit by a negligible 1px or so, across both mobile and web. Not a blocking issue.

This is already the behavior in prod isn't it? Toggling another send token function will disable all others.

It's not routing for me as the createdTokenId is always coming up as null in the console logs.

Tested fine on desktop and extension, but on mobile it's got some cray cray clipping happening on the onboarding screen

Accepted with minor nit on function name.

Minor non-blocking nit:
Use the existing shading in prod for the horizonal separator between txs. It's obvious enough to be a separator but not too obvious that it starts adding to the busy-ness of the screen.
Prod

Also the existing horizontal lines separating each tx should be retained, otherwise each grouping of info is not immediately obvious.

Since this diff touches on how refreshAliases is called in useWallet, can you patch the bug where right after a registration broadcast the pending alias is not immediately added to the pending aliases list, but navigating away and back to the alias screen fixes it? From a glance one of the useEffect() blocks needs to have a dependency on the aliases.pending map coming out of useWallet, so that once it is added to the pending list it can call refreshAliases.

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