Some standard tree formats hash encoded leaves twice.
LET’S PICTURE IT
A separate envelope layer distinguishes a record fingerprint from a branch combination.
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.
Recognize the specific convention
Some common allowlist libraries use Keccak-256 of a first leaf digest. Their verifier expects that same double-hashed leaf construction.
Understand the separation goal
Separating leaf representation from internal-node inputs helps avoid a raw leaf being interpreted like a concatenated pair of child hashes under unsuitable constructions.
Do not change one side only
Adding a second hash to an existing verifier while keeping the old tree root will generally break compatibility. Builder, root and verifier must agree.
Keep the playground convention explicit
This site’s text playground hashes each text leaf once and is an educational model. It does not claim to generate every library’s standard allowlist tree.
Follow the proof model
Example convention: leaf = H(H(standard encoded fields))
Playground convention: leaf = H(UTF-8 text)
These produce different trees.
Binary examples use the stated local playground convention. They are not Ethereum account or storage trie proofs.