Oz upgrade failed with error: Failed to check for transaction receipt

Support Contracts
1

I am trying to upgrade my mainnet contracts: github dot com / syscoin/sysethereum-contracts by adding safeerc20

:computer: Environment
solc 0.5.3, Truffle v5.1.5

I run npx oz upgrade and normally it asks which contracts or all to upgrade but it just goes ahead and deploys and then fails with:

“The package name, contract name, or address to upgrade must be provided, or set the all flag to upgrade all contracts in the application.”

The testnet branch I was able to deploy to rinkeby earlier.

do I have to use npx oz upgrade --all?

I initially tried to use infura in my truffle config with an hdwalletprovider, it had failed on :

:heavy_multiplication_x: Validating and deploying contract SyscoinSuperblocks

âś“ Contract SyscoinERC20Manager deployed

âś“ Contract SyscoinBattleManager deployed

âś“ Contract SyscoinClaimManager deployed

SyscoinSuperblocks deployment failed with error: Failed to check for transaction receipt:

{}

After that I switched to running a local geth node which I normally do to upgrade my contracts, and my account wasn’t sending transactions the nonce was OK but still was stuck locally, so I sent eth to a new account and tried and got the contracts deployed but it gives the “all contracts up-to-date” after or the “No contract instances that match were found” message.

Is it related to my openzeppelin/mainnet.json? is there a way to reproduce this file based on the current deployed proxy?

My original deployer account:

This is the address I used once I had my original account stuck:

1 Like
2

Hi @Jag_Sidhu,

Looking at your master branch you don’t appear to have your mainnet.json in version control. I suggest that you commit this as per the documentation: https://docs.openzeppelin.com/cli/2.8/configuration#configuration-files-in-version-control

As an aside, I also noticed that you have a mnemonic checked in. I recommend not committing any secrets (private keys, mnemonic). There are bots running on GitHub looking for secrets and emptying wallets.

The gas price at 10 gwei appears low given current network congestion: https://www.ethgasstation.info/

To test your upgrade, I suggest having a look at the following post (some of the commands are outdated but the concepts are still the same): https://blog.openzeppelin.com/testing-real-world-contract-upgrades/ Essentially it is taking a fork of mainnet, copying your .json and running your upgrade against the fork first.

If you have errors with this, can you please share the output of the upgrade command.

3

Hi @Jag_Sidhu,

It looks like you were adding to your question, as I was replying. Sorry for the cross over.

If I understand what happened:

  1. You tried to upgrade via Infura but received: deployment failed with error: Failed to check for transaction receipt
  2. You then tried to upgrade via a local geth node (using a different account) but get No contract instances that match were found

If you used a different account from what the contracts were originally deployed as, that account is not the owner of the proxy admin so won’t be able to upgrade (change the logic contract that the proxy points to).

4

Hi Andrew,

It does seem like mainnet.json got corrupted after step 1 somehow. I did find my current mainnet.json which likely has the proxy info correct still, I can try to change the contracts to try to force an upgrade with the correct key using local geth again.

So I did end up looking at the proxy section and re-entering details in there manually:

"proxies": {
    "sysethereum-contracts/SyscoinSuperblocks": [
      {
        "address": "0xa0Fe740Ed57C9FCB0A04E330824aD8aD574bc54c",
        "version": "1.0.0",
        "implementation": "0xA3C431e1694983262452CC0a6dC4A001D8a51C68",
        "admin": "0x8d827Cf5515718a79Be1DC38152873bC0C1cA263",
        "kind": "Upgradeable"
      }
    ],
    "sysethereum-contracts/SyscoinERC20Manager": [
      {
        "address": "0xFF957eA28b537b34E0c6E6B50c6c938668DD28a0",
        "version": "1.0.0",
        "implementation": "0x269B4F1105a71529f2eAc362299c0487a7936714",
        "admin": "0x8d827Cf5515718a79Be1DC38152873bC0C1cA263",
        "kind": "Upgradeable"
      }
    ],
    "sysethereum-contracts/SyscoinBattleManager": [
      {
        "address": "0xbf96Ded9600e6874c3247A61874f470fA7929f58",
        "version": "1.0.0",
        "implementation": "0x637e110A6C61cfd3a8838eC25a2DBF75A0F34B30",
        "admin": "0x8d827Cf5515718a79Be1DC38152873bC0C1cA263",
        "kind": "Upgradeable"
      }
    ],
    "sysethereum-contracts/SyscoinClaimManager": [
      {
        "address": "0xd03a860F481e83a8659640dC75008e9FcDF5d879",
        "version": "1.0.0",
        "implementation": "0xb6d93f5391a45c08028e449fc0d6427c63603da1",
        "admin": "0x8d827Cf5515718a79Be1DC38152873bC0C1cA263",
        "kind": "Upgradeable"
      }
    ]
  },
  "manifestVersion": "2.2",
  "version": "1.0.0",
  "proxyAdmin": {
    "address": "0x8d827Cf5515718a79Be1DC38152873bC0C1cA263"
  }

When I ran I got something new ("Call a function on the instance after upgrading it?"). My question about that is, this does not stop the upgrade from finishing properly right? I normally don't run anything after a proxy upgrade. You can see my migration to know if it indeed is correct or if I need to call something, I did not have to do this all the other times I upgraded though: https://github.com/syscoin/sysethereum-contracts/blob/master/migrations/2_deploy_contracts.js. You can see init is called but I think that is to the proxy so that should remain constant I assume?

All contracts are up to date

? Which instances would you like to upgrade? Choose by name

? Pick an instance to upgrade SyscoinERC20Manager

? Call a function on the instance after upgrading it? No

5

So I ran the upgrade after doing that:

All contracts are up to date

? Which instances would you like to upgrade? Choose by name

? Pick an instance to upgrade SyscoinERC20Manager

? Call a function on the instance after upgrading it? No

âś“ Instance upgraded at 0xFF957eA28b537b34E0c6E6B50c6c938668DD28a0. Transaction receipt: 0xb57c72e350342430189ac63d0b7296134cee1373a4700b490850ba49662b2af7

âś“ Instance at 0xFF957eA28b537b34E0c6E6B50c6c938668DD28a0 upgraded

I don’t see etherscan updating the proxy. I am not sure if it worked or not. Is there a way to re-create the mainnet.json based on the current configuration and the current proxies?

1 Like
6

Here is a full upgrade:

âś“ Contract SyscoinSuperblocks deployed

âś“ Contract SyscoinERC20Manager deployed

âś“ Contract SyscoinBattleManager deployed

âś“ Contract SyscoinClaimManager deployed

All contracts have been deployed

? Which instances would you like to upgrade? All instances

âś“ Instance upgraded at 0xbf96Ded9600e6874c3247A61874f470fA7929f58. Transaction receipt: 0x6325b15f63fa6750660dc29dda0a82bc1956f1c270f43c196b92b5fa8628d82c

âś“ Instance at 0xbf96Ded9600e6874c3247A61874f470fA7929f58 upgraded

âś“ Instance upgraded at 0xFF957eA28b537b34E0c6E6B50c6c938668DD28a0. Transaction receipt: 0x3fd324cfebe1ddcffd04199ac984f679908922f95dcc47cb93691fc69fd83248

âś“ Instance at 0xFF957eA28b537b34E0c6E6B50c6c938668DD28a0 upgraded

âś“ Instance upgraded at 0xa0Fe740Ed57C9FCB0A04E330824aD8aD574bc54c. Transaction receipt: 0xd22dde537346e0b0507fa5a399f24944937e9ee8be9c49de7e9488df1d39661b

âś“ Instance at 0xa0Fe740Ed57C9FCB0A04E330824aD8aD574bc54c upgraded

âś“ Instance upgraded at 0xd03a860F481e83a8659640dC75008e9FcDF5d879. Transaction receipt: 0xc93ab721852292dc0e95ba4cd5f54606dd0eb24d5f8a3511cbe48bd80abc0d01

âś“ Instance at 0xd03a860F481e83a8659640dC75008e9FcDF5d879 upgraded

I have pushed my mainnet.json to the repo if you want to see it: https://github.com/syscoin/sysethereum-contracts/blob/master/.openzeppelin/mainnet.json

It says it upgraded… I have upgraded from the proxy admin account, the etherscan address for admin shows it deployed contracts and then another transaction, but I don’t see any upgrade event and proxy hasn’t changed on etherscan… maybe you can check to see if the proxies are pointing to a new implementation.

7

I also noticed the src/destination is my deployer address which is not consistent with what I saw on rinkeby.

Mainnet: https://etherscan.io/tx/0x6325b15f63fa6750660dc29dda0a82bc1956f1c270f43c196b92b5fa8628d82c

Rinkeby:

8

If you need to initialize state in an upgrade, then you should have an upgradeX function with guarding in to ensure it can only be called once. If you don't have state to initialize, then you don't need to call a function as part of the upgrade process.

You would need to do this manually unfortunately.

I have run out of time to check this today unfortunately, so will need to have a look next week.

9

Ok thanks!

I think I have got it deployed now… I manually updated the addresses and proxy admin and it did upgrade… but now etherscan verify seems to fail.

Rinkeby verified after upgrade, the contracts are the same. I copied the rinkeby.json (post upgrade) and replaced addresses with mainnet ones and upgrade worked but verify says “Fail - Unable to verify”

Edit: I redeployed a new migration and that verified, so I took the implementation and pointed my old proxy to the new implementation which seemed to work so now upgrade is completed and its pointing to verified implementations, along with hopefully a mainnet.json file which will allow me to upgrade in the future… thanks for your time!

1 Like
10

Hi @Jag_Sidhu,

Congratulations on getting it resolved. I think network congestion becomes a pain point here.

11

Thanks for your time.

Yes on congestion I saw this as a big problem, we built a bridge between syscoin and ethereum that is trustless/decentralized and counterparty-less. The effect of it is to enable syscoin asset users to execute contracts on ethereum tooling but also offload ethereum congestion for simple value transfers off of eth to other chains like syscoin. We focus on SVT’s and make them as efficient as possible, through our probabilistic settlement algorithm for on-chain scaling and payment channels for off-chain (lightning network)

1 Like