Storage Packing

Storage packing is a smart contract development technique that minimizes gas costs by strategically arranging multiple, smaller state variables to occupy a single 32-byte storage slot. On the Ethereum Virtual Machine (EVM), reading from or writing to a storage slot has a fixed, high gas cost, regardless of how much of the 32-byte word is used. By packing related data—such as multiple uint8 booleans, small integers, or packed structs—into one slot, developers can drastically reduce the number of expensive SSTORE and SLOAD operations. This is a fundamental optimization for contracts where gas efficiency is critical, such as in DeFi protocols or NFT collections.

The technique relies on understanding EVM storage layout and bitwise operations. Variables are declared contiguously in the contract, and the Solidity compiler will automatically pack them into a single slot if they fit within 32 bytes. For example, a uint128, a uint64, and two uint32 variables can be packed together. Developers often use explicit bitmasking with operators like & (AND) and | (OR) to encode and decode packed data within a slot. This manual control is essential for non-standard packing or when interacting with already-deployed contracts using inline assembly via yul.

Consider a practical example: an NFT contract tracking staking status. Instead of using a full bool (which uses an entire slot) for each token's staked state, a developer can pack 256 boolean flags into a single uint256 variable, using each bit to represent a token ID. Reading or updating the status for any token then only requires accessing that one storage slot and performing a bitwise operation, rather than performing a storage operation for each individual token. This pattern is common in highly optimized contracts like Uniswap v3, which uses bit-packed Slot0 to store multiple fee and tick parameters.

While powerful, storage packing introduces trade-offs. It increases code complexity and can make contracts harder to audit and maintain. Reading a packed value requires extra computation (bit shifting and masking) off-chain, though this cost is negligible compared to on-chain storage operations. It's also incompatible with some data types; dynamic arrays and mappings cannot be packed, and elements within structs only pack if they are stored in storage, not memory. Effective packing requires careful planning during the contract design phase, as the storage layout is immutable after deployment.

The optimization is closely related to other gas-saving strategies like using immutable and constant variables, minimizing storage writes, and employing transient storage (EIP-1153). As a core technique in the Ethereum gas golfing playbook, mastery of storage packing is a key differentiator for developers building high-performance, cost-effective smart contracts. Its principles also apply to other EVM-compatible chains like Arbitrum, Polygon, and Base, where reducing L1 data publication costs or L2 execution fees is equally vital.

Storage packing is the process of efficiently storing multiple, smaller state variables within a single 256-bit storage slot on the Ethereum blockchain to minimize gas costs. Each storage operation on the EVM, whether reading or writing, incurs a gas fee based on the slot accessed. By packing related data—such as multiple uint8, bool, or address types—into one slot, developers drastically reduce the number of expensive SSTORE and SLOAD operations. This optimization is essential for contracts where gas efficiency is paramount, directly lowering transaction costs for users.

The mechanism relies on the EVM's fixed 256-bit (32-byte) slot size. For example, a uint8 uses only 8 bits of data but would occupy an entire slot if declared alone, wasting 248 bits. Through careful struct design and variable ordering, a developer can declare variables like uint64 a, uint64 b, uint64 c, and uint64 d sequentially; the Solidity compiler will automatically pack them into one slot because their combined size (256 bits) fits perfectly. Manual bitwise operations using & (AND), | (OR), and bit-shifting are required for more complex packing or when accessing packed data within assembly blocks.

Effective packing requires understanding storage layout rules. In Solidity, variables are packed contiguously within a slot starting from the least significant bits, and a new slot is started only when the remaining space is insufficient. However, packing is disabled for variables within structs and arrays that are stored in memory or calldata, and it does not cross word boundaries (256-bit slots). A common practice is to group smaller, frequently accessed variables together in a single struct to ensure they are packed, while isolating larger types like uint256 or string into their own slots.

Consider a contract managing user flags: storing a bool isActive, uint8 tier, and uint64 lastUpdated separately would consume three slots and over 60,000 gas for initial writes. Packed into a struct {uint64 lastUpdated; uint8 tier; bool isActive;}, they occupy one slot, as the total size is less than 256 bits. This single-slot write costs 20,000 gas, saving roughly 66%.* This demonstrates why storage packing is a fundamental skill for writing cost-effective smart contracts, especially in high-throughput applications like DeFi protocols and NFT minting.

In the Ethereum Virtual Machine (EVM), a storage slot is a 256-bit (32-byte) unit of persistent data. Reading from or writing to storage is one of the most expensive operations in terms of gas. Storage packing works by declaring multiple, smaller contiguous state variables (like uint8, uint16, bool) so the EVM can pack them into a single slot, provided their combined size does not exceed 256 bits. For example, two uint128 variables can be packed into one slot, but a uint256 will always occupy an entire slot by itself. This technique directly reduces the gas costs for contract deployment and state-modifying transactions.

The packing order is determined by the declaration order of variables within a contract. The EVM packs variables from right to left within a slot, starting with the first variable in the slot. It's crucial to group variables that are read or updated together, as unpacking a value from a packed slot still incurs a computational cost. A common pitfall is leaving storage gaps—unused bits within a slot—by not ordering variables efficiently. Developers must also be aware that elements of arrays and mappings always occupy their own full storage slots and cannot be packed with other variables.

Consider this optimized struct: struct Packed { uint64 a; uint64 b; uint128 c; }. All three members fit into one 256-bit slot (64+64+128 bits). In contrast, struct Inefficient { uint128 a; uint256 b; uint64 c; } would use three slots because the uint256 b forces a new slot, and uint64 c is placed into a new slot as it cannot fit into the remainder of the previous one. Using the pragma abicoder v2 and uint types with explicit bit sizes is essential for effective packing. This optimization is a fundamental skill for writing gas-efficient smart contracts.