Five proofs,
one API.
Models change. Proofs remain.
Issue proofs for your records, your data, and your AI runs. Raw data never leaves your systems; only the proof is sent. Verification is free and unlimited, and needs no key.
Why proofWhy it has to be proof.
Not detection. Not human inspection. Three reasons proof builds trust in the AI era without adding to the cost of checking.
These are the five things Lemma can prove. Combine them to fit the job. Every one follows the same shape: show only the fact, never move the original. The original is never handed to Lemma either.
Prove origin without handing over the original.
Show where data came from and that it has not been tampered with, without exposing the contents. Receivers verify independently, with no access to the original.
What is disclosed
- The data fingerprint (docHash）
- The issuer and its signature
- Time of issuance
- The chain of provenance
What never leaves
- The original data — never sent to Lemma servers either
- Internal details and sensitive fields
- The issuer private key
See how your industry uses this in the solutions index.
Prove who you are without sending a key.
The device produces only a proof of holding the key, and sends that. Neither the key nor its hash is handed over. Because the proof is a different value at every sign-in, proofs cannot be linked to the same person from the proofs themselves.
What is disclosed
- A per-session value (the nullifier）
- Public signals needed for verification
- The fact that the sign-in succeeded
What never leaves
- The key itself — never sent to Lemma servers either
- The key hash (absent from the public signals)
- Anything that links one proof to another
Note: the service you sign in to matches the received proof against its own registered key to confirm who you are. How sign-in works and how to adopt it: the Seal page ↗
See how your industry uses this in the solutions index.
Delegate authority without handing over a key.
Only what is inside the granted scope executes; outside it, nothing runs. Agents receive bounded authority, not keys.
What is disclosed
- The delegated scope (role and limits)
- The fact that execution within that scope is allowed
- The record of allows and stops
What never leaves
- The key itself — never sent to Lemma servers either
- The delegator credentials
See how your industry uses this in the solutions index.
Prove the inference without disclosing the model.
Show, after the fact, what an execution was grounded on. The execution itself is proven without opening up the model.
What is disclosed
- The fact that an execution happened
- The input fingerprint
- Time of registration
What never leaves
- Model weights and configuration — never sent to Lemma servers either
- Prompt and input-data contents
See how your industry uses this in the solutions index.
Prove a requirement is met without revealing the attribute.
For example: show fitness for duty without exposing health data. What travels is the fact that a requirement is met, not the value itself.
What is disclosed
- The fact that the requirement is met
- The issuer and its signature
- Expiry
What never leaves
- The attribute value itself — never sent to Lemma servers either
- The underlying details: birth date, health data, and so on
See how your industry uses this in the solutions index.
Note: this proof is offered as a custom build. Talk to us.
You send only a hash. The original never rides the wire, and never reaches Lemma servers.
// Issue (billed, once) — you send a hash. Never the original. POST /v1/documents → req { docHash: "0x7a8f…", … } → res { docHash, status: "registered" } // Verify (free, any number of times, no key) GET /v1/documents/:docHash → res { status: "registered" | "anchored" | "pending", issuer, registeredAt } → Unregistered returns 404. No content fields are returned. // GET is the finalized spec, currently being implemented. Today's query path is POST /v1/verified-attributes/query.
Each proof uses different cryptography, but you call the same two endpoints. Each proof's cryptographic spec lives in the technical docs.
Issuance is billed; verification is always free. How this differs from other approaches: the comparison page.
Try the Sandbox (free) Read the docsHow it worksData stays in place. Only proofs travel.
The proof is created at the source. Lemma receives only a hash; the record itself stays with you.
You hand over the proof together with the record. The recipient needs no special software and no account.
Anyone can check it with a public key. There is no round trip back to the issuer, so your costs do not rise no matter how often it is verified.
Zero-knowledge proofs, selective disclosure, and on-chain provenance records are covered in the documentation →
RegistryWhat is running, verifiable on the spot.
The panel shows the real counts of what Lemma has verified and issued.
We do not fill in estimates. If the counts cannot be read, the panel shows OFFLINE.
The ID above belongs to a proof actually issued for the forex data feed. Paste the ID of a proof you issued yourself and it will be checked the same way.
- Verification is free. No key, no account. No limit on the number of verifications.
- There is no round trip back to the issuer. The recipient reaches its own verdict.
- Only real counts. Not data points, not requests — one verification counts as one.
CustomWhat ships as standard, what comes under custom configuration.
- Issuing and verifying proofs (Provenance, Authentication, Authority, Inference)
- Links and badges that point to the verification page
- Integration with the supported standards (MCP / A2A / x402 / C2PA / W3C VC)
- Choosing which fields to reveal (selective disclosure)
- Direct on-chain verification (a dedicated verifier contract)
- Embedding in your own screens and integration with core systems
Lemma is running in production at a municipality, without exposing personal data. It has also been deployed under custom configuration. Talk to us about deployment →
Which records would shorten checking
once they carry proof?
In a 30-to-60-minute session, we work with you on what to prove and how to configure it. You will also see on the spot whether the standard configuration is enough.