-
Notifications
You must be signed in to change notification settings - Fork 1.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow setting gas limits for individual transactions inside scripts using solidities {gas: x}
syntax
#2627
Comments
+1 to the issue, but instead of introducing new syntax, perhaps vm can respect the ether balance of an address? For e.g., following should throw meaningful "not enough gas" contract SomeContract {
function someFunction() external {
}
}
contract SomeScript is Script {
function run() public {
SomeContract someContract = new SomeContract();
vm.deal(address(0), 0);
vm.prank(address(0));
someContract.someFunction();
}
} |
These are different: your example gives the account a balance, @ckoopmann's example uses native Solidity syntax to specify the gas limit of a transaction |
I had a problem today with the lack of this feature. |
+1 would love to have this! |
This would be nice when using |
Hey guys I am trying to deploy contract on sei and my max fee per gas is 30000.. is it some what related to this error .. |
I've ran into issues deploying to SEI. Make sure your address is properly linked (meaning you got a native address). If you don't, an easy way is to send yourself some SEI from the same address with an EVM wallet, this will create a SEI address for you. Also, on Testnet I ran into insufficient fund errors, I found that if I did a transaction before deploying (i.e. send yourself SEI), I was able to get rid of the insufficient fund error. It doesn't seem to happen on mainnet, fees are so little I'd suggest you deploy right there. |
Component
Forge
Describe the feature you would like
Summary
Allow the user to hardcode gas limits on individual transactions inside a forge-script using standard solidity syntax.
This hardcoded value should override / have preference over existing gas estimation logic.
Example
In the below example the first call to
someFunction
should be executed with exactly the specified gas limit both in simulation as well as on broadcast.The second call to this function (as well as the contract deployment) should have its gas limit estimated the same way as usual.
Additional context
No response
The text was updated successfully, but these errors were encountered: