OwnableUpgradable setting initial owner to 0x0 on initialization in remix

Support Contracts
1

Im trying to write an ownable upgradeable ERC721 contract for NFTs using remix IDE. I used the open zeppelin wizard to just create a base for the contract without any of the NFT functions added yet but even just using the code output from the wizard of an ownable upgradeable contract on deployment the contract initializes with the 0x0 address as the owner. Ive read all the other posts about this and none of them worked. Again im using remix so not really even using a deployment script. The code the wizard produced that still sets the owner to 0x0 initially is attached below. We are on a time crunch so any quick help would be loved

:1234: Code to reproduce

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.2;

import "@openzeppelin/contracts-upgradeable/token/ERC721/ERC721Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC721/extensions/ERC721EnumerableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC721/extensions/ERC721URIStorageUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/security/PausableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/token/ERC721/extensions/ERC721BurnableUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/utils/CountersUpgradeable.sol";

contract Contract1 is Initializable, ERC721Upgradeable, ERC721EnumerableUpgradeable, ERC721URIStorageUpgradeable, PausableUpgradeable, OwnableUpgradeable, ERC721BurnableUpgradeable {
    using CountersUpgradeable for CountersUpgradeable.Counter;

    CountersUpgradeable.Counter private _tokenIdCounter;

    /// @custom:oz-upgrades-unsafe-allow constructor
    constructor() initializer {}
    

    function initialize() initializer public {
        __Ownable_init_unchained();
        __ERC721_init("Contract1", "CK");
        __ERC721Enumerable_init();
        __ERC721URIStorage_init();
        __Pausable_init();
        __ERC721Burnable_init();
    }

    function _baseURI() internal pure override returns (string memory) {
        return "https://gateway.pinata.cloud/ipfs/QmViwiqtVtGWjnYYHwsnQQwfqps3bEsRJ2bveAhnyCBrrV";
    }

    function pause() public onlyOwner {
        _pause();
    }

    function unpause() public onlyOwner {
        _unpause();
    }

    function safeMint(address to) public onlyOwner {
        _safeMint(to, _tokenIdCounter.current());
        _tokenIdCounter.increment();
    }

    function _beforeTokenTransfer(address from, address to, uint256 tokenId)
        internal
        whenNotPaused
        override(ERC721Upgradeable, ERC721EnumerableUpgradeable)
    {
        super._beforeTokenTransfer(from, to, tokenId);
    }

    // The following functions are overrides required by Solidity.

    function _burn(uint256 tokenId)
        internal
        override(ERC721Upgradeable, ERC721URIStorageUpgradeable)
    {
        super._burn(tokenId);
    }

    function tokenURI(uint256 tokenId)
        public
        view
        override(ERC721Upgradeable, ERC721URIStorageUpgradeable)
        returns (string memory)
    {
        return super.tokenURI(tokenId);
    }

    function supportsInterface(bytes4 interfaceId)
        public
        view
        override(ERC721Upgradeable, ERC721EnumerableUpgradeable)
        returns (bool)
    {
        return super.supportsInterface(interfaceId);
    }
}

:laptop: Environment

Remix

1 Like
2

Realized the original output was like this for the initializer function... still sets owner to 0x0

function initialize() initializer public {
        __ERC721_init("Contract1", "CK");
        __ERC721Enumerable_init();
        __ERC721URIStorage_init();
        __Pausable_init();
        __Ownable_init();
        __ERC721Burnable_init();
    }
3

There's 8 different imports and my first thought is that something is vague and it's running a different super-function than the one you think runs.

Check if your imports are importing the same libs that you later import yourself. I don't think the solidity compiler complains it there's super function ambiguity.

4

You're likely not invoking the initialize() function. You're also likely not deploying this contract behind a proxy, so it is not really upgradeable.

Remix is not a good fit for upgradeable contracts. This should be featured more prominently in the Wizard (see https://github.com/OpenZeppelin/contracts-wizard/issues/63).

I strongly recommend using Hardhat with our Upgrades plugin.

5

Hi, I'm having a similar issue using hardhat. The contract gives the owner as 0x0, yet when I run the initialize() function on it, it says: VM Exception while processing transaction: reverted with reason string 'Initializable: contract is already initialized'

What might be going wrong? How should we initialise an upgradeable contract? the docs are lacking on this point.

Using upgrades package and all the rest as per the docs...

6

Hi, welcome to the community! :wave:

If you do not use the Upgrades plugin, I think you can call initialize() in the proxy contract manually, and you can share the contract address if possible.

7

It sounds like you're interacting with the implementation contract as opposed to the proxy contract. Can you share some of the code you're testing this with?

10

could have been that, we ended up just not making it upgradeable as immutable X didnt like it either, thanks for the replies though you guys are awesome :slight_smile:

11

Will do for my future projects, thanks again for the replies you guys are amazing :slight_smile:

12

we ended up just not making it upgradeable as immutable x didnt like upgradeable contracts either but thank you for the reply :heart: