
Capture details⌄
- Capture time
- Mon, 10 Aug 2026 18:02:48 GMT (claimed by device)
- Received by server
- Mon, 10 Aug 2026 18:02:54 GMT
- Location
- 40.74059, -74.00635 map (claimed by device)
- SHA-256
- ac4a0db4e8c311de249d9d50bd271c46515dfb29c78d7e09aec9a7b46043e858
- Poseidon commitment
- 21621027846243882055424117190489643391466176264522501360777927830574030317430
zkVerify verification
FINALIZED ✓- ✓Queued
- ✓Valid
- ✓Submitted
- ✓IncludedInBlock
- ✓Finalized
0xfc2fccb374f026195974e85b391c4747e4e5c67c13f18dfaeb7245ed685940ff
What this proof shows — and what it doesn't
A zero-knowledge proof, verified on the zkVerify network, shows that someone holding a one-time session secret bound this exact image (by its SHA-256 hash), the capture timestamp, the location (if shared), and a device commitment together at proving time inside the zkShot capture flow. If the image integrity check above passes, the image displayed here is byte-identical to the one committed in that proof.
It does not cryptographically prove the photo came from a physical camera sensor, nor that the timestamp or location are accurate — browsers cannot access hardware attestation, and both values are asserted by the capturing device. It also says nothing about what was in front of the camera: photographing a printed picture, another screen, or any staged scene produces an equally valid capture proof of a fake image. Treat it as evidence of an unbroken chain from the zkShot capture session, not as forensic proof of origin or authenticity.