Proof Holdings vs Stytch

Stytch runs your authentication: it logs users in, issues and manages sessions, stores the user record, and orchestrates MFA, SSO, RBAC and fraud signals. You adopt Stytch as the front door to your app.

Proof Holdings works at the moment of trust: a person proves control of a specific asset — a phone, an email, a domain (wallet and social coming soon) — and you get a signed ES256 token you can hand to anyone. You can build login on that — passwordless, and account-less if you want, since the asset control is the credential (Proof runs its own login and 2FA this way) — but there's no user directory, session manager, or SSO to operate.

They overlap on the passwordless moment and diverge on scope. If you need a full login system — a stored user directory, sessions, SSO, RBAC — that's Stytch. If you want passwordless login *without* a user database, or to *prove control of an asset* and hand that proof to a third party — often for someone who will never have an account in your system — that's Proof.

Both are passwordless — the business stores no password to breach and the user remembers none. The difference is what you get back.

Stytch returns a session bound to your application. Proof returns a proof token: an ES256 attestation that a specific asset was verified at a specific time, portable to any third party and verifiable offline with a public key. A session says "this user is logged in right now." A proof token says "this person controls this domain" — and stays true after the session ends.

Proof's phone verification also uses Reverse OTP: the user sends a code to the service (via Telegram, WhatsApp or SMS) instead of receiving one. That sidesteps SMS delivery failure and SIM-swap interception entirely — a channel Stytch (and every server-initiated-OTP platform) doesn't offer.