Skip to content
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

Transaction Request "type" defaults to legacy transactions when null, does not recognize EIP-1559 parameters via signTransaction #3587

Open
Cybourgeoisie opened this issue Dec 14, 2022 · 2 comments
Assignees
Labels
investigate Under investigation and may be a bug.

Comments

@Cybourgeoisie
Copy link

Ethers Version

5.7.2

Search Terms

wallet, signTransaction, serialize, eip1559, eip2718, maxPriorityFeePerGas, gasPrice, maxFeePerGas

Describe the Problem

Per the documentation for a Transaction Request, which states "The EIP-2718 type of this transaction envelope, or null for to use the network default.".

A few issues arise here:

  1. The documentation does not mention that the type needs to be set to 1 for EIP-2718, and does not mention that type needs to be set to 2 for EIP-1559 gas parameters.
  2. The code does not respect "null to use the network default", it actually defaults to legacy transactions, which does not match what the documentation states. (See
    if (transaction.type == null || transaction.type === 0) {
    )
  3. Using signTransaction without setting a type, it will automatically default to the legacy transactions without explicitly setting type, which is not clarified in the documentation and is not explained in the error message.

A few fixes are recommended here:

  1. Update the documentation or the code so that they match the intended function when type is null, maybe move type to the top of the transaction request documentation if it's critical to use EIP-1559 transactions
  2. Suggest automatically recognizing when EIP-1559 transactions are being signed, by the existence of the maxPriorityFeePerGas or maxFeePerGas parameters, since that would save a lot of lost developer time debugging this particular issue

Code Snippet

No response

Contract ABI

No response

Errors

No response

Environment

Other (please specify)

Environment (Other)

N/A

@Cybourgeoisie Cybourgeoisie added the investigate Under investigation and may be a bug. label Dec 14, 2022
@tab00
Copy link

tab00 commented Aug 16, 2023

@ricmoo said "The ethers provider will automatically detect if a network supports EIP-1559 and use it if it does" in the thread #1610 (comment) but it's not working.

Using this code resulted in type 0 (legacy) transactions:

  await contract.interchainTransfer(
    "binance",
    "0x...",
    ethers.parseUnits("1", "ether"),
    "0x",
    {
      value: ethers.parseUnits("0.1", "ether"),
    }
  )

Only after I change it to

  const { gasPrice, ...feeData } = await ethers.provider.getFeeData()

  await contract.interchainTransfer(
    "binance",
    "0x...",
    ethers.parseUnits("1", "ether"),
    "0x",
    {
      value: ethers.parseUnits("0.1", "ether"),
      ...feeData
    }
  )

the transaction is type 2.

So the automatic EIP-1559 detection needs to be fixed.

@tab00
Copy link

tab00 commented Aug 24, 2023

Default transaction type is still 0 (Legacy). I'm using Ethers 6.7.1.

So I've been needing to getFeeData:

  const { gasPrice, ...feeData } = await ethers.provider.getFeeData()

... and add it to every transaction request:

  txRec = await contract.mint(address, ethers.parseUnits("10", "ether"), { ...feeData })

instead of just:

  txRec = await contract.mint(address, ethers.parseUnits("10", "ether"))

@ricmoo please fix this. Thank you.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
investigate Under investigation and may be a bug.
Projects
None yet
Development

No branches or pull requests

3 participants