Open ux-design-dev opened 2 years ago
Transaction hash: 0x17cb36e3abfe5cd2894f7b324102c3864d202bc7b85e4f3e5ec78ca2c3db79d7
✅⌚Witness event verification hash has been verified on goerli via etherscan.io
✅🌿Witness Merkle Proof is OK
✅🔏 Valid signature from wallet: 0xhurrdurrimasheep
✅Is a Domain Snapshot, hence not part of Merkle Proof
✅📄 File content hash matches (990d929a9ca19e1803366c0137a726f37e153782df0329a861d4591f5146f21487b61d3d3d69ef920bc57fd931b865a2ca803e9299f46f7fabee2e8c545774b8)
❌verification hash doesn't match ('verification' should be capitalized; this is a mistake in the code) ❌⌚Witness event verification hash does not match on goerli via etherscan.io ❌Witness event verification hash doesn't match ❌🌿Witness Merkle Proof is corrupted
❌📄 Invalid file content hash
❌🔏Invalid signature
The long hash is always converted to <first 6>...<last 6>, that can be clicked to copy the hash to clipboard. I was copying the output from the CLI verifier, and hence the full hash.
To recap and combine all of the states above into accurate groups, here is my understanding:
File
990d92....5774b8
Signature
Witness
Other
The verification hash is like the "Merkle root" to summarize the result, and so should be in its own classification.
To create a list of all the various event state seen in the Verifier
:heavy_check_mark: Verification hash matches
...@FantasticoFox @rht