Connect a slot claim through the account’s committed storage root.
LET’S PICTURE IT
A certified cabinet record can point to a second certified drawer index.
SEE IT FOR YOURSELF
Build a root and follow one membership proofStep 1 / 4
This example hashes UTF-8 A, B, C and D. The displayed hashes are abbreviated, and the tree uses the playground’s sorted-pair convention.
This example hashes UTF-8 A, B, C and D. The displayed hashes are abbreviated, and the tree uses the playground’s sorted-pair convention.Each pair of raw child hashes is sorted, concatenated and hashed. The resulting parent fingerprints commit to their children.Hash the two parents under the same rule to obtain one root commitment. Changing a leaf changes the hashes on its path.The highlighted siblings are B and hash(C,D). Starting with A, the verifier recomputes its path and compares the final result with a trusted root.
Animated local teaching model. No wallet, RPC or live blockchain data. Some labels and hashes are abbreviated for readability.
Calculate the intended slot
A Solidity variable name is not itself a trie key. Determine its actual slot using the compiler layout and mapping or array derivation where needed.
Verify the account layer
Establish the account record against an accepted state root. Its storage root supplies the commitment used for the next proof layer.
Verify the storage key rules
The storage trie uses its specified key preprocessing and value encoding. Do not assume a raw slot number can be inserted directly into a generic binary tree verifier.
Decode the resulting word
A verified slot value still needs the layout’s type and packed offsets. Proving one word does not automatically prove an entire multi-slot struct or application invariant.
Follow the proof model
layout → slot location
account proof → accepted storage root
storage proof → slot value
field layout → interpreted value
Binary examples use the stated local playground convention. They are not Ethereum account or storage trie proofs.