Uncatchable “missing v” when sending transaction

[ricmoo]

Ethers Version

6.9.0

Search Terms

Missing v, signature

Describe the Problem

This is related to two issues:

1. An Ethers bug, related to fix: catch rejected promise #4512 where an error during sending a transaction is not catchable
2. wallets not returning a v or yParity in the response to eth_getTransactionByHash.

I’m working on a fix for 1 (which is exposing some other possible oddity) and communicating with other groups for 2.

If you are experiencing this issue, ca you please let me know which wallet you are using? It seems like MetaMask through Wallet Connect is having this issue at least. Curious if there are others.

Code Snippet

No response

Contract ABI

No response

Errors

No response

Environment

No response

Environment (Other)

No response

[ricmoo]

It seems like this isn’t a WalletConnect issue, but maybe a MetaMask issue (for part 2). Still investigating.

I currently only have data points for MetaMask through WalletConnect. There is a “hacky” solution I can imagine if necessary. Since only the v is missing, what ethers could do for EIP-1559 transaction transactions, at least, is use ecrecover to compute from using a v of 27 and 28, if one of those match to tx, use it to fill in the transaction.

The doesn’t help for EIP-155 transactions though, unless the chain ID is incorporated, which starts feeling more hacky. I’d ether fix this upstream, as it seems like a wallet bug, but seeking feedback on some other ideas too. ;)

[llopez]

I am using ethers v6.9.0 and web3modal v3.4.0 + metamask extension

[llopez]

it happens after several times of sending a transaction.

code snippet:

  const provider = new BrowserProvider(walletProvider.value, 80001)
  const signer = await provider.getSigner()
  const admin  = await signer.getAddress();
  const contract = new ethers.Contract(CONTRACT_ADDRESS, ABI, signer);

  const r = await contract.votingEscrow();
  console.log(r);

  const tokenBptAddr = '0x975Ec7795F0Fbab6aF88C9C4228a46359165F3B0';
  const name = 'test'
  const symbol = 'test1'
  const maxLockTime = 60*60*24*7; // 1 week
  const now = new Date();
  const rewardDistributorStartTime = now.getTime() + (60 * 60);

  try {
    const tx = await contract.deploy(tokenBptAddr, name, symbol, maxLockTime, rewardDistributorStartTime, admin, admin)
    console.log('tx submitted', tx)
    const receipt = await tx.wait();
    console.log('tx success', receipt);
  } catch (error) {
    console.log('error', error);
  }

it never catches the error

[glitch-txs]

I'm not able to reproduce it, I was able to do txs with both MetaMask and Rabby.

it happens after several times of sending a transaction.

So does it mean it happens randomly?

[llopez]

yes. It is a random error. I would be great at least if we can catch it.

[ricmoo]

Catching it is coming. :)

[WooMai]

Same error here (but transaction sent successfully), randomly happening about 90% of the time, using ethers.js 6.9.0 with @metamask/sdk-react-ui 0.14.1 and MetaMask Chrome Extension

async function mintToken() {
        const provider = new BrowserProvider(sdk!.getProvider());

        const contract = new Contract(tokenInfo!.address, [{
            "inputs": [
                {
                    "internalType": "uint256",
                    "name": "nonce",
                    "type": "uint256"
                }
            ],
            "name": "mint",
            "outputs": [],
            "stateMutability": "nonpayable",
            "type": "function"
        }], await provider.getSigner());
        const tx = await contract.mint(foundNonce!);  // this promise rejected
        console.log('mint tx', tx);
    }

the error message is

Uncaught (in promise) TypeError: missing v (argument="signature", value={ "accessList": null, "blockHash": null, "blockNumber": null, "from": "(sender address)", "gas": "0xf856", "gasPrice": "0x2540be400", "hash": "(removed)", "input": "(removed)", "maxFeePerGas": "0x2540be400", "maxPriorityFeePerGas": "0x2540be400", "nonce": "0x16", "r": "(removed)", "s": "(removed)", "to": "(removed)", "transactionIndex": null, "type": "0x2", "value": "0x0" }, code=INVALID_ARGUMENT, version=6.9.0)

just debugged for a couple hours for this problem until I saw this issue :´(

[llopez]

I noticed that the error occurs when I send a transaction with the same data than the previous one. maybe the code does not regenerate the signature because the data is the same.. not sure

[llopez]

yes. that is the way to reproduce the error. send the same transaction two times in a row