Iterating on Wallet Balances #2052
Replies: 3 comments 2 replies
-
|
Following up on this with a note just to say that there is sentiment from quite a number of folks, mostly technical / developers, that are interested in just seeing a NEAR balance as the primary balance in the wallet that does not include other fungible tokens. Since there are opinions in opposition to this as well, I'll be doing a bit of user research over the next week to get a better feel from a larger sample size. I'll be including some questions to validate some of the above. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for summarizing the challenges and potential improvements around current wallet balances. I really like this approach and agree that we should separate staking, lockup, and account balance. Having a ‘portfolio balance’ is beneficial as a snapshot of all balances. However, it does make it seem like staking, lockups, etc, are actually part of the main account. Complete separation makes it explicit that the funds have been transferred out of the account into a staking pool, etc. Where would amounts ‘reserved for storage’ for the account, 2FA, etc, be displayed? Since most of these storage amounts are rather small, personally I’d be OK with just a summary ‘reserved for storage’ number like we currently do, vs separating by account, 2FA, apps, etc. |
Beta Was this translation helpful? Give feedback.
-
|
My comments, by proposal ID:
To elaborate more on 2 and 4, a lockup and a staked balances are not that different from other fungible tokens (think of wrapped near) and may help the user understand how having multiple balances in the same account works. Re: available balance inlcuding other tokens: can it be interactive? Can we let the user "switch on and off" his tokens, and see them counted in the total balance based on his preference? |
Beta Was this translation helpful? Give feedback.
-
|
@stefanopepe For what you are describing in 2&4, I'd like to do some prototyping and user testing with a couple variations to validate any solutions before we implement that, since it's not totally clear at the moment what mental model most users who stake and/or have lockups currently maintain. Since there are many obvious advantages to emphasizing the wallet's available balance, especially in conjunction with the upcoming changes to our onboarding UX, I think our first actionable step is to make that change, followed by some testing around how best to represent lockups and staking if they could be different from what was shared above. How does that sound? |
Beta Was this translation helpful? Give feedback.
-
Yes I think this could be interesting but again also worth testing with a prototype so we can evaluate its usefulness |
Beta Was this translation helpful? Give feedback.
-
Recent feedback around fiat conversion has highlighted some of the ways in which our Total Balance figure causes confusion for some users depending on the ways that they interact with their account. Aside from fiat conversion itself, there are some opportunities that exist for us to take a step back and reconsider how a user reasons about balances in the wallet that could ultimately lead to more transparency and clarity.
A short history:
Lockups: When launching to mainnet, people panicked that they couldn't see their associated lockup accounts in their wallet. The reality is, even if an account is associated with a lockup, the lockup is actually a different account entirely. You can stake from a lockup, but those funds are actually not available to you until certain conditions are met. To try and meet the need to surface lockup accounts, a table was added to the account page to show a breakdown of your account balances. This now included your associated lockup account, even if in reality, it exists as a different account all together.
Staking: The launch of staking in the wallet introduced a need to reflect your staking balances. A decision was made to emphasize a "Total Balance" figure that included any tokens being staked with a validator. I believe this was one of the first mistakes that started us down a path of trying to incorporate all funds "owned" by a given account into the Total Wallet balance. The reason that this is a mistake, is that when funds are staked, they are actually removed from a wallet, and moved to a staking pool to earn rewards. In this way, they are actually no longer a part of the balance of the wallet from which they originated. Unfortunately, the wallet balance figure does not reflect this, and retains these funds as a part of the total balance figure, leading to additional complexity around the "role" of the primary balance figure in the wallet.
Storage Deposits: When a wallet account generates a full access key for a contract, a small storage deposit is reserved and "locked" in a sense. It is made inaccessible until the owner of the account decides to delete the key, at which point the storage deposit is returned. The storage deposit is also included in the "Total Balance" of the wallet account.
The primary issue with the current Total Balance approach is that it does not reflect the reality that during events like staking, funds are actually moved out of the wallet into separate contracts. The Total Balance remains unchanged, and only the deemphasized available balance is changed.
This creates the illusion that the funds are still present in the wallet account as a part of its total balance, which in fact isn't true. This introduces some friction since users have questions about how the Total Balance is figured, and what it includes.
Proposal
I'd like to make a proposal that we introduce a separation of concerns that reenforces the reality of where funds are located at any given time, and what kind of access the wallet owner has for each of those balances.
The primary account balance should be the available balance, which is a sum of assets that the user has that are immediately available to trade or transfer.
When funds are moved out of the wallet, the amount should be subtracted from the wallet balance and reflected at the location to which they have been moved. In the case of staking: staked funds would no longer be included as a part of the wallet balance, and would "live" solely inside the staking portion of the UI. When the user navigates to Staking, they would see "Your Stake", which conveys their staking balance (separate from their wallet balance).
When funds are reserved to cover storage costs, they should also be "moved" into the storage deposit total. They would be taken out of the available wallet balance, and emphasized as a separate balance that is uniquely tied to storage costs, which are returned when a key is deleted.
The impact that these changes have is to make it easier to reason about the location and availability of a users funds. The wallet balance never reflects funds that aren't available for use. When funds are moved out of the wallet to a different contract or location, they can be seen by navigating to that part of the application. The Wallet Balance is separate from the users Active Stake, which is separate from their storage deposit. At any point in time, I can operate with confidence that I know the balance I am looking at has certain restrictions and limitations around its use. I can send from my wallet balance. I can unstake and withdraw from my Active Stake. And I can delete a key to recover my storage deposit. When I perform these actions, the funds make their way back into my wallet, at which point the relevant balances update to reflect this.
Wallet balance labels across the app also become more clear. We can simply use the word "balance" instead of trying to use both "available balance" and "available to send/stake" which sound similar but are slightly different.
We can still show a total balance somewhere for users who have a desire to see the entire value of their portfolio, but we shouldn't think of it like a balance, since the funds are actually distributed across several separate contracts. The purpose of this figure should only be to give the user an idea of the total value of their portfolio, as it is not useful in determining what portions of that figure are accessible and how they can interact with it. This figure should essentially be a static sum.
Another positive side effect of all of this is that we would remove the dependency on the balance breakdown table to help the user reason about their funds. If they want to view and display a particular balance, they simply go to that part of the wallet (one click), and don't have to worry about reasoning about whether a balance includes a sum of several figures pulled from various locations throughout the experience.
Beta Was this translation helpful? Give feedback.
All reactions