I have enough ETH in the wallet but migration to mainnet fails for illogical reason - not enough funds.
Truffle has strange logic of cost calculation - it deploys Initial migration and my contract (Nft) and then complains that the remaining balance left in the wallet is lower than total upfront cost. Thank you for helping me to understand this.
Illogical Error: 0.1381 ETH is lower than upfront cost 0.2755 ETH
truffle-config.js
const HDWalletProvider = require('truffle-hdwallet-provider')
...
live: {
provider: () => new HDWalletProvider(MNEMONIC_LIVE, LIVE_URL),
network_id: 1,
gas: 3450000,
gasPrice: web3.utils.toWei('79', 'gwei'),
confirmations: 1,
timeoutBlocks: 200,
skipDryRun: false,
networkCheckTimeout:1000000
},
Migration dry-run log
1_initial_migration.js
======================
Deploying 'Migrations'
----------------------
> block number: 12232671
> block timestamp: 1618329800
> account: 0xbb467DA83d9DB2F10Bb5E6d5C4b48121a62FB80E
> balance: 0.379524194
> gas used: 235234 (0x396e2)
> gas price: 79 gwei
> value sent: 0 ETH
> total cost: 0.018583486 ETH
-------------------------------------
> Total cost: 0.018583486 ETH
3_nft_deploy.js
================
Deploying 'Nft'
----------------
> block number: 12232673
> block timestamp: 1618330490
> account: 0xbb467DA83d9DB2F10Bb5E6d5C4b48121a62FB80E
> balance: 0.138160076
> gas used: 3027724 (0x2e330c)
> gas price: 79 gwei
> value sent: 0 ETH
> total cost: 0.239190196 ETH
Error: sender doesn't have enough funds to send tx. The upfront cost is: 272550000000000000 and the sender's account only has: 138160076000000000
at Migration._deploy (/home/roman/.npm-global/lib/node_modules/truffle/build/webpack:/packages/migrate/Migration.js:103:1)
at process._tickCallback (internal/process/next_tick.js:68:7)
Truffle v5.2.6 (core: 5.2.6)
Node v10.19.0
I had same problem and I was able to contact with truffle support team, they know the issue, here's the answer:
So in doing #4296, @fainashalts discovered that the naïve strategy of doing an
eth_estimateGas
is insufficient for transactions that revert: in such situations,eth_estimateGas
does not provide a quantity in response (it instead errors). This means that Truffle won't be able to proceed with sending the transaction, since it won't have all the information it needs to be able to do so. We need Truffle to be able to send transactions, even if it knows those transactions will revert, because users must be able to inspect such reverted transactions (e.g. via stacktrace inspection, etc.). As a consequence of this, we'll need some additional logic to produce a gas limit value when the estimate cannot be determined viaeth_estimateGas
.Best solution for this remains undetermined, but we've uncovered a few options (all specifically relating to the case where
eth_estimateGas
fails due to revert): a. Use the block limit (or some value based on the block limit, e.g.blockLimit / 2
) as the default transaction gas limit
b. Do a binary search to find the boundary for gas limit between the transaction's failing for "out of gas" and the transaction's failing for "revert", and use that value when sending the transaction to the network.
c. Petition to modify the JSON-RPC and all client implementations so as to ensureeth_estimateGas
reports a sensible gas limit value even for transactions that revertThese all seem not-ideal; currently looking for an option (d)
Anyways, you can avoid running dryrun to deploy migration or do what I did which was to adjust gas and gasPrice in order to reduce tx cost and add more funds to my wallet.
If you handle correctly gas and gasPrice, you should not be worried to have more Ethers in your wallet than you really need.
I know, It's not the best solution but works.