Sigma Auth vs Clerk
Clerk is a managed authentication service with an unusually good component library. Sigma Auth is key based and adds BSV wallet standards. The right choice depends on which constraint matters.
Choose Clerk if
- You want working authentication this afternoon, with prebuilt components
- Email, social, and passkey logins cover your users completely
- You need organizations, invitations, and member roles as shipped features
- A managed vendor relationship suits your compliance story
Choose Sigma Auth if
- Users should hold their own keys rather than a credential in a vendor database
- Entitlement should follow an asset a user holds, not a row you maintain
- Your application needs BSV wallet authentication standards
Feature comparison
| Clerk | Sigma Auth | |
|---|---|---|
| Hosting | SaaS only | Hosted |
| License | Proprietary | Repository not public |
| Pricing model | Plans and graduated pricing based on monthly retained users | Hosted access has no active quota today. A $99 per month Team tier is proposed |
Where Clerk is strong
Pretending otherwise would make the rest of this page less useful to you.
The fastest route to a working login
Drop in a component, get a styled and accessible flow the same day. If time to first login is your binding constraint, Clerk wins that outright and it is not close.
B2B primitives are already built
Organisations, invitations, roles, and member management arrive as shipped features rather than as something you assemble and then own forever.
Login methods people already recognize
Email codes, social providers, and passkeys need no explanation. A key based flow needs one, at least the first time a user meets it.
Somebody else carries the pager
Uptime, patching, abuse handling, and email deliverability become the vendor's problem. That is worth real money, and self hosting means taking it back.
Where Sigma differs
These are structural choices about who holds what, which is why they are hard to add later.
Self sovereign identity
Users sign a challenge with a key held on their own device. Sigma never receives the private key, so there is no credential store to breach and no password to reset.
Anchored on BSV, generated from a key you already hold
Two layers. The identity attestation hashes live on BSV through BAP, which is the anchor chain and does not move. Generating the identity is separate, and the key can be one a user already holds on Ethereum, Bitcoin, Bitcoin Cash, Bitcoin SV, Litecoin, Avalanche, ICP, or Solana. See how.
Moving from Clerk
Sigma uses OAuth 2.1, so most of the work is configuration rather than a rewrite. Point your client at the Sigma authorization endpoint, map users to public keys, add the backup and restore path, then run both providers in parallel while users migrate on next sign in.