Deploy to Optimism via script fails after incorrect gas estimation

[spengrah]

Component

Forge

Have you ensured that all of these are up to date?

• Foundry
• Foundryup

What version of Foundry are you on?

forge 0.2.0 (8adf428 2023-05-08T00:04:45.691256000Z)

What command(s) is the bug in?

forge script script/MyScript.s.sol -f optimism --broadcast --verify

Operating System

macOS (Apple Silicon)

Describe the bug

I have a script that deploys an implementation contract and a clone factory. I'm currently attempting to run the script to deploy to Optimism. Simulation run works just fine, but when broadcasting I end up with a code -32000 [...] insufficient funds for gas * price + value error.

I have confirmed that all my wallet and rpc configs are correct (I'm able to broadcast a simple eth transfer on optimism, for example).

As you can see in the screenshot below, the deployer balance exceeds the estimated amount required value, but the broadcast is still failing. It appears that the cost estimation is way too low, likely because it excludes the L1 gas component that is part of an L2 transaction.

[backseats]

I am experiencing something similar, deploying to mainnet. Wallet has triple the ETH in it relative to the estimate

forge 0.2.0 (43974b0 2023-05-09T00:17:51.920839000Z)

Command: forge script script/MultiMerkleMinterV1.s.sol:MultiMerkleMinterV1Script --rpc-url $MAINNET_RPC_URL --chain-id 1 --private-key $MAINNET_PRIVATE_KEY --broadcast --verify -vvvv

macOS (Apple Silicon)

$ forge script script/MultiMerkleMinterV1.s.sol:MultiMerkleMinterV1Script --rpc-url $MAINNET_RPC_URL --chain-id 1 --private-key $MAINNET_PRIVATE_KEY --broadcast --verify -vvvv
[⠰] Compiling...
No files changed, compilation skipped
Traces:
  [2296694] MultiMerkleMinterV1Script::run() 
    ├─ [0] VM::envUint(PRIVATE_KEY) [staticcall]
    │   └─ ← <env var value>
    ├─ [0] VM::startBroadcast(<pk>) 
    │   └─ ← ()
    ├─ [2237130] → new MultiMerkleMinterV1@0x3B718a2272216343c4E63809276317E8295e453B
    │   ├─ [8087] GenArt721CoreV3_Engine::getPrimaryRevenueSplits(0, 0) 
    │   │   └─ ← 0, 0xE7bEB4Af9Da9b567778278F863Ed475212589526, 0, 0xFdc45dae01d1F9EF394b33c227BA9489795d148B, 0, 0x0000000000000000000000000000000000000000, 0, 0x0000000000000000000000000000000000000000
    │   ├─ [326] MinterFilterV1::genArt721CoreAddress() 
    │   │   └─ ← GenArt721CoreV3_Engine: [0x6DdefE5DB20D79EC718A8960177bEB388f7EbB8d]
    │   └─ ← 10987 bytes of code
    ├─ [0] VM::stopBroadcast() 
    │   └─ ← ()
    └─ ← ()


Script ran successfully.

## Setting up (1) EVMs.
==========================
Simulated On-chain Traces:

  [2471622] → new MultiMerkleMinterV1@0x3B718a2272216343c4E63809276317E8295e453B
    ├─ [8087] GenArt721CoreV3_Engine::getPrimaryRevenueSplits(0, 0) 
    │   └─ ← 0, 0xE7bEB4Af9Da9b567778278F863Ed475212589526, 0, 0xFdc45dae01d1F9EF394b33c227BA9489795d148B, 0, 0x0000000000000000000000000000000000000000, 0, 0x0000000000000000000000000000000000000000
    ├─ [326] MinterFilterV1::genArt721CoreAddress() 
    │   └─ ← GenArt721CoreV3_Engine: [0x6DdefE5DB20D79EC718A8960177bEB388f7EbB8d]
    └─ ← 10987 bytes of code


==========================

Chain 1

Estimated gas price: 139.159975345 gwei

Estimated total gas used for script: 3213108

Estimated amount required: 0.44713603006082226 ETH

==========================

###
Finding wallets for all the necessary addresses...
##
Sending transactions [0 - 0].

Transactions saved to: /Users/backseats/tender/broadcast/MultiMerkleMinterV1.s.sol/1/run-latest.json

Error: 
(code: -32000, message: insufficient funds for gas * price + value, data: None)

[simplyoptimistic]

it excludes the L1 gas component that is part of an L2 transaction.

I also had this issue. Given that the majority of the gas consumed by a L2 transaction on Optimism (at this stage) is in the L1 gas component, the gas estimation functionality is fairly useless on Optimism.

I have also noticed that it overestimates the gas price unless you use --legacy (perhaps related to this issue #4547).

Optimism has described here how the L1 fee could be estimated, by reading from the gas oracle contract, so perhaps that could be a way foundry could address this issue.

[PaulRBerg]

Just bumped into this issue as well, but when trying to deploy to Arbitrum. My account is funded with 0.04 ETH, but the gas estimation reports (incorrectly) that I need ~0.0821 ETH instead:

## Setting up (1) EVMs.

==========================

Chain 42161

Estimated gas price: 3.2 gwei

Estimated total gas used for script: 25681451

Estimated amount required: 0.0821806432 ETH

This estimation is wrong. I deployed bigger contracts yesterday and they cost much less than that.

[PaulRBerg]

I ended up having to deploy via Remix + MetaMask because of this bug 😬

[ctate]

Just bumped into this issue as well, but when trying to deploy to Arbitrum. My account is funded with 0.04 ETH, but the gas estimation reports (incorrectly) that I need ~0.0821 ETH instead:

## Setting up (1) EVMs.

==========================

Chain 42161

Estimated gas price: 3.2 gwei

Estimated total gas used for script: 25681451

Estimated amount required: 0.0821806432 ETH

This estimation is wrong. I deployed bigger contracts yesterday and they cost much less than that.

I’m having the same issue mentioned here via Arbitrum

[PaulRBerg]

@ctate see a neat workaround on Twitter: Is it possible to send CREATE transactions via MetaMask (without using Remix)?.

[rachel-bousfield]

@PaulRBerg your issue is likely that the L1 basefee increased since your previous contract deployments.

On Arbitrum gas estimation fluctuates with the L1 basefee, since you pay for the cost of posting calldata to L1 with L2 gas. Contract deployments use a lot of calldata so estimates are especially sensitive to changes.

Your best bet is to estimate right before deployment.

[PaulRBerg]

your issue is likely that the L1 basefee increased since your previous contract deployments.

I'm quite sure that that was not the issue. I ended up deploying my contract with MetaMask using the trick described here and the gas paid was way, way, way less than what was estimated by Forge.

Your best bet is to estimate right before deployment.

That's what forge script does.

[klkvr]

FIxed by #7106