Security Considerations for Upgradeable Smart Contracts

4 min readAug 29, 2024

In the ever-evolving world of blockchain technology, smart contracts play a crucial role. However, the immutable nature of blockchain can pose challenges when it comes to updating or fixing smart contracts. This is where upgradeable smart contracts come into play. In this blog post, we’ll explore the security aspects of upgradeable smart contracts, focusing on proxy contracts and their implementation.

Upgradable smart contracts have gained popularity due to their flexibility in addressing bugs and enhancing functionalities post-deployment. However, they also introduce significant security risks, as evidenced by several high-profile attacks.

Notable Attacks and Losses

Wormhole Cross-Chain Bridge Attack: This incident resulted in a loss of approximately $320 million due to vulnerabilities in the upgradeable contract’s initialization process, allowing attackers to exploit the system without proper safeguards in place.
DODO DEX Hack: Here, attackers exploited a vulnerability in the upgradable contract, leading to a loss of about $3.8 million. The attack highlighted risks associated with improper upgrade mechanisms and storage collisions.

These Hacks underscore the necessity of robust security measures in upgradable smart contracts. The mutable nature of these contracts allows developers to implement fixes and enhancements, but it also opens avenues for malicious actors to exploit vulnerabilities, particularly if upgrade mechanisms are poorly managed.

Understanding Proxy Contracts

Proxy contracts are a fundamental concept in creating upgradeable smart contracts. Their primary function is to delegate calls to an implementation contract. This approach serves two main purposes:

1. Upgradeability: Allows updating the contract logic without changing the contract address.
2. Modular architecture: Maintains consistent storage while allowing for modular code structure.

The most common use case for proxy contracts is upgradeability. Transparent and UUPS (Universal Upgradeable Proxy Standard) contracts are two popular upgradeability patterns.

Transparent Proxy Pattern
Transparent proxies delegate calls to an implementation contract, with the implementation address stored in a specific storage slot. OpenZeppelin’s implementation is widely regarded as the most optimized.

Security Considerations for Transparent Proxies:
1. Proxy Contract:
— It should be identical to OpenZeppelin’s implementation or follow the same logic if it is custom-built.

2. Implementation Contract:
— Must not have a constructor.
— Should have an initializer function (equivalent to a constructor).
— Should inherit OpenZeppelin’s Initializable contract or ensure the initializer function can only be called once.
— State variables should not be initialized at deployment; all variable initialization should occur in the initializer function.
— Constant variables can be initialized before deployment.
— Cannot have immutable variables (as these contracts cannot have constructors).

Example: Transparent Proxy Contract (using OpenZeppelin)

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

import "@openzeppelin/contracts/proxy/transparent/TransparentUpgradeableProxy.sol";
import "./ERC20Implementation.sol"; // Your ERC20 implementation contractcontract ERC20Proxy is TransparentUpgradeableProxy {
    constructor(address _logic, address _admin, bytes memory _data) 
        TransparentUpgradeableProxy(_logic, _admin, _data) {}
}

Example: ERC20 Implementation Contract (using OpenZeppelin)

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

import "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";contract ERC20Implementation is Initializable, ERC20Upgradeable {
    function initialize(string memory name, string memory symbol) initializer {
        __ERC20_init(name, symbol);
    }    function mint(address to, uint256 amount) public {
        _mint(to, amount);
    }    // ... other ERC20 functions ...
}

3. Access Control:
— The proxy contract’s upgrade function must have proper access control mechanisms in place.

UUPS Pattern

UUPS (Universal Upgradeable Proxy Standard) is another popular pattern for upgradable contracts

Security Considerations for UUPS:
1. Proxy Contract:
— It should be identical to OpenZeppelin’s implementation or follow the same logic if it is custom-built.

2. Implementation Contract:
— Follows the same rules as Transparent Proxy implementation contracts.
— Must override the `_authorizeUpgrade()` function as internal.
— Access control should be implemented for the `_authorizeUpgrade` function.
— Must inherit the UUPSUpgradeable contract.

While UUPS contracts are more gas-efficient during execution, they are more complex to understand and implement correctly.

Example: UUPS Proxy Contract (using OpenZeppelin)

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

import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
import "./ERC20Implementation.sol"; // Your ERC20 implementation contractcontract ERC20Proxy is Initializable, UUPSUpgradeable {
    function initialize(address implementation) initializer{
        __UUPSUpgradeable_init();
        _setImplementation(implementation);
    }    function _authorizeUpgrade(address newImplementation) internal override onlyRole(DEFAULT_ADMIN_ROLE) {} 
}s

Example: ERC20 Implementation Contract (using OpenZeppelin)

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

import "@openzeppelin/contracts-upgradeable/token/ERC20/ERC20Upgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/UUPSUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/access/AccessControlUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";contract ERC20Implementation is Initializable, ERC20Upgradeable, UUPSUpgradeable, AccessControlUpgradeable {
    function initialize(string memory name, string memory symbol) initializer {
        __ERC20_init(name, symbol);
        __AccessControl_init();
        _grantRole(DEFAULT_ADMIN_ROLE, msg.sender);
    }    function mint(address to, uint256 amount) public onlyRole(DEFAULT_ADMIN_ROLE) {
        _mint(to, amount);
    }    // ... other ERC20 functions ...    function _authorizeUpgrade(address newImplementation) internal override onlyRole(DEFAULT_ADMIN_ROLE) {}
}

General Security Guidelines

Regardless of the chosen pattern, there are some general security guidelines to follow when working with upgradeable smart contracts:

1. Avoid Storage Collisions:
— Be cautious not to declare variables directly in proxy contracts (or contracts inheriting from proxies) as you would in generic smart contracts.
— This could lead to collisions with the implementation contract.
— Consider using randomized storage in the proxy to mitigate this issue.

2. Thorough Testing:
— Implement comprehensive test suites that cover both the proxy and implementation contracts.
— Include upgrade scenarios in your tests to ensure smooth transitions between versions.

3. Careful Access Control:
— Implement robust access control mechanisms for upgrade functions.
— Consider using multi-signature wallets or time-locks for critical upgrade operations.

4. Audit and Verify:
— Always have your upgradeable contracts audited by reputable security firms like QuillAudits.
— Verify the deployed bytecode matches the audited source code.

5. Transparent Upgrades:
— Communicate clearly with your users about the upgradeable nature of your contracts.
— Provide detailed documentation of any upgrades performed.

Conclusion

Upgradeable smart contracts offer flexibility in an otherwise immutable environment, but they come with their own set of security challenges. Developers can create secure and maintainable upgradeable smart contracts by understanding the complexity of proxy patterns like Transparent and UUPS and following best practices.

Please Note that the field of smart contract security is constantly evolving. Stay informed about the latest developments, and always prioritize security in your blockchain projects.

Written by Akshay Babhulkar
Project Lead QuillAudits - Web3 Security 🛡️

Originally published on: https://medium.com/@akshay.m_96876/security-considerations-for-upgradeable-smart-contracts-c4d329b48a58