Insufficient funds for gas error is thrown when building L1-L1 routes despite user has enough funds to cover fee

[pavloburykh]

User has enough balance on L1 ETH to cover fee. Please try to test on Mainnet not testnet. Looks like it is more reproducible on Mainnet.

Steps:

1. Try sending tokens / collectibles L1-L1
2. See if routes are build and user if able to perform transaction

Actual result: very often ``insufficient funds for gas``` error is thrown when building L1-L1 routes despite user has enough funds to cover fee

On the video below you can see me trying to build L1-L1 route in order to perform 0.01 ETH transaction. My balance is 0.015.

Finally (at 01:11) I was able to build routes and perform transaction.

The final fee according to etherscan https://etherscan.io/tx/0xe38a312a2dab16212aae551a5831f8e06a2b9c95d6df7ae204bac0418b54e2f9 was just 0.000020496115248 ETH ($0.05) which means I had enough funds on balance cover fee and despite this fact I received errors multiple times.

logs (43).zip

https://github.com/user-attachments/assets/3ecef998-cf35-4942-81d6-564b5a4064f7

Additional Information

• Status version: release 2.30
• Operating System: Android, iOS

[alwx]

The main finding is that it's not a mobile issue, the same happens on desktop, and likely due to proxy. Follow this for more information: https://discord.com/channels/1210237582470807632/1270072144067563520/1275893262594347068

[anastasiyaig]

thats the same issue discussed in https://discordapp.com/channels/1210237582470807632/1270072144067563520/1275893262594347068

i was able to reproduce as well on desktop: on account used for this i have only 0.015 eth and i tried to send collectible (erc721)

[VolodLytvynenko]

Hi @saledjenic, due to this issue, L1 is almost unusable. It's rare to get routes for this network, making it difficult to send assets or collectibles related to L1. Do we have any updates related to this issue?

[saledjenic]

@VolodLytvynenko please check out this comment https://github.com/status-im/status-mobile/issues/21292#issuecomment-2363275012 hope it will help understand the router logic.

[pavloburykh]

@VolodLytvynenko please check out this comment #21292 (comment) hope it will help understand the router logic.

Thank you @saledjenic! The route logic is clear. Although I still don't understand why do we constantly get stuck by Insufficient funds error in Status app while trying to build L1-L1 route but the same time I can successfully perform transaction on Metamask with same account, same token, same amount, same chain. Can you please check if our fee is not too high comparing to Metamask or there is some other problem.

[saledjenic]

@pavloburykh I did some checks now with your account 0xFFCB588c4f3fEC98a94986232e4c19036e224C05 that has nothing on optimism and arbitrum and has 0.005024597142129702 ETH on mainnet

This is what I got for possible options:

• transfer mainnet -> mainnet, where I am getting insufficient funds for gas * price + value: address 0xFFCB588c4f3fEC98a94986232e4c19036e224C05 have 5024597142129702 want 146683473303771940
• bridge mainnet -> optimism, where I am getting insufficient funds for gas * price + value: address 0xFFCB588c4f3fEC98a94986232e4c19036e224C05 have 5024597142129702 want 146683473303771940
• bridge mainnet -> arbitrum, where I am getting insufficient funds for gas * price + value: address 0xFFCB588c4f3fEC98a94986232e4c19036e224C05 have 5024597142129702 want 146683473303771940

I did one more try:

• transfer mainnet -> mainnet, where I am getting insufficient funds for gas * price + value: address 0xFFCB588c4f3fEC98a94986232e4c19036e224C05 have 5024597142129702 want 133526826033813769
• bridge mainnet -> optimism, where I am getting insufficient funds for gas * price + value: address 0xFFCB588c4f3fEC98a94986232e4c19036e224C05 have 5024597142129702 want 144000432737765202
• bridge mainnet -> arbitrum, where I am getting insufficient funds for gas * price + value: address 0xFFCB588c4f3fEC98a94986232e4c19036e224C05 have 5024597142129702 want 133526826033813769

packed data for mainnet to mainnet:

0x6574685f73656e645261775472616e73616374696f6e

packed data for mainnet to optimism:

0xdeace8f5000000000000000000000000000000000000000000000000000000000000000a0000000000000000000000005098dfb44c5e9a727c65072fd0d1ceb2765227c0000000000000000000000000000000000000000000000000002386f26fc10000000000000000000000000000000000000000000000000000002359bc9eb865870000000000000000000000000000000000000000000000000000000066f690f200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

packed data for mainnet to arbitrum:

0xdeace8f5000000000000000000000000000000000000000000000000000000000000a4b10000000000000000000000005098dfb44c5e9a727c65072fd0d1ceb2765227c0000000000000000000000000000000000000000000000000002386f26fc100000000000000000000000000000000000000000000000000000022ec7513b6455b0000000000000000000000000000000000000000000000000000000066f690f300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

So all looks good, but the errors and values like have X want Y is something that is coming from the network so if we don't get the value there we cannot generate the route.

What is questionable... on the first try even for different packed data I was getting the same "want X" value, which makes me wonder if all is good on our providers' side.

Also this problem is noticeable only with accounts that have very small balances, let's say below 0.2-0.3 ETH.

So again I have to say that checking the router I haven't seen any line that can cause this behavior.

[alaibe]

@pavloburykh One of the possible reason is that in order to compute the fees, we do base fee * 2 in order to get the max fee.

That changed happened in order to speed up transaction and nearly guarantee they will be included in next block. The side effect is that if your balance is close to the max you can send, there is high chance that you won't be able to actually making a transaction.

Before making that change: we were having transaction being stuck due to base fee raising

Our "only" way to prevent that is to let end user pick the max fee, this is planned on desktop and mobile i believe but not yet developed

[pavloburykh]

@alaibe @saledjenic thank you for your replies!

Can I ask you to check one more case which I still don't understand even taking into consideration that we do base fee * 2

Here is my testing account https://etherscan.io/address/0xcf2272205cc0cf96Cfbb9Dd740BD681D1E86901E

As you can see it has 0.104600126418608309 ETH ($265.91) on L1

I am trying to send 1 SNT via Status app but it is unable to build the routes. According to @saledjenic comment the reason is Insufficient funds error that is coming up when we try to build L1-L1 route.

I am attaching the logs below so you can check what is amount of fee in this case Status-debug-logs - 2024-09-20T145336.794.zip

At same time, I have tried to perform the same transaction (same account, same token, same chain) on Metamask and the fee there is just about 6$

So, my main QUESTION is: why the user with the balance of 265$ in ETH on L1 is unable to perform transaction in Status app, while fee for such transaction on Metamask is just 6$?

Are we sure that our fee is just base fee*2 (not *10 or * 20)? What is the base fee then? And why our base fee * 2 is so way higher than the fee on Metamask?

[saledjenic]

@pavloburykh I agree that's weird and not sure what to say about why it's like that while all the data we're using looks correct.

In the test I did, msg that was sent to the estimate gas function was:

From:0xcf2272205cc0cf96Cfbb9Dd740BD681D1E86901E 
To:0x744d70FDBE2Ba4CF95131626614a1763DF805B9E
Data: 0xa9059cbb000000000000000000000000c69132c3e3d6508038f16bde32473cd9d66bb7960000000000000000000000000000000000000000000000000de0b6b3a7640000

• this is the contract being used (check "To" above) https://etherscan.io/address/0x744d70FDBE2Ba4CF95131626614a1763DF805B9E#writeContract

If we break down the Data we get:

• 0xa9059cbb -> transfer function
• c69132c3e3d6508038f16bde32473cd9d66bb796 -> recipient address
• de0b6b3a7640000 -> hex value, converted to dec is 1000000000000000000, which means 1 SNT

Till now all looks correct. Then we call estimate gas for mainnet with msg from above. And we get: status-proxy-0.error: insufficient funds for gas * price + value: address 0xcf2272205cc0cf96Cfbb9Dd740BD681D1E86901E have 104600126418608309 want 156882382625043852

That's insanely expensive ~0.15 ETH, and I have no idea why, but that's something we don't have an impact to.

We have to check that with somebody else or with other providers.

[saledjenic]

@pavloburykh I've just disabled status proxy and grove as providers and checked with infura only (mainnet.infura.io) and every time I've tried I got a valid route without any issues.

@alaibe @shivekkhurana (check the comment before first)

[clauxx]

@pavloburykh I've just disabled status proxy and grove as providers and checked with infura only (mainnet.infura.io) and every time I've tried I got a valid route without any issues.

@alaibe @shivekkhurana (check the comment before first)

@saledjenic can confirm that with the infura token it seems to work as expected on mobile

[VolodLytvynenko]

can't reproduce it anymore. It seems new RPC https://github.com/status-im/status-mobile/pull/21378 fixes it