Inherited declarations participate in the final instance layout.
LET’S PICTURE IT
A combined filing cabinet incorporates drawers inherited from earlier cabinet designs.
SEE IT FOR YOURSELF
Pack small values into Solidity storage slotsStep 1 / 4
In this simple default-layout example, two uint128 values come before one uint256. Each slot holds thirty-two bytes.
In this simple default-layout example, two uint128 values come before one uint256. Each slot holds thirty-two bytes.The first sixteen-byte value occupies the low-order half of slot zero. Low-order bytes are shown on the right.The second uint128 fits in the remaining sixteen bytes. Both values now share slot zero.C needs a complete thirty-two-byte slot, so it begins at slot one. Two packed small values plus C use two slots.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
Follow linearized ordering
Solidity derives state-variable order using inheritance linearization. Reading only the most-derived contract’s own declarations misses earlier inherited storage.
Allow compatible cross-contract packing
Under ordinary layout rules, suitable small fields from different contracts in that ordering can share one slot. Contract boundaries do not always create fresh slot boundaries.
Avoid guessing diamond inheritance
Multiple inheritance can produce an order that is not obvious from a quick visual scan. Use the actual compiled storage layout for the exact source hierarchy.
Recheck after a structural change
Changing bases or declarations can move existing fields. In upgradeable systems, such changes can reinterpret live state even when the new contract compiles successfully.
Inspect the layout
contract Base { uint128 a; }
contract Child is Base { uint128 b; }
// In this simple default layout: a and b share slot 0.
A declaration sketch; inspect compiler output for complex inheritance or custom base layouts.