isHuman | Stop repeat abusers from coming back as new accounts

Built for platforms where account rotation is the attack. Ticketing and presale drops, marketplaces, gaming, free trials, rewards — anywhere the next account is almost free.

Example

A scalper creates 500 accounts. You ban 200. Tomorrow they're back with new emails, SIMs, and proxies. Recognizing the same lemma.id helps with continuity — it doesn't stop someone from making another. Require a human proof, and coming back means identity verification again.

How lemma.id builds trust

One integration, three levels of proof

Start with lemma.id continuity. Add a presence proof when you need the holder at the device. Step up to a human proof only where one person must mean one account.

lemma.id

The continuous thing. Recognize the same returning lemma.id with a stable, site-private PPID. Good for trying the integration — but anyone can create another lemma.id, so this alone won't stop repeat abusers.

Presence proof

A fresh passkey at presentation signing shows the holder is at the device right now. Your backend gets a signed proof it can trust, with no KYC data on your servers.

Human proof

One account per verified human. A ban actually costs the abuser something. Use this when new-account rotation is the attack you're fighting.

For your real users

Already verified? No ceremony on your site.

A user who already has a human proof anywhere on the network clears your gate instantly — no ID check, no upload. Most fraud tools cost conversion; this one can improve it for returning verified users.

Why teams choose lemma.id

The gap between login and KYC

Login tells you which account signed in. Bot tools flag suspicious sessions. Neither proves two accounts are the same person. Human proofs fill that gap — privately, on your own backend.

	lemma.id + your site	Auth0 / Google SSO	Direct KYC on your stack
Your servers store	`human` + ~80-char PPID	Email, name, shared `sub`	ID images, name, DOB, reports
Cross-site linkability	Different PPID per site	Same user ID across apps	You own the identity store
Return-visit checks	Local, no lemma.id call	Server token validation	Vendor re-query or re-verify
Ban survives rotation requires human proofs	Block the human root, not just the email	Attacker rotates email or OAuth account	Strong, but you run KYC

Full trust & data comparison →

How it works

Bind, detect, enforce

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

1

Bind

Tie the user to a site-private PPID. lemma.id means “same identity object.” Human proof means “same verified person.”

2

Detect

Your fraud and moderation tools still decide who's bad. lemma.id makes the consequence follow the person, not the email.

3

Enforce

Block the PPID or demand fresh verification. Once human proofs are required, a new email or SIM doesn't buy a clean slate.

Before

Bot detected → account banned → attacker rotates email, SIM, or proxy → new account, free

With human proofs

Bot detected → account tied to verified human → PPID blocked → must pass fresh IDV to return

Verification flow, site doubt, and data model →

Verifiable audit stamps

Prove a verified human did it, later

Stamp a checkout, post, or moderation call with an offline-verifiable proof. Evidence stays in your systems — re-check years later without calling lemma.id.

Stamp at the action

The SDK's stamp() helper attaches a signed credential to any event your backend records.

Verify offline

Same local verifier you use at signup. No network call on audit review day.

Your data, your systems

lemma.id doesn't store your logs. Useful for chargebacks, regulators, and “human or agent?” questions.

See stamp integration →

Developer integration

Verify a signed presentation on your backend

Most users stay on lemma.id continuity, with a presence proof when you need the holder at the device. Where you need one human per account, require a human proof. Your backend verifies the presentation and never touches KYC data.

Signup gate when one-person-one-account matters

<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 sits between login, fraud detection, and identity verification. It doesn't replace any of them.

Not bot detection

Finding suspicious behavior is your fraud stack's job. lemma.id makes the ban stick once you've decided.

Not a global identity

Every site gets its own PPID. No shared identifier follows people across the web.

Not an identity store you run

Your servers hold a verdict and a PPID. No ID documents, names, or dates of birth.

Learn more

Trust & data model Integration docs Ticketing & presale About the approach

Add isHuman to your site

The next time you ban someone, make it stick. A script tag and a backend check.

Add to Your Site Watch Demo

Stop the same abuserfrom coming back as a new account.