Unable to upgrade contract Ownable: caller is not the owner

i have deployed my contract and once i try to update my proxy with the same owner , i got the Caller is not owner error

Hello @AmirDoreh,

caller is not the owner is an error you get when an unauthorized account tries to call a function that has the onlyOwner modifier.

From the code you include above its difficult to see what exactly is happening. Can you give more details about your upgrade process (what kind of proxy, what is the previous implementation, what is the new implementation) ?

I dont have such issue on Testnet .
for test purpose i just add a new function to the last part of my contract , i make sure my caller is the one who deployed the old contract but again i got that issue .
here is my inheritances
Screenshot 2023-04-03 at 2.36.40 PM

and this is my setup initializer function
Screenshot 2023-04-03 at 2.37.21 PM

This setup function is initializer. This can fail, but it would cause a very different error.

__Ownable_init does not perform any caller check. So this cannot cause the caller is not the owner check.

You error must come from somewhere. And there is no way to help without a broader view.

it is not failing at all
the contract deployment and upgrade works as charm on testnet, but on mainnet once i try to upgrade i got that Caller is not the owner error even if the owner is the caller. @Amxx

what proxy pattern you used for? if you utilize the transparent proxy, there is proxy admin contract to play the contract upgrade role.

the type is transparent.
the proxy admin is also set to the the caller . but still getting the same error @uua

i tested to deploy & upgrade proxy contract using transparent pattern at sepolia (goerli is scarce and expensive rn).

implementation contract is inherit to {ERC721AUpgradeable} and {OwnableUpgradeable} (see implementation contract's code below)

here's the initialize function at the implementation contract:

function initialize(
    string memory name,
    string memory symbol
) external initializerERC721A initializer {
    __ERC721A_init(name, symbol);

here's my proxy deployment script via hardhat:

const { ethers,upgrades } = require("hardhat");

async function main() {
  const Implementation = await ethers.getContractFactory("SimpleERC721Trans"); 
  const Proxy = await upgrades.deployProxy(Implementation, ["SimpleERC721","TRANS"], {
      initializerERC721A: "initialize",
      initializer: "initialize",
  await Proxy.deployed();

  console.log("Proxy Contract deployed to:", Proxy.address);

  .then(() => process.exit(0))
  .catch((error) => {

and the results are:
Transparent Upgradeable Proxy

Implementation Contract

Proxy Admin

and then i checked:

  1. the owner of the proxy admin contract via "read contract" tab and
  2. the owner of transparent upgradeable proxy contract via "read as proxy" tab
    at sepolia's etherscan and they return: 0xcfd86e16635486b2eCAf674A98F24ed12a15c3b4 -- it means the __Ownable_init() function from {OwnableUpgradeable} works well. the owner is the deployer address.


last part, i created an upgraded implementation contract (just adding function burn to the contract) using this script:

const { ethers,upgrades } = require("hardhat");

async function main() { 
 // The address of the Transparent Upgradeable Proxy (above)
  const PROXY_ADDRESS = "0x0e50Ea4a0ec7869edF34465F98Eb7B9ef14543d2";  
  const newImplementation = await ethers.getContractFactory("SimpleERC721Trans_v2");
  await upgrades.upgradeProxy(PROXY_ADDRESS, newImplementation);

  console.log("Implementation Contract upgraded.");

  .then(() => process.exit(0))
  .catch((error) => {

it deployed the new implementation contract (v2) at this txn hash:

and triggered the proxy admin contract to call upgrade method at this txn hash:

Implementation Contract (v2)

and if we check "read as proxy" tab at the proxy contract, we got this info:

ABI for the implementation contract at 0xaeb0bd3bf0f7686ae6bd257eda1eedc0eabc7ff1, using the EIP-1967 Transparent Proxy pattern.
Previously recorded to be on 0xe008d12123f312c7056473b8b4445108a3bc6a4b.

it means the upgrading process is successful. i hope it can help your case @AmirDoreh

1 Like