LP Claim Attestation
Issue DeFi liquidity-provider attributes — KYC outcome, region, risk tolerance — as ZK attestations without exposing the raw data, so the protocol verifies only the attribute predicates it needs and meets regulatory requirements without ever holding the source identity record.
For DeFi protocol teams
Bound LP participation by eligibility without holding a custodial KYC database — resolving the binary between off-chain KYC cost and permissionless tail risk.
-
Protocol design leads building regulated DEXes, lending markets, or cross-border liquidity venues
-
Compliance and risk owners weighing privacy promises against AML / KYC obligations
-
Jurisdiction policy designers implementing region-based participation limits at the protocol layer
Hand over the source, or just the facts?
Nothing changes on the floor. Everything changes for the receiver.
① Your team just saves, as always.
- The usual step
- Fill in the record and save
- On save
- A proof is attached (API, behind the scenes)
- The document itself
- never sent
② They just open a link.
- Proven fact
- meets the regulatory regime (region, risk tolerance)
- the LP's KYC data and balances
- not shown
- Login / keys
- not needed
- The document stays private — the record itself is never sent or disclosed.
- Independent verification — the receiver just opens a link. No account, no keys.
- Edits are detected — even a one-character edit fails verification.
An LP completes identity verification with an issuer that already operates under a relevant regulatory regime — a regulated KYC provider, an attribute authority, a banking partner. The issuer signs a credential against the LP's identity record. The LP holds the credential in its own wallet.
When the LP deposits into a Lemma-integrated protocol, the deposit path verifies a ZK attestation against the credential: "this LP passed KYC with an issuer accepted by this protocol, is resident in a region permitted by this pool's policy, and falls into the risk tier this pool requires." Nothing else crosses to the protocol. The protocol never holds, indexes, or retains the identity record itself.
Revocation lives at the issuer. If the LP's KYC lapses or region changes, the issuer publishes an update and the next deposit path verification fails — without the protocol ever scanning its own LP set.
Why the usual methods fall short.
Only work that needs all three at once — pass without exposing, independent verification, tamper-evidence — is Lemma's domain.
| Method | Pass without exposing | Independent verification | Tamper-evident | What happens |
|---|---|---|---|---|
| Access control / permissions | △ | ✗ | ✗ | “Someone inside could have edited it” remains possible |
| Masking / redacted copies | △ | ✗ | ✗ | Redaction work grows; the original is still unproven |
| Encrypt and store / send | ✓ | ✗ | ✗ | To verify, the receiver needs it disclosed after all |
| Lemma (ZK proof)the only one with all 3 | ✓ | ✓ | ✓ | The receiver just opens a link |
How it works — and how to start.
We help design disclosure scope and retention, run the PoC, and support production.
Start with a 30-minute call.
Tell us one participation path where "want to gate by eligibility but don't want to hold identity data" applies, in the first 30 minutes. No LP identity records or pool configuration required.
Find the case that matches your industry and problem
Browse all 36 use cases →TRY LEMMA
Run it yourself.
No sales call needed — start hands-on with Lemma's products.