Replies: 2 comments 7 replies
-
That is weird. Can you verify the RPC response from the provider includes those (you can use My guess is they have modified their node to return everything, trying to be helpful, but in reality it just confuses things. Just a guess though. But including those all cause compatibility issues, because they can’t all be used when sending a transaction. |
Beta Was this translation helpful? Give feedback.
-
so I guess it's a bug and for now you need to manually remove values from the received tx params depending on the tx type.. I wanna make logic to replace tx if they are still not mined after the timeout is reached. I guess the tx.wait() method doesn't support it? |
Beta Was this translation helpful? Give feedback.
-
I'm listening mem pool on zksync era but it's not important
here are some examples from the provider listener
type: 2,
gasLimit: 603996n,
gasPrice: 33750000n,
maxPriorityFeePerGas: 0n,
maxFeePerGas: 33750000n,
type: 0,
gasLimit: 978604n,
gasPrice: 25000000n,
maxPriorityFeePerGas: 25000000n,
maxFeePerGas: 25000000n,
type: 2,
nonce: 707,
gasLimit: 603996n,
gasPrice: 33750000n,
maxPriorityFeePerGas: 0n,
maxFeePerGas: 33750000n,
type: 113,
gasLimit: 1404347n,
gasPrice: 25000000n,
maxPriorityFeePerGas: 0n,
maxFeePerGas: 25000000n,
etc
and the question
why type 2 txs contains defined gasPrice and type 0 contains maxFeePerGas and maxPriorityblabla
if I try sending a tx with ethers it won't allow me to define gasPrice with maxFeePerGas, it will throw an error, but at the same time the provider show txs with all the keys defined ??????? How? Why?
Thank you
Beta Was this translation helpful? Give feedback.
All reactions