Setting Custom gasPrice
#53
-
Hi there, I've recently been using xdeployer on Polygon. While for testnet (Mumbai) the auto gasPrice calculations seem to work fine, that's not the case on Polygon mainnet unfortunately. After multiple attempts of using auto calculated gasPrices failing I resorted to calling the Create2Deployer contract myself, with custom gasPrices, rather than using the plugin. I couldn't find an easy way to set gasPrices whilst using the plugin, am I missing something obvious? It sort of brings up another question, which I saw mentioned in another discussion - given this is a HardHat plugin, is there any reason not to have a more direct tie in to the HardHat config? Especially the network info which would include gas prices. Are there other networks which aren't supported as well in the HardHat config? Thanks for creating the plugin!
|
Beta Was this translation helpful? Give feedback.
Replies: 4 comments 7 replies
-
@JasperTimm thanks for opening this discussion. I've been actually aware of this problem for a while. The reason behind that issue is gas under-pricing by the Polygon's RPC providers (you would need to multiply by at least 2x the Polygon has some serious issues with EIP-1559 it seems: Some points:
So the temporary solution I propose to you is either wait for Polygon to fix their RPC pricing issue or fork the code and patch it in the way you need it (UPDATE: see below how to patch the code). My goal is really to leave all the management to ethers, as recommended by its author: Concerning your second point: I do see your points here, but my goal is to have a plugin that contains all the necessary information within its own config and is not affected by potential breaking changes from Hardhat's config structure. Or in other words, I think the design of the current plugin is more future-proof than making it dependent on core functionalities that can change over time. I want to assure that this plugin also works for hardhat versions 3+ without any major refactoring. The current structure also allows using specific RPCs for the |
Beta Was this translation helpful? Give feedback.
-
If you fork it, you could resolve the issue in the following manner (https://github.com/pcaversaccio/xdeployer/blob/main/src/index.ts#L144) - disclaimer: I'm hacking this together on my mobile lol: createReceipt[i] = await create2Deployer[i].deploy(
AMOUNT,
hre.ethers.utils.id(hre.config.xdeploy.salt),
initcode.data,
{
gasLimit: hre.config.xdeploy.gasLimit,
maxPriorityFeePerGas: ethers.utils.parseUnits('YOUR_VALUE', 'gwei'),
maxFeePerGas: ethers.utils.parseUnits('YOUR_VALUE', 'gwei'),
}
); |
Beta Was this translation helpful? Give feedback.
-
I would like to highlight that Polygon has an enforced minimum 30 gwei priority fee and |
Beta Was this translation helpful? Give feedback.
-
Apologies this is all very confusing even though I myself had to put in a workaround specifically for Polygon Mainnet's gas disaster. I tried modifying the source and even the dist files directly but just couldn't get it to work. It would've been great if someone had a PR as an example if everyone's saying it's so easy or "just do that". Polygon Mainnet's gas estimate is a train wreck, it's not a fun area, I get it, it's not your fault or my fault but makes consumers even more irritated makes things very broken for a major chain. Anyways thx for a great plugin, looks like it was fixed in ethers 6.7: ethers-io/ethers.js#2828 (comment) |
Beta Was this translation helpful? Give feedback.
@JasperTimm thanks for opening this discussion.
I've been actually aware of this problem for a while. The reason behind that issue is gas under-pricing by the Polygon's RPC providers (you would need to multiply by at least 2x the
maxFeePerGas
andmaxPriorityFeePerGas
to include a deployment successfully). I've tested all other chains and it's a Polygon-specific problem.Polygon has some serious issues with EIP-1559 it seems:
Some points:
xdeployer
code since this is a Polygon-specific problem and on all other 39 EVM chains it apparently works… - even L2 solutions like Optimism & Arbitrum have no issues so far (see e.g. here);