Solidity Internal Storage Layout: Slots, Packed Variables & Transient Storage (EIP-1153)

Variable Packing Mechanics & Right-to-Left Slot Alignment

When state variables are smaller than 32 bytes (such as uint128, uint64, uint8, address (20 bytes), or bool (1 byte)), the Solidity compiler attempts to pack multiple adjacent variables into a single 32-byte storage slot.

Rules of Variable Packing:

1. Contiguous Packing: Multiple variables are packed into the same slot only if they are declared consecutively and their combined byte length does not exceed 32 bytes.
2. Little-Endian / Right-Aligned Packing: Within a single 32-byte slot, the first declared variable occupies the lowest-order bytes (the rightmost bits). Subsequent variables are packed to the left.
3. Word Boundary Alignment: If adding the next variable would exceed 32 bytes, that variable is not split across slot boundaries; instead, the compiler advances to the next clean 32-byte slot, leaving the remaining bytes in the previous slot empty and wasted.

Consider the following contrast in struct variable ordering:

Unoptimized Layout (Consumes 3 Slots = 96 Bytes):

• uint128 a; (Slot 0, 16 bytes used, 16 bytes empty)
• uint256 b; (Slot 1, cannot fit in Slot 0, occupies full 32 bytes)
• uint128 c; (Slot 2, occupies 16 bytes)

Optimized Layout (Consumes 2 Slots = 64 Bytes):

• uint128 a; (Slot 0, bytes 0..15)
• uint128 c; (Slot 0, bytes 16..31 - perfectly packed!)
• uint256 b; (Slot 1, bytes 0..31)

By reordering variables, the contract saves one full SLOAD/SSTORE slot, reducing deployment costs by 20,000 gas and every subsequent state update by thousands of execution gas.

Storage Math: Calculating Locations for Mappings, Dynamic Arrays & Strings

Because dynamic data structures (mappings, dynamic arrays, and strings) have unbounded lengths, they cannot be stored in simple sequential slots without causing slot collision with subsequent state variables.

Solidity resolves this using cryptographic Keccak-256 hash formulas:

1. Mappings:

If a mapping mapping(keyType => valueType) public myMap; is declared at slot $p$:

• The slot $p$ itself remains completely empty (stores zero).
• The storage slot location for a specific key $k$ is calculated as:

$$\text{Slot}(k)=\text{keccak256}(h(k)\mathrm{\parallel }\text{p32}(p))$$

where $h(k)$ is the key padded to 32 bytes, $\text{p32}(p)$ is the slot index $p$ padded to 32 bytes, and $\mathrm{\parallel }$ represents binary concatenation.

• For nested mappings mapping(k1 => mapping(k2 => v)) at slot $p$:

$$\text{Slot}(k_1,k_2)=\text{keccak256}(h(k_2)\mathrm{\parallel }\text{keccak256}(h(k_1)\mathrm{\parallel }\text{p32}(p)))$$

1. Dynamic Arrays:

If a dynamic array uint256[] public myArray; is declared at slot $p$:

• The slot $p$ stores the length of the array ($N$).
• The array elements are stored contiguously starting at base location:

$$\text{BaseSlot}=\text{keccak256}(\text{p32}(p))$$

• The $i$-th element is located at: $\text{Slot}(i)=\text{BaseSlot}+i\times \text{elementSizeSlots}$.

1. Short Strings and Bytes (< 32 bytes):

If a string or bytes is 31 bytes or shorter, Solidity utilizes Short String Optimization: the raw string characters are stored directly in the higher-order bytes of slot $p$, while the lowest byte (byte 31) stores $2\times \text{length}$. If the string is $\ge 32$ bytes, slot $p$ stores $2\times \text{length}+1$, and the actual string data is stored at $\text{keccak256}(p)$.

Yul Inline Assembly for Direct Bit-Level Storage Manipulation

When reading or writing packed variables in high-performance protocols (such as Uniswap v4 pool managers or Yearn vaults), developers use Yul inline assembly to avoid compiler-generated redundant masking and achieve maximum gas efficiency.

In Yul assembly:

• SLOAD: Loads a 32-byte word from storage: let value := sload(slot).
• SSTORE: Stores a 32-byte word into storage: sstore(slot, value).
• Bit-Shift & Masking: To extract packed variables from a slot, developers use bit-shift right (shr) and bitwise AND (and) operations.

Consider reading a packed uint64 variable located at byte offset 20 (bit offset 160) inside a 32-byte slot: The assembly executes let slotData := sload(0), shifts right by 160 bits (let shifted := shr(160, slotData)), and masks with 0xFFFFFFFFFFFFFFFF (let uint64Val := and(shifted, 0xffffffffffffffff)).

Direct Yul storage manipulation eliminates Solidity's automatic boundary checks and redundant memory allocations, reducing execution gas by up to 30% in tight computational loops.

Transient Storage (EIP-1153): TLOAD, TSTORE & 100-Gas Reentrancy Guards

Introduced in the Ethereum Cancun upgrade (March 2024), EIP-1153 introduced Transient Storage to the EVM via two new opcodes:

• TSTORE (Opcode 0x5D): Stores a 32-byte word in transient storage for 100 gas.
• TLOAD (Opcode 0x5C): Loads a 32-byte word from transient storage for 100 gas.

Transient storage possesses unique operational characteristics:

• Scope: Behaves exactly like storage (accessible across multiple smart contract calls within the same transaction), but is completely discarded and wiped to zero at the end of the transaction execution.
• No Disk I/O: Because transient data is never written to the Ethereum state trie on disk, it requires zero Merkle trie recomputation, explaining its flat 100 gas cost.

The most transformative application of Transient Storage is the Zero-Overhead Reentrancy Guard. Historically, OpenZeppelin's ReentrancyGuard used persistent storage (SSTORE), costing ~2,200 to 5,000 gas per protected function call to set a non-reentrant lock and clear it.

With EIP-1153 transient storage, setting and clearing a reentrancy lock costs exactly $200$ gas ($100$ gas TSTORE(lockSlot, 1) + $100$ gas TSTORE(lockSlot, 0)), a $95\mathrm{\%}$ gas reduction that fundamentally optimizes all modern DeFi protocols.

Storage Collision Vulnerabilities in Upgradeable Proxy Contracts

The deterministic slot layout of the EVM introduces severe security hazards when building Upgradeable Proxy Contracts (such as ERC-1967, UUPS, and Transparent Proxies).

In a proxy pattern:

• The Proxy Contract holds all persistent state in its own storage slots.
• The Implementation Contract contains the execution logic, executed via delegatecall.

Storage Collision occurs when the new implementation contract modifies the variable declaration order, removes an existing variable, or inserts a new variable before existing ones:

• If Implementation V1 has address owner at Slot 0 and uint256 balance at Slot 1.
• Implementation V2 inserts bool isPaused at the top (Slot 0).
• When V2 reads isPaused, it will read the lowest byte of the original owner address. When V2 updates owner, it overwrites balance at Slot 1!

To eliminate storage collisions permanently:

1. ERC-7201 Namespaced Storage: Instead of starting variables at Slot 0, contracts allocate isolated storage structs at deterministic hash slots:

$$\text{Slot}=\text{keccak256}(\text{keccak256}(\text{namespaceId})-1)\mathrm{\&}\sim 0xff$$

1. Storage Gap Arrays: Including uint256[50] private __gap; reserved slots at the end of base contracts to allow future state expansion without shifting downstream child contract storage slots.

## Frequently asked questions

Why does Solidity pack variables from right to left inside a 32-byte slot?

Solidity uses little-endian byte ordering within words, placing the first declared variable in the lowest-order (rightmost) byte positions of the 32-byte EVM storage word.

How much gas does EIP-1153 Transient Storage save compared to persistent storage for reentrancy locks?

Transient storage costs 100 gas for TLOAD and 100 gas for TSTORE (200 gas total per call), compared to 2,200 to 5,000 gas for traditional SSTORE-based reentrancy guards—a 90% to 95% gas saving.

What happens to transient storage variables at the end of a transaction?

All transient storage slots are completely wiped to zero at the end of the transaction and cannot be accessed by future transactions.

Related reading

• Transient storage reentrancy guards vs standard SLOAD guards — See how EIP-1153 eliminates reentrancy vulnerabilities while saving 95% in gas fees.

## Sources

• Layout of State Variables in Storage — Solidity docs
• EIP-1153: Transient storage opcodes — Ethereum Improvement Proposals

No contributor to this article holds a professional cryptography or security credential. Every technical claim above is sourced to primary protocol documentation rather than to personal authority — follow the sources and verify anything you intend to act on.

Not financial advice. Crypto assets are volatile and can lose value. This article describes how protocols work, not what you should buy.