A contract can check membership without storing every entry individually.
LET’S PICTURE IT
A short official roster fingerprint can validate a supplied membership path.
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.
Encode the authorization fields
A leaf might bind an account and allowed quantity. If quantity is security-relevant, it must be included under the chosen encoding rather than trusted as an unsigned extra field.
Check the stored root
The contract compares the reconstructed root with its authorized root. The caller should not be free to supply any root and call that sufficient authorization.
Control repeated claims
Membership does not automatically mark a claim used. Track claim consumption or remaining allocation where the protocol requires limited redemption.
Review root administration
A root update can replace the effective roster. Document update authority, timing and the effect on earlier claims or cached proofs.
Follow the proof model
leaf fields: account + allowed amount
verify proof against authorized root
check unused allocation
consume claim and apply the action consistently
Binary examples use the stated local playground convention. They are not Ethereum account or storage trie proofs.