L1
Anchored integrity
The verifier hashes the original media bytes locally, then reads the finalized TrustEye event from Solana. The index can help find the transaction, but the chain event is the authoritative record.
Trust no one. Verify the proof.
TrustEye is designed so a verifier does not have to trust the sender, the index service, or TrustEye as an authority. The verdict comes from the original bytes, the public chain event, device signatures, and platform attestation.
Authority Model
The index discovers. The verifier decides.
TrustEye runs an index so people can find proofs by file hash quickly. That index is never treated as final evidence. A valid verdict still requires reading the public chain event and checking the cryptography locally.
Local file
SHA-256
Public chain
Solana event
Device proof
P-256 + attestation
Three Layers
A TrustEye verdict is layered, not vibes.
L2
Device signed
The capture device signs the content hash or video window with a hardware-backed P-256 key. The verifier checks that signature locally against the device key published in the chain event.
L3
Platform attested
Android captures verify a Google-rooted Key Attestation chain for the TrustEye Play package. iOS follows the same principle with Apple App Attest: prove the signing key belongs to a genuine app/device path.
Verification Protocol
What the verifier actually does.
The public website and mobile apps follow the same rule: the media file being checked is the input. Everything else must be rediscovered and revalidated from public or self-verifying evidence.
Open verifierStep 1
Hash the original bytes
The image or video is read in the verifier. For photos, the SHA-256 is computed in the browser or app; for video, windows and surviving chunks are checked against the anchored timeline.
Step 2
Use the index only for discovery
The index maps a hash to candidate transaction metadata. It is useful infrastructure, not a source of truth. A dishonest or stale index cannot make a bad proof pass.
Step 3
Read the public chain event
The verifier fetches the finalized TrustEye Solana event and checks the program, slot, capture id, batch/window data, content hashes, and device keys.
Step 4
Check signatures and attestation
Device signatures are verified locally. Android Key B is checked against a Google-rooted certificate chain and an assertion bound to the exact on-chain batch.
Proof Anatomy
What the technical proof panel is showing you.
A verified result is not a single green check from a server. It is a set of independently checked facts that all have to agree.
Example Verdict
Genuine TrustEye capture
File → content hashpass
Finalized TrustEye Solana eventpass
Device signature using on-chain Key Apass
Android hardware attestation using Key Bpass
Batch assertion bound to exact photo setpass
Local
Content SHA-256
f9e667f5…a7f6fc
Computed from the original file bytes in the verifier. If one byte changes, this fingerprint changes.
On-chain
Capture ID
relay:pAJoc…
The capture identifier read from the finalized TrustEye event. It lets the verifier bind this file to the exact batch or video window.
Device
Device key
pv-device-v1-05ea…
The public capture key published in the chain event. It verifies the media signature without exposing any private key.
Public chain
Anchor transaction
Solana mainnet · paJo…
The public transaction containing the TrustEye event. Anyone can fetch it independently from Solana.
L2
Device signature
ECDSA-P256 · pass
Checked locally over the file hash using the device key from the chain event.
L3
Platform attestation
Android Key B · pass
Checks that the app/device path is genuine and that the attestation assertion authorizes this exact batch.
Platform Binding
Android and iOS map to the same canonical proof idea.
Android
- Key A signs media hashes and video windows.
- Key B is Android Key Attestation evidence rooted in Google hardware roots.
- The batch assertion binds Key B to the exact on-chain photo batch.
- The verifier checks package id io.trusteye.app and fails closed on mismatch.
iOS
- The same canonical capture and proof records are used by the SDK.
- The device signing key is bound to Apple platform evidence.
- Verification keeps the same three-layer model: chain, device signature, platform assertion.
- The user experience stays aligned: capture first, proof in the background.
What a verified result means
The original bytes match an on-chain TrustEye capture record, the device signature is valid, and available platform attestation confirms the capture path.
What TrustEye does not claim
It does not prove the scene is morally complete, that a caption is true, or that a screenshot/export/re-encoded share is the original. It proves byte integrity and capture provenance.
How verification fails
If the file is missing from the chain record, the signature does not match, the chain event cannot be verified, or attestation fails, TrustEye fails closed instead of guessing.