Leaf and branch encodings need an unambiguous separation.
LET’S PICTURE IT
A filing system should not confuse an original record with a pair of record fingerprints.
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.
Review the entire tree scheme
The hash function, original field encoding, leaf hashing and parent combination form one construction. A strong digest alone does not establish a safe scheme.
Inspect shared input shapes
A raw sixty-four-byte leaf can resemble the concatenation of two thirty-two-byte nodes under unsuitable conventions. Verify how the chosen library prevents that confusion.
Use compatible builder and verifier
Double-hashed leaves or explicit domain tags can be part of reviewed designs. They must be applied consistently when building the root and checking claims.
Keep claim limits separate
Even an unambiguous valid proof does not consume a claim or authenticate an arbitrary supplied root. Check root authority and repeated redemption rules too.