I developed a walle similar to this for the NEAR & Zcash hackathon. Thanks for bringing it back to my attention gamify wallets will bring mass adaption. My vision is to have a user using a wallet at times forgetting it’s a wallet because the gamify experience it top tier.
It is true and there is also one T-address so let’s say you received funds, shielded them. And then spent them on crosspay. Everything is completely traceable to that first transaction, completely making it obsolete that you shielded anything to begin with.
It is usable if you create a temporary wallet, fund it shielded and then never use that wallet again.
Zashi devs… please, we need rotating transparent addresses.
Nevertheless, I think there needs to be change of approach here: Zashi must never share a previously used t-address without asking the user. If a feature doesn’t yet work without sharing a tainted t-address, the user must understand that. Right now I don’t know what is safe to use and what isn’t - what about any of the other services like Flexa?
The t-address is the absolutely most private piece of information Zashi has, it needs to be treated with more care. I would say it’s even more private than the seed phrase as the user might lose more by losing privacy than by losing their Zashi balance. The wallet needs to be very upfront about sharing extremely sensitive data like the t-address or the seed phrase.
I also think about future integrations like Maya. If Zashi is supposed to be serious privacy product, and not just a playground, we can’t have like five buttons in the app for swapping, paying, and so on and then have randomly three out of them defeat users’ privacy because some service has not yet implemented shielded payments. That doesn’t fly.
I’ve been using NEAR Intents swaps about 10 times for BTC ↔ ZEC and noticed:
BTC deposits are detected instantly and move from “awaiting deposit” → “processing” immediately.
After that, there can be a ~45–60 minute period with no visibility until the swap moves to “Receiving” (this processing time may have increased over the past week).
Assuming this processing time is solver-side, it would be really helpful if possible to provide some visibility into what’s happening during “processing” (solver matching / NEAR settlement / preparing outbound transaction), even if it’s just status indicators or progress updates. Currently, I only see the swap timestamp and deposit address in the app. If intermediate NEAR intent IDs or transaction data are available from the protocol, exposing them would let users track progress via blockchain explorers during the wait.
I’m not fully familiar with the underlying tech, so if there are technical constraints or reasons this visibility isn’t currently exposed, I’d love to understand them. I’m coming at it purely from a user experience perspective and would really appreciate any feedback or info.
Other helpful features could include:
Rough ETA for fulfillment
Indicators when liquidity is low or queue is long
Everything works as expected - this would just reduce uncertainty during the wait, especially during price swings.