Why would anyone use proxies that do not support upgradable contracts? Instead, just create contract without a proxy, doesn't that save the trouble?

// SPDX-License-Identifier: MIT
pragma solidity 0.8.15;

import { Initializable } from "@openzeppelin/contracts/proxy/utils/Initializable.sol";

contract Test is Initializable {
    address public owner;

    constructor() public {
        owner = msg.sender;
    function initialize()
    // logic

Aren't all proxies meant to support upgradable implementation contracts??

Another question is since it uses a non-upgradable contract, is it still susceptible to the constructor caveat? Openzeppelin Docs

2 Answers 2


Proxies can be implemented with and without the upgradeability feature (see Proxies). Depending on the use case or technical considerations, you may opt to deploy a non-upgradeable proxy using one of the most known mechanism such as Diamond Proxy (see ERC-2535).

One use case of a non-upgradeable proxy would be to separate your contract's functions into smaller contracts called facets and allow your proxy to route functions call to the proper facet. By doing so, for example, you can get rid of the maximum contract size limit (which is now 24.576 kb).

  • But am wondering if it's still susceptible to if it's non upgradable Constructor Caveat Mar 28 at 8:08
  • No matter of the type of the proxy (upgradeable or non-upgradeable) they are still oblivious to the existence of constructors in the logic contracts. Therefore, whenever the proxy links to a logic contract, one must use a initializer function rather than a constructor so the proxy can sync with the logic contract state. Mar 28 at 8:20
  • Hmm, what if you were in the constructor to call the initializer function? 1) Deploy new Implementation 2) Upgrade to new implementation How would this negatively affect the newly implemented contract? Mar 28 at 8:42
  1. @openzeppelin/contracts/proxy/utils/Initializable.sol and @openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol is the same, diffrent import from diffrent package

  2. When using upgradable we don't use the constructor to prevent re-initialize contract state

  /// @custom:oz-upgrades-unsafe-allow constructor
  constructor() {
  • I agree on the first point, but the second point we should do it for almost all contracts. But am wondering if it's still susceptible to Constructor Caveat Mar 28 at 7:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.