How proofs work
Every Kist proof is a chain of cryptographic commitments: a device signature, a content hash, and an on-chain record binding them together under your client id.
The proof pipeline
01CaptureThe app captures media and computes its SHA-256 hash locally.
02SignThe device signs the hash with its Ed25519 private key. The key never leaves the device.
03VerifyThe relayer verifies the signature against the device's enrolled public key.
04AnchorA Solana program stores the hash, signature, device, timestamp, and client id.
05Verify againAnyone can read the record from Solana and compare hashes.
What is stored on-chain
| Field | Meaning |
|---|---|
| imageHash | SHA-256 of the captured content |
| signature | Ed25519 signature over the hash, by the device |
| devicePubkey | The device's enrolled public key |
| captureTimestamp | When the media was captured on the device |
| clientId | The organization that owns the proof |
| metadataUri | Optional pointer to off-chain metadata (e.g. IPFS) |
Trust model
Kist never needs to be trusted. The relayer is a convenience that submits transactions and pays fees; the verdict always comes from reading Solana. If Kist disappeared, the proofs would remain and verification would still work.
Idempotent by design
Re-anchoring the same image hash for the same client returns the existing record — you never pay twice for one proof.
Device identity
A device is identified by the SHA-256 of its public key. Devices are enrolled once with POST /devices/enroll, which also registers the key on-chain, so every proof that follows can be attributed to a real, bound device.