You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the send token screen estimates gas based on info the user has entered. So, if no recipient address or amount has been entered, we provide the best estimate we can with that info.
If an absence of info provided to estimateGas results in a failed simulation, we provide an estimate based on the blockGasLimit, which will be huge relative to what a user will be expecting. Such failures will be more likely when we are missing the recipient address.
We can improve the UX of gas estimation on the 'Send Token' screen by providing a base estimate that should cover all token sends, and then updating that estimate only once recipient address has been entered.
Users may still see jumps in estimates after they change the amount if they are sending to an address that does not yet have any of the token. I don't think that there is anything we can do about this, except that ideally our base estimate will be something that usually goes down as new info is added, but which never is extremely high (which it doesn't need to be in the case of a token send).
Currently, the send token screen estimates gas based on info the user has entered. So, if no recipient address or amount has been entered, we provide the best estimate we can with that info.
If an absence of info provided to estimateGas results in a failed simulation, we provide an estimate based on the
blockGasLimit
, which will be huge relative to what a user will be expecting. Such failures will be more likely when we are missing the recipient address.We can improve the UX of gas estimation on the 'Send Token' screen by providing a base estimate that should cover all token sends, and then updating that estimate only once recipient address has been entered.
Users may still see jumps in estimates after they change the amount if they are sending to an address that does not yet have any of the token. I don't think that there is anything we can do about this, except that ideally our base estimate will be something that usually goes down as new info is added, but which never is extremely high (which it doesn't need to be in the case of a token send).
This will partly address issue (d) in #4645
The text was updated successfully, but these errors were encountered: