Merkle Tree Root and Proof Builder
Build a keccak-256 Merkle tree from a list of leaves, get the root to put on chain and a proof for any entry, with the sorted-pair convention and the duplicate-leaf pitfall explained.
Last reviewed by the Radiatus Cloud team
Need this done properly for your business?
Radiatus delivers secure cloud, DevOps & compliance engineering.
A Merkle root puts a large list on chain for 32 bytes
An allowlist of fifty thousand addresses cannot go on chain; the root of a Merkle tree built from it can, in one storage slot. A user proves membership by supplying the leaf and the sibling hashes along the path to the root, which is about seventeen hashes for fifty thousand leaves, and the contract recomputes the root and compares. The cost of verification grows with the logarithm of the list size rather than with the list, which is what makes the pattern practical at all.
Sorting each pair is what makes proofs order-independent
The widely used convention sorts the two hashes before concatenating them, so the verifier does not need to know whether a sibling was on the left or the right. That halves the information a proof must carry and is why almost every allowlist implementation uses it. The cost is that a sorted tree cannot represent position, so it cannot be used where the ordering of leaves is part of what is being proved, and mixing a sorted proof with an unsorted verifier produces failures that look random.
Duplicate leaves are the pitfall that reaches production
A list containing the same entry twice produces a tree where one proof validates two positions, which is usually harmless and occasionally is not: in an airdrop where the leaf is just an address, a duplicate lets the same proof be replayed unless the contract tracks claims separately. The related trap is a tree built by hashing a raw address rather than an encoded and typed leaf, which can allow a valid intermediate node to be presented as a leaf. Hashing the leaf twice, or including a domain separator, closes it.
Related tools
- Ethereum Unit Converter — Convert between Wei, Gwei, and Ether units.
- Gas Fee Calculator — Calculate transaction costs based on gas price and limit.
- IPFS CID Generator — Generate IPFS Content Identifiers (CID) from text or files.
- Wallet Address Validator — Validate Ethereum and Bitcoin wallet addresses.
Frequently Asked Questions
Why sort each pair of hashes?
So the verifier does not need to know whether a sibling was on the left or the right, which halves what the proof must carry. The cost is that a sorted tree cannot represent leaf position.
How large is a proof?
About log2 of the leaf count in hashes, so seventeen 32-byte hashes for fifty thousand leaves. Verification cost grows with the logarithm of the list rather than with the list.
What happens with duplicate leaves?
One proof validates both positions. In an airdrop where the leaf is only an address, that lets the same proof be replayed unless the contract tracks claims separately.
What is the second-preimage risk?
Presenting an internal node as if it were a leaf. Hashing leaves differently from internal nodes, by double hashing or a domain separator, prevents it, and it is why libraries recommend hashing the ABI-encoded leaf twice.
Does a Merkle proof keep the list private?
No. It proves one entry belongs without revealing the rest, but anyone who has the full list can rebuild the tree, and roots are often published alongside the list anyway.
Privacy & Security
Everything runs in your browser; nothing is uploaded.
How to Use
Paste your leaf values to build the tree and generate proofs.
Disclaimer: This tool is provided "as is" without warranty of any kind. Results are for educational and utility purposes.