upgrade-solidity-contracts

Guide Solidity contract upgrades using OpenZeppelin proxy patterns and storage-layout validation.

203|28|Updated Feb 5, 2026
One-click install
npx skills add https://github.com/OpenZeppelin/openzeppelin-skills --skill upgrade-solidity-contracts
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: upgrade-solidity-contracts
Source: https://github.com/OpenZeppelin/openzeppelin-skills/tree/main/skills/upgrade-solidity-contracts
Command: npx skills add https://github.com/OpenZeppelin/openzeppelin-skills --skill upgrade-solidity-contracts

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Upgrading Solidity contracts can be risky due to storage layout constraints, lack of initializer usage, and upgrade path complexity. This Skill guides developers through safe upgrade practices using OpenZeppelin proxy patterns to preserve state and enable future upgrades.

Core Features & Use Cases

  • Supports UUPS, Transparent, and Beacon proxy patterns for upgradeable contracts.
  • Emphasizes using initializer functions instead of constructors and enforcing storage-layout compatibility.
  • Provides guidance for Hardhat Upgrades and Foundry upgrades workflows, including validation and deployment steps.

Quick Start

Provide a step-by-step upgrade plan for converting my Solidity project to an OpenZeppelin upgradeable pattern

Frequently Asked Questions about upgrade-solidity-contracts

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I upgrade Solidity contracts without breaking storage layout?

To upgrade Solidity contracts without breaking storage layout, use OpenZeppelin proxy patterns that preserve state and enforce storage-layout compatibility validation during the upgrade process.

What is the difference between UUPS, Transparent, and Beacon proxy patterns?

UUPS, Transparent, and Beacon proxies are OpenZeppelin upgradeable patterns that differ in where the upgrade logic resides and how the implementation contract is managed across multiple deployed proxies.

How do I migrate Solidity contracts to OpenZeppelin v5 upgradeable proxies?

Migrating to OpenZeppelin v5 proxies involves converting constructors to initializer functions and validating your existing storage layout against the new upgradeable contract structure.

Does OpenZeppelin upgrades work with Foundry or only Hardhat?

OpenZeppelin upgrades support both Hardhat and Foundry workflows, providing validation and deployment steps for upgradeable contracts across both development environments.

Why do I need to use initializers instead of constructors for upgradeable contracts?

You need initializers instead of constructors because proxy delegate calls bypass constructor execution, requiring initializer functions to safely set up the contract state during deployment.

What are the limitations when using OpenZeppelin proxy patterns for contract upgrades?

Limitations of OpenZeppelin proxy upgrades include strict storage layout constraints preventing variable reordering, inability to run constructors, and the need to carefully manage privileged upgrade roles.