Interesting design choice, I like it.
I just tested it and if you don’t mind, here are some additional suggestions, based on my understanding that you want to give the most authority to the user and let him make explicit decisions, rather than having things done automatically for him:
- If a t-address has already been used I would show a warning on the screen where it is shown and advise the user to generate a new one, to prevent linking two transparent transactions together by reusing the t-address.
- If a user has received funds on two (or more) different t-addresses shielding them will link them together. If you want to give the user explicit choice you could warn him about the the linking and offer him a choice to just shield one of them (to prevent linking).
- It might also be a good idea to show the amount of time that has elapsed since the last shielding operation (to make timing attacks harder).
- Maybe you can even show the number of transactions that happened on chain since the last shielding transaction, if you have an easy way to query that from the backend. To give the user a better estimation if enough time has elapsed since the last shielding transaction to make timing attacks harder.
- Funds received in multiple transactions on the same t-address can and should always be shielded together. They are linked anyway, so nothing can be gained anymore by shielding them separately.
In this post I describe a similar possible mechanism for Zashi, but with a UX where most decisions are made automatically for the user: