Polygon transactions are stuck/transaction underpriced error

[moltam89]

Ethers Version

5.6.1

Search Terms

polygon maxPriorityFeePerGas maxFeePerGas

Describe the Problem

There is a harcoded (1.5 gwei) maxPriorityFeePerGas (and maxFeePerGas) in index.ts.

This value is used in populateTransaction.

In case of Polygon, this will either result in a transaction stuck in the mempool, or in case og e.g an Alchemy endpoint, "transaction underpriced" error.

Code Snippet

signer.populateTransaction(txParams)
signer.sendTransaction(txParams)

Where txParams don't contain maxPriorityFeePerGas/maxFeePerGas, and is a type 2 transaction.
(Legacy transactions pass as they use gasPrice only)

Contract ABI

No response

Errors

processing response error (body="{\"jsonrpc\":\"2.0\",\"error\":{\"code\":-32000,\"message\":\"transaction underpriced\"},\"id\":64}", error={"code":-32000}, requestBody="{\"method\":\"eth_sendRawTransaction\",\"params\":[\"0x02f873818981c98459682f0084596898e882520894c54c244200d657650087455869f1ad168537d3b387038d7ea4c6800080c080a07cb6e05c60a2cb7ffc83349bc52ade79afaf9fdb911c64d57aed421caa1ecbcfa05f30023a4d21dd2eab6ea619c8dbb4820ce40c71841baacf8e82cbde7e87602a\"],\"id\":64,\"jsonrpc\":\"2.0\"}", requestMethod="POST",

Environment

No response

Environment (Other)

No response

[Benjythebee]

I have the exact same issue for the exact same use.
However I am using "ethers": "^5.4.6",. so the value for me is BigNumber.from("2500000000");

For reference:
https://medium.com/stakingbits/polygon-minimum-gas-fee-is-now-30-gwei-to-curb-spam-8bd4313c83a2

[robertu7]

My current workaround:

// get max fees from gas station
let maxFeePerGas = ethers.BigNumber.from(40000000000) // fallback to 40 gwei
let maxPriorityFeePerGas = ethers.BigNumber.from(40000000000) // fallback to 40 gwei
try {
    const { data } = await axios({
        method: 'get',
        url: isProd
        ? 'https://gasstation-mainnet.matic.network/v2'
        : 'https://gasstation-mumbai.matic.today/v2',
    })
    maxFeePerGas = ethers.utils.parseUnits(
        Math.ceil(data.fast.maxFee) + '',
        'gwei'
    )
    maxPriorityFeePerGas = ethers.utils.parseUnits(
        Math.ceil(data.fast.maxPriorityFee) + '',
        'gwei'
    )
} catch {
    // ignore
}

// send tx with custom gas
const tx = await contract.multicall(calldata, {
    maxFeePerGas,
    maxPriorityFeePerGas,
})

[Benjythebee]

And my current workaround:

  const feeData = await maticProvider.getFeeData()

  // Start transaction: populate the transaction
  let populatedTransaction
  try {
    populatedTransaction = await contract.populateTransaction.mint(wallet, arg, { gasPrice: feeData.gasPrice })
  } catch (e) {
    return
  }

I removed gasLimit from the options as it never worked;

[herzaso]

I have the same problem with the same version (5.6.1)

[ihorbond]

@Benjythebee seems like you could then just call provider.getGasPrice() directly

[cupOJoseph]

@robertu7 what is this Matic.network site? is that officially supported by Polygon / how reliable is it? thanks for the code!

I've also had this issue with tx getting stuck. Hoping this will fix it.

[robertu7]

@jschiarizzi It's official: https://docs.polygon.technology/docs/develop/tools/polygon-gas-station

[impguard]

For your interest @robertu7 I pulled what you did into a new wallet subclass that one day may or may not get sent back into the main lib. It's tuned for our use cases with Polygon but I can't see why it can't be generalized with the help of some interfaces:

import { TransactionRequest } from "@ethersproject/abstract-provider"
import { Provider } from "@ethersproject/abstract-provider"
import { ExternallyOwnedAccount } from "@ethersproject/abstract-signer"
import { BytesLike } from "@ethersproject/bytes"
import { Deferrable } from "@ethersproject/properties"
import { SigningKey } from "@ethersproject/signing-key"
import fetch from "cross-fetch"
import { Wallet as EthersWallet, ethers } from "ethers"

type GasData = {
  fast: {
    maxPriorityFee: number
    maxFee: number
  }
}

const DEFAULT_GAS_DATA: GasData = {
  fast: {
    maxPriorityFee: 40,
    maxFee: 40,
  },
}

class AutomaticGasWallet extends EthersWallet {
  gasStationUrl: string

  constructor(
    privateKey: BytesLike | ExternallyOwnedAccount | SigningKey,
    provider: Provider,
    gasStationUrl: string
  ) {
    super(privateKey, provider)
    this.gasStationUrl = gasStationUrl
  }

  async populateTransaction(
    transaction: Deferrable<TransactionRequest>
  ): Promise<TransactionRequest> {
    const tx = await super.populateTransaction(transaction)

    const data = await this.getGasData()
    const maxFee = ethers.utils.parseUnits(
      Math.ceil(data.fast.maxFee).toString(),
      "gwei"
    )
    const maxPriorityFee = ethers.utils.parseUnits(
      Math.ceil(data.fast.maxPriorityFee).toString(),
      "gwei"
    )

    tx.maxFeePerGas = maxFee
    tx.maxPriorityFeePerGas = maxPriorityFee

    return tx
  }

  async getGasData(): Promise<GasData> {
    if (!this.gasStationUrl) {
      return DEFAULT_GAS_DATA
    }

    try {
      const response = await fetch(this.gasStationUrl)
      const data = (await response.json()) as GasData
      return data
    } catch (e) {
      logger.error(
        `Could not fetch gas data from ${this.gasStationUrl}: ${e.toString()}`
      )
      return DEFAULT_GAS_DATA
    }
  }
}

export default AutomaticGasWallet

[tomonari-t]

Currently, we should do like @robertu7 's way.
provider. getFeeData() return only maxPriorityFeePerGas: 1.5gwei

https://github.com/ethers-io/ethers.js/blob/master/packages/abstract-provider/src.ts/index.ts#L250

[Benjythebee]

@Benjythebee seems like you could then just call provider.getGasPrice() directly

My solution above #2828 (comment)
seem to be unreliable now. The transaction fails even before asking the user for a transaction most of the time.
With error "err: max fee per gas less than block base fee..."

metamask 10.14.1
ethers ^5.4.6

[vicwtang]

I just stumbled across this after pulling my hair out this past week with transaction errors UNDERPRICED, REPLACEMENT_UNDERPRICED and "tx fee exceeds the configured cap" on maticvigil, polygon-rpc and alchemy.
Various multiples of the getFeeData results were used, all with low success rates. I will try @robertu7's workaround later tonight to see if there any improvement - i sure hope so. A clear and concise example in the ethers docs would be TRULY helpful for all of us trying to use Polygon. Note that Mumbai gave no indication that this would be an issue in production.

[GolfredoPerezFernandez]

same issue here trasactions are pending for ever on mumbai polygon

[clemsos]

same issue here on polygon mainnet

[vicwtang]

Interesting. I never had any issues with Mumbai. It was only after going live that the majority of transactions were rejected. And those that went thru the 2nd week of May had wildly fluctuating prices such that same tx went from cents to up to $3. So currently, I am very jaded with Polygon. Anyways, didn't get to trying the work-around. Doing it as shortly, will advise on my experience...

[vicwtang]

Thanks for the post @clemsos. I'm curious - is the data from the polygon gas station significantly different from the results from the getFeedata call?

[vicwtang]

Here's my results trying @clemsos code:
results from getFeeData:
{ maxFeePerGas: '1500000082' } { maxPriorityFeePerGas: '1500000000' }
results from @clemsos:
const resp = await fetch('https://gasstation-mainnet.matic.network/v2')
const data = await resp.json()

				maxFeePerGas = ethers.utils.parseUnits(
					`${Math.ceil(data.fast.maxFee)}`,
					'gwei'
				)
				maxPriorityFeePerGas = ethers.utils.parseUnits(
					`${Math.ceil(data.fast.maxPriorityFee)}`,
					'gwei'
				)

gasstation { maxFeePerGas: '48000000000' } { maxPriorityFeePerGas: '48000000000' }
NOTE: gasstation value is 32x greater than getFeedata value, yet when I was submitting 3x getFeeData.maxFeePerGas values last week, i hit over cap errors

**************** calling secureToken ****************
batchMint failed secureData Error: replacement fee too low [ See: https://links.ethers.org/v5-errors-REPLACEMENT_UNDERPRICED ]

reviewing @impguard / @robertu7 next...
And that is pretty much the same code... hmm
my method call with the gas values:
await contract.connect(signer).secureToken(
bnTokenId, bnCollectionId, bnChain, meta.metaCid,
meta.properties.docroot, '', meta.exchange, owner,
{
maxFeePerGas,
maxPriorityFeePerGas
}
)

so still dead in water...

[vicwtang]

and with @Benjythebee 's use of feeData.gasPrice:
gasPrice 37172324995
await contract.connect(signer).secureToken(
bnTokenId, bnCollectionId, bnChain, meta.metaCid,
meta.properties.docroot, '', meta.exchange, owner,
{ gasPrice: feeData.gasPrice })

**************** calling secureToken ****************
batchMint failed secureData Error: replacement fee too low [ See: https://links.ethers.org/v5-errors-REPLACEMENT_UNDERPRICED ] (error={"reason":"processing response error","code":"SERVER_ERROR","body":"{"jsonrpc":"2.0","id":56,"error":{"code":-32000,"message":"replacement transaction underpriced"}}","error":{"code":-32000},"requestBody":"{"method":"eth_sendRawTransaction"

requestMethod: 'POST',
url: 'https://rpc-mainnet.maticvigil.com/v1/xxxxx'

},
method: 'sendTransaction',
transaction: {
type: 2,
chainId: 137,
nonce: 3017,
maxPriorityFeePerGas: BigNumber { _hex: '0x08a7a4aa83', _isBigNumber: true },
maxFeePerGas: BigNumber { _hex: '0x08a7a4aa83', _isBigNumber: true },
gasPrice: null,
gasLimit: BigNumber { _hex: '0x099b26', _isBigNumber: true },
to: '0xxxxxx',
value: BigNumber { _hex: '0x00', _isBigNumber: true },

INTERESTING - gasPrice shown as NULL in the actual transaction despite being submitted in call...

[vicwtang]

Am I doing something wrong? I imagine that these workarounds are working for those who posted these solutions.
Is it the rpc provider? What rpc provider is used for the gasstation solution versus the gasprice one?
I should note: I am making these calls from the BACKEND. I guess I'll check in the DAPP if this helps on that front...

Dang it. Just realized its REPLACEMENT_UNDERPRICED, meaning a previous TX has stuck my new TX. But doesn't the NEW tx with the CORRECT fee override the stuck on and push it through? Trying to figure out how to cancel these pending now. Maybe the code above will work once that's done. I have to say - this has been an awful experience.

[vicwtang]

Update. SO the nonce was pending with a previous accepted tx. So, the maxFeePerGas value from the gasstation is getting accepted. However, if I wait for the transaction to confirm, it never returns. If i submit another TX, it gets a REPLACEMENT_UNDERPRICED error. I then have to go to metamask, and send a 0Matic transaction with the SAME NONCE at the fast price to clear the pending tx. GREAT. YAY.

So as a part of all this pricing business, I have TX with an accepted price and a hash, that doesnt confirm within any reasonable timeframe, hence still blocking all other TX. Looking up the TX in polygonscan - i get this:
Status:
Pending This txn hash was found in our secondary node and should be picked up by our indexer in a short while.
for a tx made 5 minutes ago.

trying a different RPC to see if there's any improvement.

I'm updating this info so maybe it helps others? But I sure could use some feedback from the more experienced Polygoner's out there who have figured this out. If there is such a state...

Meanwhile, more 0 matic transfers to reset Tx.

Update: after maybe 15min? explorer shows this: Sorry, We are unable to locate this TxnHash
Sooo... the accepted fee wasn't good enough???

Update #2: so it seems now we're cooking with gas :) So a number of issues:

1. getFeeData is apparently WAY UNDERPRICED compared to the gasstation values - USE the gasstation values for maxFeePerGas and maxPriorityFeePerGas (the tip is the same as the limit??? - whatever)
2. I changed my RPC provider from maticvigil to polygon-rpc. It apparently was the difference between the await for confirmation timing out and the tx should as pending on a secondary node TO ACTUALLY being confirmed within 30s.
3. If you see a REPLACEMENT_UNDERPRICED - that means you ALREADY have a pending TX and should ensure this is cancelled or processed before you create a NEW ONE. Your current NODE# is stuck and you will need to unstick it. Doing a zero matic transfer on Metamask for that node # at Aggressive gas seems to take care of that within 30s. And what do you know - Metamask is using polygon-rpc.

So... my batcher is finally chugging await and logging successful tx now. YAY but what a week from HELL. I cannot say I would recommend Polygon, or the support that is available to help. Thanks to the community here for the gas pricing info

NEXT STOP: anyone have any experience setting default gas for the provider, versus per tx. when using an sdk - direct access to setting the gas for a tx is sometimes not available - ie Rarible API or Opensea perhaps. I'm told Web3 has Web3Ethereum that can be supplied with gas option - does this work for maxFeeForGas? Is there an ETHERS equivalent?

[vicwtang]

Just completed minting 1000 nfts yesterday on polygon RELIABLY - finally.
Here's my code to get around this very frustrating gas pricing issue on Polygon/Mumbai:

	const gasEstimated = await contract.estimateGas.yourMethod(...methodParams)

	const gas = await calcGas('fast', chain) // this is @robertu7 's code - thanks!

	let response = await (
		await contract.connect(signer).yourMethod(...methodParams,
			{ gasLimit: mulDiv(gasEstimated, 110, 100), 
			maxFeePerGas: gas.maxFeePerGas, 
			maxPriorityFeePerGas: gas.maxPriorityFeePerGas }
		)
	).wait()

it irks me that the maxPriorityFeePerGas is so high. I know I saw random transactions I had with default gas paying 1.5gwei but I havent been able to re-achieve this reliably.

Note that I had to include a gasLimit at a 10% premium for improved reliability. the ethers getFeeData did NOT work. it was always underpriced.

But the code is demonstrably reliable in sending the tx and getting it included in the block within a few seconds each time. I added a check to retry the tx later if the maxFeePerGas exceeds 50gwei in production.

Hope that helps someone.

[y0unghe]

Just completed minting 1000 nfts yesterday on polygon RELIABLY - finally. Here's my code to get around this very frustrating gas pricing issue on Polygon/Mumbai:

	const gasEstimated = await contract.estimateGas.yourMethod(...methodParams)

	const gas = await calcGas('fast', chain) // this is @robertu7 's code - thanks!

	let response = await (
		await contract.connect(signer).yourMethod(...methodParams,
			{ gasLimit: mulDiv(gasEstimated, 110, 100), 
			maxFeePerGas: gas.maxFeePerGas, 
			maxPriorityFeePerGas: gas.maxPriorityFeePerGas }
		)
	).wait()

it irks me that the maxPriorityFeePerGas is so high. I know I saw random transactions I had with default gas paying 1.5gwei but I havent been able to re-achieve this reliably.

Note that I had to include a gasLimit at a 10% premium for improved reliability. the ethers getFeeData did NOT work. it was always underpriced.

But the code is demonstrably reliable in sending the tx and getting it included in the block within a few seconds each time. I added a check to retry the tx later if the maxFeePerGas exceeds 50gwei in production.

Hope that helps someone.

What's the mulDiv function do? Can you kindly put out the complete code? I am trying to make it work on polygon too. But the transaction is always stuck at pending.

[vicwtang]

adds a 10% premium to the estimated fee

…

On Wed, Jul 27, 2022 at 10:32 PM Yong He ***@***.***> wrote: Just completed minting 1000 nfts yesterday on polygon RELIABLY - finally. Here's my code to get around this very frustrating gas pricing issue on Polygon/Mumbai: const gasEstimated = await contract.estimateGas.yourMethod(...methodParams) const gas = await calcGas('fast', chain) // this is @robertu7 's code - thanks! let response = await ( await contract.connect(signer).yourMethod(...methodParams, { gasLimit: mulDiv(gasEstimated, 110, 100), maxFeePerGas: gas.maxFeePerGas, maxPriorityFeePerGas: gas.maxPriorityFeePerGas } ) ).wait() it irks me that the maxPriorityFeePerGas is so high. I know I saw random transactions I had with default gas paying 1.5gwei but I havent been able to re-achieve this reliably. Note that I had to include a gasLimit at a 10% premium for improved reliability. the ethers getFeeData did NOT work. it was always underpriced. But the code is demonstrably reliable in sending the tx and getting it included in the block within a few seconds each time. I added a check to retry the tx later if the maxFeePerGas exceeds 50gwei in production. Hope that helps someone. What's the mulDiv function do? — Reply to this email directly, view it on GitHub <#2828 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AQKOKAZ4PVRIJAFRDVVOSDTVWILNPANCNFSM5REEG7RQ> . You are receiving this because you commented.Message ID: <ethers-io/ethers .***@***.***>

[SethTurin]

What's the mulDiv function do? Can you kindly put out the complete code? I am trying to make it work on polygon too. But the transaction is always stuck at pending.

Yeah I was reading this thread like "oh yay a solution" and then "wtf is mulDiv?"

After some significant googling, I found that it's an old timey method that just means (a * b) / c. He's using it to calculate 10% higher than the given number.

But after getting it to work, I found that I didn't need to go 10% higher. I included the 10% higher code in a comment, in case anyone needs it.

I adapted and cleaned up the code, and here is what I ended up with.

function parse(data) {
    return ethers.utils.parseUnits(Math.ceil(data) + '', 'gwei');
}

async function calcGas(gasEstimated) {
    let gas = {
        gasLimit: gasEstimated, //.mul(110).div(100)
        maxFeePerGas: ethers.BigNumber.from(40000000000),
        maxPriorityFeePerGas: ethers.BigNumber.from(40000000000)
    };
    try {
        const {data} = await axios({
            method: 'get',
            url: 'https://gasstation-mainnet.matic.network/v2'
        });
        gas.maxFeePerGas = parse(data.fast.maxFee);
        gas.maxPriorityFeePerGas = parse(data.fast.maxPriorityFee);
    } catch (error) {

    }
    return gas;
};

const gasEstimated = await contract.estimateGas.yourMethod();
const gas = await calcGas(gasEstimated);
const tx = await contract.yourMethod(gas);
await tx.wait();

Provided I didn't make any mistakes in converting to ES, this should be a full working snippet. If not, let me know.

Honestly I don't know how I would have ever solved this if not for stumbling upon this particular thread. So thanks for your efforts, and your help.

[hickscorp]

@ricmoo I'm not entirely sure. But this seems to be a hint to a possibility? https://github.com/nevermined-io/sdk-js/pull/528/files#diff-0aacc7b648d468e263987a52e20ca68ab32aeedf88d21a4036875bd87a9c54a8R146

[isvidler]

For anyone still struggling with this, we encountered this issue here at Den.

Our solution

Set maxPriorityFeePerGas to (await provider.getFeeData()).maxFeePerGas.toString(). Some others in this thread also mentioned that this worked for them.

Why this works

See @ricmoo's explanation earlier in this thread: #2828 (comment)

Quoting here for convenience:

So, basically Polygon wanted to keep “backwards compatibility” with Geth by using EIP-1559 but without actually using EIP-1559.

The purpose of EIP-1559 is to stabilize fee pricing and make it highly predictable (for example; I’ve not had a single tx take more than 2 blocks on Ethereum since it was added, and almost all are in the next block). But that involves setting a reasonable floating baseFee and a fixed priorityFee.

Polygon wants their prices to remain “looking low”, so they effective hard coded the baseFee, and a floating priorityFee (notice this is backwards).

This results in mimicking the old pre-EIP-1559 behaviour, creating a bidding war for priorityFee during congestion (which per-EIP-1559 txs did, creating a bidding war for gasPrice during congestion). The only viable solution Ethereum had that worked back then was a gas station; a separate service which would track the mempool and store stats on when a tx enters the mempool and when it was mined, map this duration against its gasPrice, and generate histograms that map gasPrice to wait times. These histograms over short periods of time could then be used to pick a gas price that would get a tx included within a reasonable time. During congestion ramp up, the prices would possibly lag and would result in slower transactions and during ramp down would cause overpayment for a transaction. It’s a terrible solution, it the best possible solution at the same time. :)

[lancelot-c]

I've updated @robertu7's answer to make it work with ethers 6.6.3 and the new Polygon gas station URLs:

const gasStationURL = (network === 'mainnet') ? "https://gasstation.polygon.technology/v2" : "https://gasstation-testnet.polygon.technology/v2";
let maxFeePerGas = BigInt("40000000000") // fallback to 40 gwei
let maxPriorityFeePerGas = BigInt("40000000000") // fallback to 40 gwei


// Call this function every time before a contract call
async function setOptimalGas() {
    try {
        const { data } = await axios({
            method: 'get',
            url: gasStationURL
        })
        maxFeePerGas = ethers.parseUnits(
            Math.ceil(data.fast.maxFee) + '',
            'gwei'
        )
        maxPriorityFeePerGas = ethers.parseUnits(
            Math.ceil(data.fast.maxPriorityFee) + '',
            'gwei'
        )
    } catch {
        // ignore
    }
}

await setOptimalGas();
await contract.myMethod(myParams, {
        maxFeePerGas,
        maxPriorityFeePerGas,
});

[ricmoo]

Ethers now uses the Polygon gas stations (via a NetworkPlugin) in v6.7.0 for gathering fee data, which has been vetted by the Polygon team.

Please let me know if you have any more issues with transactions not going through.

Thanks! :)

[morimaxw]

@lancelot-c This worked perfectly for me under ethers 6.7.0, thanks!

The only reliable solution I could find that consistently gets transactions out in a few seconds.