Transparent Proxy Pattern and Storage Layout
Learn the Transparent Proxy pattern, how delegatecall separates logic from storage, and the storage layout rules you must follow to upgrade contracts safely.
Transparent Proxy Pattern and Storage Layout is a free Blockchain Smart Contracts with Solidity lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Blockchain Smart Contracts with Solidity learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
Recap: Why Proxies
You have seen UUPS and the Diamond standard. Both rely on a foundational idea: a proxy holds the storage and forwards calls to a separate logic (implementation) contract. Upgrading means pointing the proxy at new logic.
How delegatecall Works
The magic behind proxies is delegatecall. It runs the logic contract's code but in the proxy's storage context, using the proxy's msg.sender and balance.
So storage lives in the proxy; behavior lives in the implementation.
A Minimal Proxy Fallback
A proxy forwards every unknown call to the implementation using assembly delegatecall in its fallback.
fallback() external payable {
address impl = _implementation();
assembly {
calldatacopy(0, 0, calldatasize())
let ok := delegatecall(gas(), impl, 0, calldatasize(), 0, 0)
returndatacopy(0, 0, returndatasize())
switch ok
case 0 { revert(0, returndatasize()) }
default { return(0, returndatasize()) }
}
}The Function Clash Problem
If the proxy itself has an upgradeTo function and the logic also has a function with the same selector, calls become ambiguous. The Transparent Proxy pattern solves this by routing based on the caller.
Admin vs User Routing
In a Transparent Proxy, the admin address can call admin functions (like upgrade) but cannot reach the implementation. Everyone else is always forwarded to the implementation. This removes clashes.
modifier ifAdmin() {
if (msg.sender == _admin()) {
_;
} else {
_fallback();
}
}Storage Slot Collisions
Both proxy and logic write to the same storage. If they used slot 0 for different variables, they would corrupt each other. Proxies store admin and implementation at fixed pseudo-random slots (EIP-1967) to avoid collisions.
// EIP-1967 implementation slot
bytes32 internal constant _IMPL_SLOT =
0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;Reading the Implementation Slot
The proxy reads and writes that fixed slot directly with assembly so it never collides with logic variables.
function _implementation() internal view returns (address impl) {
bytes32 slot = _IMPL_SLOT;
assembly { impl := sload(slot) }
}Storage Layout Rules
When upgrading the logic you must preserve the order and types of existing storage variables. New variables go at the end.
- Never reorder existing variables
- Never change a variable's type
- Never insert a new variable before old ones
Storage Gaps
Inheritable base contracts reserve space for future variables with a __gap array so child contracts do not collide after an upgrade adds fields to the base.
contract Base {
uint256 public value;
// reserve 50 slots for future use
uint256[50] private __gap;
}Initializers Not Constructors
Constructors run only on the logic contract's own deployment, not through the proxy. Upgradeable contracts use an initialize function guarded so it runs exactly once.
bool private _initialized;
function initialize(uint256 v) external {
require(!_initialized, 'already init');
_initialized = true;
value = v;
}Transparent vs UUPS
Transparent proxies put the upgrade logic in the proxy (more deployment gas, simpler logic). UUPS puts it in the implementation (cheaper proxy, but you must include upgrade code in every version). Choose based on cost and team discipline.
Quick Check
Test your understanding of proxy storage.
Recap
You learned the Transparent Proxy pattern:
delegatecallruns logic in the proxy's storage- Admin-vs-user routing avoids function clashes
- EIP-1967 fixed slots and
__gaparrays prevent collisions - Use
initialize, preserve storage layout, append new variables
Follow these rules and upgrades stay safe.
Frequently asked questions
Is the “Transparent Proxy Pattern and Storage Layout” lesson free?
Yes — the full text of “Transparent Proxy Pattern and Storage Layout” is free to read here on the web, and the Blockchain Smart Contracts with Solidity course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Blockchain Smart Contracts with Solidity course, upgrade to CoddyKit PRO.
What will I learn in “Transparent Proxy Pattern and Storage Layout”?
Learn the Transparent Proxy pattern, how delegatecall separates logic from storage, and the storage layout rules you must follow to upgrade contracts safely. You practise Blockchain Smart Contracts with Solidity with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start Blockchain Smart Contracts with Solidity?
No prior experience is required. Blockchain Smart Contracts with Solidity on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Transparent Proxy Pattern and Storage Layout” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this Blockchain Smart Contracts with Solidity lesson?
Yes. Every Blockchain Smart Contracts with Solidity lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Why Upgradeable Contracts?
- UUPS Proxy Pattern Implementation
- Diamond Standard (Multi-facet Proxies)
- Transparent Proxy Pattern and Storage Layout