From your phone to a yes-or-no answer
Five steps carry you from a tap on your phone to a yes-or-no answer anyone can check. At every step we label what each party sees, what it signs, and — the part a security reviewer cares about — which claims are cryptographically proven and which are operator-asserted.
As you scroll, each step of the trust flow reveals in turn. The diagram stays pinned so you never lose your place.
Reduced motion is on, so nothing animates — every step below is shown at once, each labelled in words with its number, party, what it sees, what it signs, and whether it is cryptographically proven or operator-asserted.
Step 1 of 5 — Your phone
Mint a biometric-gated key
cryptographically proven- Sees
- Your biometric and the new private key — the only place either one ever exists.
- Signs
- Mints a keypair inside the Secure Enclave / StrongBox, unlockable only by your biometric. Nothing leaves the device.
Step 2 of 5 — Your phone
Platform TEE attestation
cryptographically proven- Sees
- The public key and the platform (Apple / Android) attestation for it.
- Signs
- The secure hardware attests that the key was minted in a genuine TEE. The private half never surfaces.
Step 3 of 5 — Your phone
Generate the zero-knowledge proof
cryptographically proven- Sees
- The private key, used locally. Nothing secret leaves the device.
- Signs
- A P-256 zero-knowledge proof of key possession, generated on the phone. The biometric never leaves it.
Step 4 of 5 — Verity server
Validate attestation, relay the proof
operator-asserted- Sees
- The attestation, the public key, and the finished proof — never the biometric. Relay-only on the proof path.
- Signs
- Signs an operator issuer attestation and relays the phone-made proof onward. It cannot forge the proof, but its own signature is operator-asserted, not proven.
Step 5 of 5 — StarkNet
The chain answers is_human(address)
cryptographically proven- Sees
- The relayed proof and the issuer attestation.
- Signs
- Records the result so anyone can read is_human(address). By design this is device-key proven; in the hosted build it is operator-relayed (see below).
Proven vs operator-asserted
Some claims are proven by a zero-knowledge proof; others are operator-signed and labelled as such. We never flatten the two.
- cryptographically proven(solid line)
- A device-key zero-knowledge proof. Anyone can check it — no need to trust Verity, and no operator signature stands between you and the fact.
- operator-asserted(dashed line)
- Backed by Verity's operator signature, not a proof. You are trusting the operator key. We label it as such rather than flattening it into the proven claims.
What’s real vs demo in this build
This is a proof of concept. Here is exactly what is real, shipping code and what is a demo stand-in in the hosted build — labelled, not buried.
- real code
On-phone proof generation
The biometric-gated key mint and the P-256 zero-knowledge proof are real, shipping code — by design the proof is cryptographically proven and the biometric never leaves the phone.
- mock
The hosted demo
The live deploy runs the chain and prover in mock mode (chain_mode=mock, prover_mode=mock) and relays over the network — it exercises the real end-to-end flow without a live StarkNet write.
- operator-relayed
is_human(address) on-chain
In this build is_human is operator-relayed and operator-asserted: the chain trusts the operator issuer key, not the device key. A live-chain, device-key-bound read is a v1.5 track.
- demo-only
Liveness / anti-spoof tier
The face-liveness verdict is decided on-device and is demo-only — forgeable on a compromised client. The signed tier makes that legible, not prevented (operator-asserted, not proven).
Attribution, not authentication. Some claims are proven by a zero-knowledge proof; others are operator-signed and labelled as such. We never flatten the two.