status-mobile
status-mobile copied to clipboard
status-im
Bridging of assets is blocked unless user has a positive balance of this asset ("Network is not available")
Preconditions:
Recover user that has an asset on network 1 only (current asset should not be ETH, DAI, or SNT)
Steps:
- Recover user with assets that are supported on 3 networks (Example: USDC)
- Go to the routes generation page 3.Attempt to bridge assets from the network where the user holds assets to another network.
Actual result:
On send page: "Network is not available" is shown in the TO section for the receiver, even though asset (a token available on all networks) is selected for sending.
https://github.com/user-attachments/assets/e8567210-8210-4c4a-9fd9-455345f933b2
On Bridge Page: The user cannot select networks on which they do not hold the asset (e.g., if the user has USDC on Optimism, they cannot select Arbitrum or Mainnet for bridging).
Expected result:
The app should allow the user to select networks where the asset is supported, even if the user does not have an available balance on those networks.
OS:
IOS, Android
Devices:
- Pixel 7a, Android 13
- iPhone 11 Pro Max, IOS 17
Logs
@shivekkhurana, @ilmotta @status-im/mobile-qa @xAlisher @vkjr - If simple send is happening in 2.31 will this still be needed? I think you should properly plan ahead for this to spare any double work.
Good question @J-Son89. I don't know as well. It depends on how simple send will overlap with the existing complex send feature. Will complex send be removed/disabled and will we only support simple send until we reach a butter smooth experience?
Good question @J-Son89. I don't know as well. It depends on how simple send will overlap with the existing complex send feature. Will complex send be removed/disabled and will we only support simple send until we reach a butter smooth experience?
Imo it should absolutely be this, remove the complexity complete and have the simple things working exceptionally. The network preferences should be removed as even that is another set of complications to support and add no value with simple send. @xAlisher should have the clearest picture on this but I think both of us agreed on that approach
@J-Son89, good point! No work done yet regarding this issue and there is no reason to do anything before simple send is in place. But when implemented, it is worth rechecking the simple send with the account @VolodLytvynenko mentioned in the description. So we can put blocked label until that time. Wdyt, @shivekkhurana @ilmotta ?
still valid. Not related to new rpc from https://github.com/status-im/status-mobile/pull/21378
Issue wouldn't be valid after re-design of Send flow (as per this comment ), also it is not really block user from sending tx, so I don't think that we need to work on anything blocked now.
Removed from milestone, cc @shivekkhurana
Additionally, such wrong validation is performed within the network edit drawer
@pavloburykh @churik
- Is this needed for 2.31 or not ?
- Is this still a bug ?
@shivekkhurana
It is still a bug and it blocks bridging, but there are more problems with bridging, i.e. https://github.com/status-im/status-mobile/issues/21180 and https://github.com/status-im/status-mobile/pull/21116, which basically make our bridge not usable.
Up to you and @ilmotta to decide, but I'd consider to block this functionality if we're facing these issues.
More info: this thread
Preliminary update:
Mobile actually depends on the token data (balances-per-chain key) for networks supported by the token.
If the token is actually supported in a network but has no positive balance, mobile expects 0 balance in that chain ID/network. I will check how Desktop does.
