-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UX for archived token balances #1438
Comments
@sdfcharles I only see designs for extending TTLs, and we have a separate task for that (#1689). What is the UX for when token balances have been archived? |
Updated designs here: https://www.figma.com/design/C3G0a4Gd6RQyplRBppGDsL/Freighter-(SDS-v3)?node-id=2932-3383&t=NNZIouOPrlmRWQS4-1 Included states for when a token balance is archived and a notification on the home screen when a token balance has been archived |
Thanks @sdfcharles, but I'm not sure if we want to even inform a user that their balance is archived, because they actually won't have to explicitly restore their balances before they can use them after protocol 23 is live. After protocol 23, if a transaction involves an archived entry, it will automatically be restored when the transaction is executed, and all the user needs to do is make sure their fee is high enough to pay for the restoration. What that means for us is that regardless of whether a transaction is sent to freighter from a dapp or a transaction is initiated from within freighter, we can go about our normal signing and submission flow without having to do anything different in our UX for transactions that use archived entires. |
Do you think that it makes sense to inform the user of why their fee is higher than without the accompanying restore operation, or will the fee difference be negligible? Maybe only more sophisticated users will even notice this but I feel it could be weird to prepare a tx that you might do often and have it sometimes have a higher fee than other times. |
Yea I would think ideally Freighter would give you detailed info on why your fee is what it is, but I don't know if we can do that for all transactions yet. I don't see any details on cost provided in RPC's simulation endpoint response definition. Maybe this something already discussed on the platform team? cc @mollykarcher So maybe for now we can do something specifically for when transactions restore archived entries. As for what level of detail to provide, I'm not sure. I would think just some UX acknowledgment that the fee is higher due to restoring necessary entries would be sufficient, as opposed to actually providing the entires that are being restored as a result of executing the transaction. |
Yeah agree I think it makes sense to just at least have some sort of by-line or copy that informs you that "fee is higher than usual because you need to restore your entry before using it" but maybe in not so many words 😅 |
Tasks
The text was updated successfully, but these errors were encountered: