This commit maps this kind of errors
`status-proxy-0.error: failed with 50011064 gas: insufficient funds for gas * price + value: address 0x4eeB09cf0076F840b38511D808464eE48efD4305 have 0 want 10000000000000`
to this form:
`status-proxy-0.error: failed with 50011064 gas: insufficient funds for gas * price + value: address 0x4eeB09cf0076F840b38511D808464eE48efD4305`
which means that we don't want to display to a user details of how much they have and how much is needed for fees, cause those data are very often
misleading, referring mostly to "how much user has".
New error added in case there is no positive balances across all enabled chains.
* chore_: unused `BuildTx` function removed from the processor interface and types that are implement it
Since the `BuildTx` function is not used anywhere, it's removed from the code.
* fix_: resolving nonce improvements
When the app sends more than a single tx from the same account on the same chain, some
chains do not return appropriate nonce (they do not consider pending txs), because of
that we place more tx with the same nonce, where all but the first one fail.
Changes in this PR keep track of nonces being used in the same sending/bridging flow, which means
for the first tx from the multi txs the app asks the chain for the nonce, and every next nonce is resolved
by incrementing the last used nonce by 1.
The Router algorithm is checking all the routes in order to find one the user has a balance to execute it
even that one is not the cheapest one. But if the user has some balances, but not enough to execute any
of suggested routes, we we're returning the last route which was checked, with the changes from this commit
we will return the last route for which the user has some balance, but not enough.
* fix_: filtering out routes which do not match the amount in
* fix_: finding the best route logic updated
* fix_: "to" chains being used in sending bridge tx via hop are more explicit
Using `ChainIDTo` depicts better an intention which chain should be used.
* chore_: checking for required balance improved
An error contains now more details, for which token on which chain there is not enough balance for
executing a tx. Also check for required balance now calculates in fees for all tx that possibly can be
sent from the same chain.
If there are multiple routes across multiple networks, but the user doesn't have a positive balance
on the network which the router initially suggested as the best (cheapest) route, then we are not returning
an error saying there are not enough balance, but instead try to suggest the route on the network where
the user has a positive balance even that's not the cheapest route (it should be the second cheapest route,
but if there are not enough balance on it we proceed with the third cheapest route and so on...).
- router logic splitted into two more logical functions
- locked amount validation improved
- hop and swap processors cached data kept per from/to chain and from/to token
- Clear function which clears the local cache is added
- process of evaluating `amountToSend` if more than a single network is locked is improved
- optimized params for require approval function
Dario Gabriel Lipicar
Igor Sirotin
Sale Djenic
Andrea Maria Piana
frank
saledjenic
Ivan Belyakov
belalshehab
Emil Sawicki
Anthony Laibe
Samuel Hawksby-Robinson