How It Works (Users)
The user will verify once then every anchor after that will be one tap consent and user's documents will never leave the licensed provider that checked them.
This page describes how StellarProof is designed to work once built.
First Verification
1.The user connects their Stellar wallet
The credential will be tied to the user's wallet, not to an account with us. No signup, no password.
2.The user signs one message
That signature will derive the user's private credential key, local vault key and delivery key all on their device, none of them ever sent anywhere. It will also mean the credential can be recovered on a new phone from the same wallet.
3.The user proves control of the account over SEP-10
Stellar's standard web authentication. One signature, One seconds.
4.The user completes KYC with a licensed provider
The user will be routed to KYC provider, which will perform the real document and liveness check and it will keep the compliance copy under their own regulatory obligations exactly as they do today.
5.The credential is sealed to the user's wallet
Three facts: date of birth, document expiry, country will be read once in memory, committed to with a Poseidon hash, signed, encrypted to the user's key, and delivered. The plaintext will be discarded immediately. Nothing personal will be written to disk anywhere in the system.
Every Anchor After That
1.The user visits a new anchor
The anchor will open the user's wallet with the policy it needs satisfied.
2.The user sees exactly what is being asked
No surprises. The user will see every predicate, and which site will receive the proof, before approving anything.
3.The user taps to approve
A zero-knowledge proof will be generated on the user's device in 2 to 4 seconds. The credential will never leave it.
4.The anchor verifies the proof on Stellar
A Soroban contract will check the proof cryptographically and record that verification happened. The anchor will learn that the user is over 18 and in a supported country. It will learn nothing else not the user's name, not their date of birth, not their document number.
Two anchors that compare notes will not be able to tell they have seen the same person. Each one will receive a different, anchor-specific value derived from the user's secret, so it will be stable at one anchor stopping one person from opening unlimited accounts and unlinkable across anchors.