Error: Deployment at 0x.. address is not registered

Support Upgrades
1

We are trying to prepare a contract for upgrade as we always do but get an error, here is our code:

VNFTxV4 = await ethers.getContractFactory("VNFTxV4");
  console.log("Preparing upgrade...");
  vnftxV4Address = await upgrades.prepareUpgrade(proxy, VNFTxV4, {
    unsafeAllowCustomTypes: true,
  });

:computer: Environment

Using hardhat-upgrades on osx

:memo:Details

the error I get is

Error: Deployment at address 0x4fEd51889672dcF22EDe6CD2421cF2aD74E1B287 is not registered

:1234: Code to reproduce

1 Like
2

Hi @surfer77,

I am sorry that you are having this issue.

I reproduced by removing my <network_name>.json file.

$ npx hardhat run --network rinkeby scripts/prepare_upgrade.js
Preparing upgrade...
Error: Deployment at address 0x71a939282aE70747A30007a857c6D7B664554846 is not registered
    at Manifest.getDeploymentFromAddress (/home/abcoathup/projects/forum/surfer77/node_modules/@openzeppelin/upgrades-core/src/manifest.ts:55:13)

What network are you deploying to?
Is your <network_name>.json file checked in if it is a public network?
Is the previous implementation 0x4fEd51889672dcF22EDe6CD2421cF2aD74E1B287 listed in <network_name>.json?

1 Like
3

Hi! we are trying to deploy to mainnet, the address you provided is not under implems, how should i add it?

It seems I am missing VNFTx3 in mainnet.json because not I was who deployed that version, I am trying to recreate it but any help is welcome as I don't want to mess up the storage fields.

 "manifestVersion": "3.1",
 "impls": {
   "2576de311ef3c85ba4a60e05ae556342448e097e31b93a1a7516761c41593763": {
     "address": "0xaB03D275cc0a02b607992E5FD455Eb41aEd5fa91",
     "txHash": "0x8d3f3b1df52bfbf40d15f485ff25879745fece67e5d3a24183f39edf6050f561",
     "layout": {
       "storage": [
         {
           "contract": "Initiali```
1 Like
4

Hi @surfer77,

First I recommend adding your public <network_name>.json files to version control: https://docs.openzeppelin.com/upgrades-plugins/1.x/network-files#configuration-files-in-version-control

This is used to check the upgrade safety of your contract when you prepare the upgrade.

I recommend creating higher level tests to test the upgrade from one version to another to check for upgrade safety.

You may be able to deploy the original version to a public testnet and then copy this to <network_name>.json and update the addresses. Though I would like to confirm that this is the best approach.

2 Likes
5

I made a duplicated post in same section and removed (we are on same project)

Yes we have the json file for first deployment and second version but missing the third.

Do you have any pointer on how is generated the keys for the impls object? I manage to recreate all the file but keys are different.

Also if we make sure about the storage order, could we just deploy the contract then call manually:
Function: upgrade(address proxy, address implementation)

or would there be potential issues?

Thanks

1 Like
6

The keys are the hash of the bytecode with the metadata part removed.

Yes, that would be fine, if you check the storage order and your new contract is upgrade safe according to the plugin.

Do you have the source code for the version that is missing? I can take a look if there's something we can do for you to properly register an implementation in your network file.

2 Likes
7

Here is the issue for registering an implementation contract that is already deployed on chain:

I wasn’t able to implement it quickly, so I don’t know when we’ll be able to implement it.

2 Likes
8

Hi @Jules_Dourlens & @surfer77,

Just wanted to follow up and see if you were able to resolve?

9

Hi @Jules_Dourlens & @surfer77,

We have found an error in Upgrades Plugins for Truffle and Hardhat. Users of the flag unsafeAllowCustomTypes should update their dependencies to the latest version.

See post for more details: Problem in Upgrades Plugins for users of unsafeAllowCustomTypes.

10

Hey Thanks for reaching out, yeah I managed to make it back manually and we updated too for future releases :wink:
Thanks

1 Like
11

I'm having a similar issue here. @frangio, please could you assist?

12

Hey @abcoathup @frangio I my case I have matic set as the network but still then when ever I compile only unknown-31337.json file is being created not matic.json. Can you please help me in this?

13

Create a new thread and share more detail please.

14

hey id like to share a solution that may be of help to ppl who come here because this forum helped me figure it out. Basically as @abcoathup says the error can come from not having a Network.json file in the .openzeppelin folder in your project root. this was the case with me. i had freshly cloned into our teams repo and when i made tried to upgrade i was getting this same error

Error: Deployment at address 0x.... is not registered

if you do not have this file you will need to add it. it will be accessable from the person who has originally deployed the contracts. for my case ive done this but can confirm that the "hacky" solution @abcoathup proposed also works where if you run your upgrade script in a freshly cloned repo the Network.json file will get generated and you can simply swap out the implementation and proxy contract addresses with the correct ones and the upgrade will work. but yeah more advisable touse original file as the second solution just seems really hacky to me. was stuck on this for a while and would consider myself more less experienced in this topic than other posters here so if anyone comes by this i hope i explained simle enough.

2 Likes
15

Using the network file that was created by the original deployment is the ideal approach. If that is not available, an alternative is to use the forceImport function to import existing proxy deployments.

1 Like
16

Thank you very much.
I was working in my hardhat local network and I have executed twice the same upgrade. This produces errors because the .json content.
Your answer has been very helpful.