Engineer debugging Solidity code on laptop at a standing desk, code visible on screen, reference docs on second monitor, casual office setup.
Glossary

Upgradeable Proxy

An upgradeable proxy is a smart contract architecture where a proxy contract delegates function calls to a separate logic contract, allowing the logic to be upgraded while preserving the contract's state and on-chain address.
definition
BLOCKCHAIN ARCHITECTURE

What is an Upgradeable Proxy?

An upgradeable proxy is a foundational smart contract design pattern that separates a contract's storage and logic, enabling the deployed code to be updated without migrating state or changing the contract's on-chain address.

An upgradeable proxy is a smart contract architecture where a proxy contract holds all storage (state variables like user balances) and delegates function calls via DELEGATECALL to a separate implementation contract (or logic contract) that contains the executable code. This separation is the core mechanism that allows for upgrades: developers can deploy a new implementation contract and instruct the proxy to point to it, thereby changing the contract's behavior while preserving all existing user data and the original contract address. The proxy pattern is essential for fixing bugs, adding features, or responding to evolving protocol requirements after initial deployment.

The upgrade process is managed by an admin or a governance mechanism, which authorizes the proxy to update its stored reference to the new implementation. Common proxy standards include the Transparent Proxy Pattern, which prevents function selector clashes between the proxy and implementation, and the more gas-efficient UUPS (Universal Upgradeable Proxy Standard), where the upgrade logic is built into the implementation contract itself. A critical security component is the Proxy Admin, a separate contract that typically holds the upgrade authorization rights, adding a layer of separation between the proxy's logic and its administrative controls.

While powerful, upgradeability introduces significant trust assumptions and centralization risks, as the entity controlling the upgrade key can alter the contract's rules. To mitigate this, projects often vest upgrade authority in a decentralized DAO or implement timelocks to delay execution, allowing users to react to proposed changes. Developers must also carefully manage storage layout across upgrades; incompatible changes to variable declarations in new implementations can irreversibly corrupt the proxy's stored data. This pattern is widely used by major DeFi protocols and dApps, such as OpenZeppelin libraries and Aave, to ensure long-term adaptability and security maintenance.

how-it-works
BLOCKCHAIN ARCHITECTURE

How an Upgradeable Proxy Works

An upgradeable proxy is a smart contract design pattern that separates a contract's storage and logic, enabling the deployed code to be changed without migrating state or altering the contract's on-chain address.

An upgradeable proxy is a smart contract architecture where a permanent proxy contract delegates all function calls to a separate implementation contract (or logic contract) using the delegatecall opcode. This separation is fundamental: the proxy holds the storage (state variables like user balances) and the external address, while the implementation contract contains the executable code. To upgrade, a developer deploys a new implementation contract and instructs the proxy to point to this new address, instantly changing the contract's logic for all future calls while preserving all existing data.

The core mechanism enabling this is delegatecall, a low-level EVM operation that executes code from the implementation contract within the context of the proxy's storage. This means the logic contract's code reads from and writes to the proxy's storage slot, ensuring state persistence across upgrades. Critical to this pattern's security is a proxy admin or ownership mechanism, which controls the privileged function to update the implementation address, preventing unauthorized upgrades. Common standard implementations include the Transparent Proxy pattern and the more gas-efficient UUPS (EIP-1822) pattern, where upgrade logic is built into the implementation itself.

While powerful, upgradeability introduces significant security and decentralization considerations. It requires immense trust in the entity controlling the upgrade key, as a malicious upgrade could alter any aspect of the contract's behavior. Best practices involve using audited, standard proxy libraries like OpenZeppelin's, implementing timelocks for upgrades, and eventually moving to a fully immutable state. This pattern is essential for long-lived DeFi protocols and dApps that require bug fixes and feature additions post-deployment without disrupting user experience or fragmenting liquidity.

key-features
ARCHITECTURAL PATTERNS

Key Features of Upgradeable Proxies

Upgradeable proxies are a foundational smart contract pattern that separates a contract's storage and logic, enabling controlled updates while preserving state and address. This section details their core operational mechanisms and security considerations.

01

Proxy Contract (Storage Layer)

The Proxy Contract is the persistent, user-facing address that holds all the contract's state variables and user balances. It contains minimal logic, primarily a fallback() or receive() function that delegates all calls to a separate Implementation Contract using delegatecall. This ensures the storage context remains within the proxy, making upgrades seamless for users who interact with a single, unchanging address.

02

Implementation Contract (Logic Layer)

The Implementation Contract (or Logic Contract) contains the executable code and business logic. It is a standard smart contract but is never called directly by end-users. When the proxy delegates a call to it, the code executes in the context of the proxy's storage. This separation allows developers to deploy a new implementation contract and point the proxy to it, thereby upgrading the system's functionality without migration or data loss.

03

Delegatecall Operation

delegatecall is the low-level EVM opcode that enables the proxy pattern. When invoked, it executes the code from the implementation contract as if it were running inside the proxy's own context. This means:

  • The implementation code reads from and writes to the proxy's storage.
  • msg.sender and msg.value are preserved from the original call.
  • The implementation's address (this) within the delegatecall context is the proxy's address, a critical detail for security.
04

Upgrade Mechanisms & Admin Control

Upgrading requires a secure method to change the implementation address stored in the proxy. Common patterns include:

  • Transparent Proxy Pattern: Uses an Admin address (often a multisig or governance contract) to perform upgrades, while regular users' calls are transparently delegated. Prevents selector clashes between admin and user functions.
  • UUPS (Universal Upgradeable Proxy Standard): The upgrade logic is built into the implementation contract itself, making proxies more gas-efficient. The upgrade function must be explicitly included and can be removed in future versions to make a contract immutable.
  • Proxy Admin Contract: A separate contract that acts as the owner of multiple proxies, centralizing upgrade management.
05

Storage Collisions & Initialization

A major risk in upgradeable contracts is storage collision, where variables in a new implementation are declared in a different order, corrupting data. Solutions include:

  • Inherited Storage Layouts: Using a base contract that defines a persistent storage structure.
  • EIP-1967 Storage Slots: Using specific, pseudo-random storage slots (e.g., 0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc) to store the implementation address, preventing clashes.
  • Initializer Functions: Since constructors cannot be used (they run only on deployment of the implementation), an initialize() function, often protected by an initializer modifier, is used to set up initial state on the proxy.
06

Security Considerations & Trade-offs

While enabling flexibility, upgradeability introduces unique risks:

  • Centralization Risk: The entity controlling the upgrade key (admin) has immense power, creating a potential single point of failure.
  • Implementation Integrity: If the upgrade mechanism is compromised, malicious code can be deployed.
  • Testing Complexity: Upgrades require rigorous testing of state compatibility and integration.
  • Trust Minimization: Protocols often use timelocks and governance (e.g., DAO votes) to control upgrades, moving from admin keys to decentralized decision-making. The trade-off is between mutability for bug fixes and immutability for trustlessness.
Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

EVM ecosystems

  • Ethereum logo
    Ethereum
  • Arbitrum logo
    Arbitrum
  • Optimism logo
    Optimism
  • Polygon logo
    Polygon
  • Avalanche logo
    Avalanche
  • Cronos logo
    Cronos

Non-EVM ecosystems

  • Solana logo
    Solana
  • Sui logo
    Sui
  • Aptos logo
    Aptos
  • Hedera logo
    Hedera
  • Stellar logo
    Stellar
  • NEAR logo
    NEAR

Additional ecosystems

  • Polkadot logo
    Polkadot
  • Cosmos logo
    Cosmos
  • TON logo
    TON
  • Cardano logo
    Cardano
  • Algorand logo
    Algorand
  • Tempo logo
    Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

UPGRADE MECHANICS

Proxy Pattern Comparison: Transparent vs UUPS

A technical comparison of the two dominant proxy patterns for upgradeable smart contracts, focusing on implementation details, security, and gas costs.

FeatureTransparent ProxyUniversal Upgradeable Proxy Standard (UUPS)

Upgrade Logic Location

Proxy Contract

Implementation Contract

Proxy Contract Size

~5.5K gas larger deployment

Minimal, base proxy only

Upgrade Authorization

Proxy admin address

Implementation contract logic

Implementation Initialization

Separate from upgrade call

Can be bundled with upgrade call

Storage Collision Risk

Uses unstructured storage

Uses unstructured storage

Inadvertent Selfdestruct Risk

Proxy admin can selfdestruct implementation

Implementation can selfdestruct itself via upgrade

Typical Gas Cost for Upgrade

~45K gas

~30K gas

Notable Implementation

OpenZeppelin TransparentUpgradeableProxy

OpenZeppelin UUPSUpgradeable

UPGRADEABLE PROXY

Frequently Asked Questions

A technical deep dive into the smart contract pattern that enables on-chain upgrades, its security models, and implementation nuances.

An upgradeable proxy is a smart contract design pattern that separates a contract's storage and logic, allowing the deployed logic to be updated while preserving the contract's state and address. It works through a delegatecall operation: a proxy contract (holding the storage) forwards all function calls to a separate logic contract, executing the logic contract's code within the proxy's own storage context. The proxy stores the address of the current logic contract, and an admin can update this address to point to a new, upgraded version, effectively changing the contract's behavior without migrating assets or breaking integrations.

Key Components:

  • Proxy Contract: The persistent address users interact with; holds all state variables.
  • Logic/Implementation Contract: Contains the executable code; can be replaced.
  • Proxy Admin: A contract or EOA with permissions to upgrade the logic address, often managed via a Timelock for security.
Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
ChainVote logo
Reax logo
Sokail logo
Swapsicle logo
SyntheX logo
Tekika logo
Telos logo
Zexe logo
I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.
L
Lee Erswell
CEO, Telos Foundation
how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

01

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

02

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

03

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

04

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Start a build

Need a blockchain engineering team?

Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.