Initializers, proxies and the contract nobody owns

A constructor is one of the few places in Solidity where access control is automatic. It runs once, at deployment, in the context of the contract being created, and nobody can call it again. Upgradeable contracts give that guarantee up. Their setup logic moves into an ordinary function, and ordinary functions have to be protected by hand.

This primer walks through the failures that follow from that change, why some of them are subtle, and the baseline Quantix reviewers expect to see in any proxy-based system.

Why constructors disappear

In the common proxy patterns, users interact with a small proxy contract that stores all state and forwards every call to an implementation contract using delegatecall. The implementation’s code runs, but it reads and writes the proxy’s storage. Standardised storage slots, defined in EIP-1967, tell tools where the proxy keeps the implementation address and admin.

A constructor, however, runs only once, when the implementation is deployed, and it writes to the implementation’s own storage. Nothing it sets is visible through the proxy. So upgradeable contracts replace the constructor with an initialize function that the proxy calls after deployment. From that point on, the safety of the system depends on three things the compiler no longer enforces: that initialize runs exactly once, that the right party runs it, and that the implementation contract itself cannot be initialised by someone else.

The initializer anyone can call

The simplest failure is an initializer without a guard.

1// Illustrative only. Several independent problems are shown together.2contract VaultV1 is UUPSUpgradeable, OwnableUpgradeable {3    IERC20 public asset;4 5    // (1) No constructor: the implementation itself is never locked.6 7    // (2) No initializer modifier: callable again, by anyone, at any time.8    function initialize(IERC20 asset_, address owner_) external {9        asset = asset_;10        __Ownable_init(owner_);11    }12 13    function _authorizeUpgrade(address) internal override onlyOwner {}14}

Without the initializer modifier, initialize can be called again after deployment. Here, calling it re-runs __Ownable_init and hands ownership, and with it the power to authorise upgrades, to whoever calls it. An upgrade to a malicious implementation then gives the caller control of every asset the proxy holds.

A second, quieter version of the same problem is a race. If the proxy is deployed in one transaction and initialised in the next, anyone watching the mempool can call initialize first with their own parameters. The fix is to make deployment and initialisation atomic: proxy constructors that accept initialisation data execute it in the same transaction.

1// Two separate transactions: the window between them is the vulnerability.2const proxy = await ERC1967Proxy.deploy(implementation, "0x")   // tx 13await vault.attach(proxy).initialize(asset, owner)               // tx 2 (can be front-run)4 5// One transaction: initialisation data is executed by the proxy constructor.6const data = Vault.interface.encodeFunctionData("initialize", [asset, owner])7const proxy = await ERC1967Proxy.deploy(implementation, data)

The implementation nobody owns

Even when the proxy is initialised correctly, the implementation contract sits on-chain as a separate, callable contract with its own, empty storage. If its initialize function is unprotected at that address, anyone can call it and become the implementation’s owner.

For many designs that is harmless, because the implementation’s storage is never used. For UUPS proxies it was not. In the UUPS pattern the upgrade logic lives in the implementation. In 2021 OpenZeppelin published an advisory (CVE-2021-41264) for UUPSUpgradeable in Contracts 4.1.0 to 4.3.1: an attacker who initialised an implementation could call its upgrade function directly and have it delegatecall into a contract that executed selfdestruct, removing the implementation’s code and leaving every proxy pointing at it unable to operate.

The defence is one line. Calling _disableInitializers() in the implementation’s constructor marks it as fully initialised, so initialize reverts at the implementation address while still working through the proxy, whose storage is separate.

Re-initialisation and inheritance

Upgrades often need setup of their own: a new fee parameter, a new role, a migrated value. Teams sometimes add an unguarded setupV2 function and call it straight after the upgrade, which reopens the original problem for the new variables. Versioned guards such as OpenZeppelin’s reinitializer(n) allow each version’s setup to run exactly once.

Inheritance adds a second hazard. Upgradeable base contracts expose their own initialisation functions, and in deep or diamond-shaped hierarchies it is easy to call a parent’s initialiser twice, or not at all. Calling it twice may silently reset state; skipping it leaves variables at their zero values, which for an owner or a pause flag can be just as dangerous as an attacker’s choice.

Finally, every upgrade must preserve storage layout. Adding a variable to a base contract shifts the slots of every variable declared after it in derived contracts. Reserved storage gaps, or namespaced storage as described in ERC-7201, keep layouts stable across versions, and upgrade tooling can check layouts automatically before a deployment.

Who may upgrade, and how fast

Initialisation decides who holds privileged roles; upgrade authorisation decides what those roles can do with them. In the transparent proxy pattern the upgrade function lives in the proxy and is reachable only by a dedicated admin, usually a separate admin contract. In UUPS the upgrade function lives in the implementation, and each implementation must restrict it by overriding an authorisation hook such as _authorizeUpgrade.

That design places a burden on every future version. An implementation that forgets the access check lets anyone upgrade the proxy. An implementation that omits the upgrade logic entirely leaves the proxy permanently frozen at that version, which may be intended but is rarely discussed. OpenZeppelin’s UUPS implementation checks that a new implementation reports the expected proxiable identifier before switching to it, which catches some, but not all, of these mistakes.

Speed matters as much as authority. An upgrade that takes effect in the same block it is proposed gives users no chance to react to a malicious or mistaken change. Routing upgrades through a timelock, and publishing the pending implementation address, turns an instantaneous risk into an observable one that monitoring can flag.

A safer baseline

1contract VaultV1 is UUPSUpgradeable, OwnableUpgradeable {2    IERC20 public asset;3 4    /// @custom:oz-upgrades-unsafe-allow constructor5    constructor() {6        _disableInitializers();       // the implementation can never be initialised7    }8 9    function initialize(IERC20 asset_, address owner_) external initializer {10        __Ownable_init(owner_);11        __UUPSUpgradeable_init();12        asset = asset_;13    }14 15    function _authorizeUpgrade(address) internal override onlyOwner {}16}17 18contract VaultV2 is VaultV1 {19    uint256 public withdrawalFee;20 21    // New setup for version 2 runs once, and only through a guarded path.22    function initializeV2(uint256 fee) external reinitializer(2) onlyOwner {23        withdrawalFee = fee;24    }25}

Review checklist

• Every initialize and versioned setup function carries an initialisation guard.
• Implementation constructors call _disableInitializers().
• Deployment scripts initialise proxies atomically; the scripts are in scope for review.
• Each parent initialiser is called exactly once, and tests assert the resulting state.
• Upgrade authorisation is restricted, ideally behind a timelock that users can observe.
• Storage layout is checked between the deployed version and the candidate upgrade.

Most of these items can be tested, and should be. A deployment test that runs the real deployment script against a local fork, then asserts the owner, the paused state, every role and every configured address through the proxy, catches skipped initialisers before they reach production. A second test that calls initialize again, both on the proxy and on the implementation, and expects both calls to revert, documents the guarantee in code. For upgrades, a test that deploys the next version, performs the upgrade through the same path governance will use, and re-checks the stored state, is the cheapest insurance available against layout drift.

None of these items is exotic. They are easy to state and easy to miss, because the code that breaks them often looks exactly like code that is correct. That is why reviewers check deployment scripts and upgrade procedures alongside the contracts themselves.

Conclusions

Moving construction into an ordinary function moves its guarantees into the developer’s hands. Every failure in this primer is the absence of one of three properties: initialisation runs exactly once, the right party runs it, and the implementation contract cannot be initialised by anyone else.

Each property is cheap to establish and cheap to test, and missing one usually costs control of the whole system. Our primer on upgradeable proxy security continues with storage layout, selector clashes and the governance of upgrades.

Recommendations