Outcome reports are filed separately from the original requests and the final ledger.
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.
Separate the receipt collection
A receipt root commits to the block’s receipts under the specified encoding and indexed trie rules. It differs from the state and transaction roots.
Connect logs to a receipt
Surviving logs are encoded within receipts. A complete inclusion argument must connect the relevant log to a receipt and that receipt to the accepted block commitment.
Use the correct transaction type framing
Receipt encodings can depend on transaction type conventions. Treating every receipt as one untyped historical byte format can give incorrect verification.
Do not infer finality from a local proof
A valid proof establishes consistency with a particular root. Accepted chain context and finality remain additional requirements when making real-world inclusion claims.