Stop the same abuser
from coming back as a new account.

Example

A scalper creates 500 accounts. Your fraud team catches 200 of them and bans them. Tomorrow the same person is back with new emails, new SIMs, new proxies. Passkeys alone can't fix this: they recognize a returning wallet, but nothing stops an abuser from making another one. If you require human proofs, coming back means passing identity verification again. Rotating emails and IPs stops minting clean accounts.

Assurance levels

One integration, three levels of assurance

You don't have to demand ID checks from everyone on day one. Start with passkey continuity, verify a signed proof on your backend where it matters, and only require a human proof for the accounts and actions where one-person-one-account is the whole point.

For your real users

Already verified? No ceremony on your site.

A user who completed isHuman on any lemma.id-enabled site can clear your gate instantly. No ID check, no document upload, no signup friction. They already proved they're human; your site just asks for the proof.

Most fraud tools cost you conversion. This is one of the few that can improve it for returning verified users. Every new integrator makes the next signup smoother for everyone on the network.

Why teams choose lemma.id

The gap between login and KYC

A login provider tells you which account signed in. A bot tool tells you which session looks suspicious. Neither can tell you that two accounts are the same person. Human proofs fill that gap, and lemma.id keeps the proof private and verifiable on your own backend, so you don't end up running an identity database to get it.

How it works

Bind, detect, enforce

lemma.id doesn't replace your login, your fraud model, or your moderation queue. It gives those systems something durable to act on when they decide someone has to go.

See the full verification flow and data model →

Verifiable audit stamps

Prove a verified human did it, later

After verification, stamp any action (a checkout, a post, a moderation call) with an offline-verifiable proof that a verified human performed it. The evidence lives entirely in your systems. Re-verify years later without calling lemma.id.

Developer integration

Verify a signed presentation on your backend

Most of your users start at the passkey tier and never see an ID check. Where you need one human per account, ask for isHuman at signup or on the risky action. Your backend verifies the signed presentation itself and never touches KYC data.

<script src="https://lemma.id/sdk/ishuman-verifier.js"></script>
<script>
  const verifier = new IsHumanVerifier({ siteId: 'app.example.com' });
  const { ok, presentation } = await verifier.verifyForBackend({
    autoProvision: true,
    requiredAssurance: 'ishuman',
  });
  if (!ok) throw new Error('not_verified');
  await fetch('/api/signup', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ presentation }),
  });
</script>

View integration docs See the demo

Product boundaries

What lemma.id is not

It's worth being clear about where lemma.id fits. It sits between your login, your fraud detection, and identity verification. It doesn't replace any of them.

Ticketing & presale farming Agent identity (roadmap) Trust & data model About the approach Integration docs Live demo Pricing For IDV providers Privacy policy

Add to Your Site Watch Demo