Upgradeable Implementation Smart Contract still Callable Directly without going via Proxy

I am following the upgradeable deployment Tutorial found at this openzeppelin-upgrades-step-by-step-tutorial-for-truffle. I have created the two scripts hereafter.

1_initial_migration.js

const Migrations = artifacts.require("Migrations");
module.exports = function (deployer) {
  deployer.deploy(Migrations);
};

2_deploy_contract.js

const MyContract = artifacts.require('MyContract');
const { deployProxy } = require('@openzeppelin/truffle-upgrades');
module.exports = async function (deployer) {
  await deployProxy(MyContract, { deployer });
};

By proceeding as such, I was still able to call my Smart Contract Implementation directly, without going through the TransparentUpgradeableProxy (although I could also call it via the Proxy) on the Ganache blockchain (I could see the deployment addresses for both the Implementation Smart Contract and the Proxy upon deploying on that local blockchain). However, upon deploying on the Ropsten net, the Implementation Smart Contract address wasn't shown in the output, and thus couldn't see the address of the actual Implementation Contract. Will it be the same on MainNet?

Thank you. J

1 Like

You can always interact directly with the implementation contract. There is no simple way to avoid that.

However, you can do your best to ensure those interactions are not significant, by leaving the implementation in an "unusable" state. For example, if the contract is an ERC20, you can ensure the implementation has no supply and is not mintable, therefore no one would be able to use it.

This recommendation is documented at Initializing the Implementation Contract.

1 Like

Thank you @frangio Unfortunately, this is an ERC721 Contract, and users will always be able to mint new tokens. The only consequence that it could have, is that some of the info in the database of my Dapp would be out of sync with the blockchain if a user decided to call the contract outside my Dapp (although I do go back to the blockchain to verify token ownership). I am currently not using IPFS to refer to info not contained on the blockchain, but a backend database (something to change in the future).