In this track: Storage, memory and layout
Namespaced storage explained
Modules can derive separate roots for structured state.
Different departments can use distinct cabinet sections with documented labels.
In this simple default-layout example, two uint128 values come before one uint256. Each slot holds thirty-two bytes.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
Define a namespace identifier
A namespaced design assigns a root to a logical group of fields. The fields then follow layout rules within that group instead of sharing one undifferentiated sequential list.
Use a specified derivation
ERC-7201 documents a namespace annotation and a particular root formula. A random hash chosen without the convention is not automatically an ERC-7201 namespace.
Preserve each namespace layout
Separate roots reduce some cross-module collision risks, but fields inside one namespace still need compatible evolution. Reordering existing members can remain unsafe.
Verify tools and actual code
A source annotation documents intent; it does not itself make every assembly storage access correct. Inspect the root calculation, compiler context and real field access paths.
Inspect the layout
@custom:storage-location erc7201:example.learning
The annotation names the intended convention.
Use the exact ERC-7201 root formula and review the access implementation.This is a documentation sketch rather than a complete namespace implementation.
Does namespacing make arbitrary field reordering safe?
Compatibility still matters inside each namespace.
Original explanations by EtherTools. Examples are educational and source-linked; this site is independent of the Ethereum Foundation. Our approach.