"deployment failed with error: only replay-protected (EIP-155) transactions allowed over RPC"


Up to last week I was deploying a contract using:

  • openzeppelin
  • truffle
  • infura

with follow command:

“npx openzeppelin create MyContract …”

and it was working fine.

As of today when i try to deploy i get the following error:

“MyContract deployment failed with error: only replay-protected (EIP-155) transactions allowed over RPC”

Is there some new configuration / setup that needs to be done in order to go around that error?

I tried googling but couldn’t find anything about this error.

I had the same problem, and solved it by adding chainId as an argument to send():

let pubKey = Wallet.fromPrivateKey(Buffer.from("priv_key_here", "hex")).getAddressString();

let contract_instance = new web3_instance.eth.Contract(

let result = await contract_instance.methods
  .my_function(param1, param2)
    from: pubKey,
    gasPrice: "150000000000",
    gas: "3000000",
    chainId: 3, // Ethereum-Ropsten

See https://chainlist.org/ for a list of chain IDs.

(Aside: now that tx is replay-protected, the next error I get is insufficient funds for gas * price + value, even though I definitely have enough ETH for the tx.)

Thanks for the suggestion, that’s good to know!

The problem here is that I’m using a deploy script from openzeppelin which in turns seems to be using truffle which is using HDWalletProvider which uses infura as an RPC provider.

Because of that I’m unsure if it’s possible to just add that chainId as a parameter in one of those config files or if i would actually have to fork some of this code to solve the issue :frowning:

The issue seems to due to the new Geth update , i believe the Infura nodes got updated today with the new update (https://blog.ethereum.org/2021/03/03/geth-v1-10-0/) .

This has been causing issue with truffle migrates and oz deployements as well. I believe either infura needs to run nodes with " --rpc.allow-unprotected-txs" or would be better if there would be a way for truffle or oz to send tx with chain id’s.

yes that would be great as currently my deployment is totally stuck because it relies on infura and I’m getting that error with all my deploy and update scripts : (

any idea if anyone from infura team is looking at it?

Hey @t3ch, and welcome to the Infura community!

Looks like this is an OpenZeppelin/Truffle issue - they have an open ticket for it currently.

Also, if you’re trying to use Truffle on Ropsten, this is a known issue and they are targeting a fix next week. You can check the status of that here.

@Leiya_Kenney Thanks for the reply.

Any idea about insufficient funds for gas * price + value? It started happening at the same time as the EIP-155 error. The from address (0xb89A16…) definitely has enough ETH.

Here’s a minimal example:

const HDWalletProvider = require("@truffle/hdwallet-provider");
const Web3 = require("web3");

// Main function
async function main(cfg) {
  let w3 = new Web3(new HDWalletProvider({
    mnemonic: {phrase: "my 12 words"},
    providerOrUrl: "https://ropsten.infura.io/v3/<PROJECT_ID>"
  try {
    let result = await w3.eth.sendTransaction({
        // the From address is deterministically generated from my 12 word mnemonic
        from: "0xb89A165EA8b619c14312dB316BaAa80D2a98B493",
        to: "0xeee7bD8503A88200095EB32FE7cEC0D3293C504E",
        gasPrice: "150000000000",
        gas: "30000",
        chainId: "3",
        value: "1",
    console.log(" block " + result.blockNumber + " tx " + result.transactionHash + " gas " + result.cumulativeGasUsed);
  } catch (e) {
    console.error("Caught an exception:" + JSON.stringify(e));


Hey @ashleyvega - seems like you’re running into this issue due to using Truffle on Ropsten. We’ve confirmed with the Truffle team that they’re aware of this issue and they are working to release a fix soon. You can keep tabs on the status of this here!

@Leiya_Kenney truffle#3913 does not mention insufficient funds for gas * price + value.

However, the docker container I built at 2021-03-08 10:48 UTC stopped working at 2021-03-08 21:21 UTC, then started working again at 2021-03-11 00:05 UTC. I did not rebuild the container. So whatever Infura did ~12 hours ago fixed both EIP-155 and insufficient funds for gas * price + value.

Now the task (for me) is to add chainId to send() without causing the spurious insufficient funds error.

Thinking about things a bit, my assumption had been that with chainId: 3 added to send({...}), I had fixed the EIP-155 error and moved forward to the insufficient funds error.

I now think that adding chainId: 3 moved backward to the spurious and unhelpful insufficient funds error, and did not fix the EIP-155 error.

Note to future readers: DO NOT ADD chainId: 3 to send({...}), it is [almost certainly] the wrong thing to do.

@ashleyvega thanks for letting other users know what you tried!

As far as fixing that insufficient funds error, this thread has a few ideas on things to double-check to make sure your code is in order and things are pointing where they should be.

You may also need to update all your number to be in hexadecimal.

Please let us know if either of these works, or if you’re still searching for a solution!

@Leiya_Kenney Interesting …

let tx = {
  "chainId": "3",
  // the From address is deterministically generated from my 12 word mnemonic,
  // so web3 already knows the corresponding private key.
  "from": "0xb89A165EA8b619c14312dB316BaAa80D2a98B493",
  "to": "0xeee7bD8503A88200095EB32FE7cEC0D3293C504E",
  "gasPrice": "150000000000",
  "gas": "30000",
  "value": "1"

// The following does NOT work: insufficient funds for gas * price + value
let result = await w3.eth.sendTransaction(tx);

// The following DOES work.
const pk = 'xx'; // the private key corresponding to 0xb89A16...
let signedTx = await w3.eth.accounts.signTransaction(tx, pk);
let result = await w3.eth.sendSignedTransaction(signedTx.rawTransaction);

console.log("block " + result.blockNumber + " tx " + result.transactionHash + " gas " + result.cumulativeGasUsed);

I tried using hex numbers before, it didn’t change anything. I think this is because I’m not using numbers big enough to cause JS rounding errors, and I’m not trying to send the whole balance, which would legitimately cause insufficient funds if the amount being sent exceeded (due to rounding) the balance.