InvalidRevealCommitHashNotMatch
Error Re-added v151 → v202, v205 → v212, v216 → v216, v217 → v219, v233 → v315, v320 → v326, v334 → current 7.51The revealed weights don't match the committed hash.
Why This Error Exists
Commit-reveal integrity depends on the reveal matching the commit exactly. This error means your revealed (weights, salt) combination doesn't hash to what you originally committed. Either you changed your weights, lost your salt, or there's a bug in your hash computation. The whole point is you can't change your mind after committing.
Deep Dive
The commit hash is computed as keccak256(SCALE_encode(weights) || salt). On reveal, the chain recomputes this hash and compares to the stored commitment. Even a single bit difference causes mismatch. Common issues: 1) Different UID ordering, 2) Different weight values, 3) Wrong salt, 4) Different encoding (JSON vs SCALE).
Debugging Example
You committed hash=0xabc123... for weights=[100,200,300] with salt=42. You reveal with weights=[100,200,301], salt=42. Error: InvalidRevealCommitHashNotMatch. Weight at index 2 changed (300->301). Solution: Either reveal the ORIGINAL weights [100,200,300], or make a new commit with your new weights.
Prevention Tips
- Store your exact weights AND salt immediately after committing
- Use the same serialization code for commit and reveal
- Never modify weights between commit and reveal - if needed, commit again
From Chain Metadata
Committed hash does not equal the hashed reveal data.
What This Means
The revealed weights don't match the committed hash.
Common Causes
- Weights changed between commit and reveal
- Wrong salt or nonce used
- Hash calculation error
How to Fix
- Ensure reveal data exactly matches what was committed
- Use the same weights, salt, and nonce from commit
- Regenerate commit if weights need to change
Storage to Check
Thrown By
Version History
Runtime Info
- Pallet Index
- 7
- Error Index
- 51
- Error Code
- 7.51
- Runtime Version
- v393