Benefit & Subsidy Eligibility Proof

For those verifying eligibility for subsidies, benefits, and public services. Collecting raw income/household/attribute data to check eligibility becomes a storage-and-leakage liability in itself. "Declared" and "verifiably eligible" are not the same.

• Public-sector teams handling benefit/subsidy eligibility checks
• Teams troubled by application-processing load and the leakage surface of held personal data
• Organizations wanting fair, consistent review that survives staff turnover

Three things at once: prove "eligible" without disclosing income/attributes; let the granting body/auditor verify independently; make it tamper-proof.

Document collection stores income/household data, and that storage is itself a leakage surface. Only a ZK proof does all three. Only work requiring all three at once is Lemma's territory.

Present only a proof that an applicant "meets the eligibility criteria" (income tier, residency, target category). Raw income amounts and household data are not disclosed. The granting body verifies conformance without storing the contents, and auditors confirm the same proof independently.

It arrives not as "more IT" but as the benefit of reducing dependence on individuals and privacy exposure.

All figures are directional.

The granting / reviewing side (public sector) Verify eligibility without collecting or storing raw data — reducing the leakage surface and review load. The basis of decisions survives staff turnover. e.g. from collecting/storing supporting documents to verifying an eligibility proof.

Residents / businesses (applicants) Show only "meets the criteria" without disclosing income/household data; no unnecessary recording or notification. e.g. disclosure shifts from submitting a document set to proving one requirement.

Audit / accountability Explain "granted to eligible applicants" without revealing contents; a fairness trail remains.

A municipality accepts applications for an income-tiered benefit. To check eligibility it collects and stores income certificates and household data — but that stored data becomes a leakage/complaint target, and reviews vary as staff change.

Had Lemma been in place, the applicant presents only a proof that "income tier is at or below the threshold," without revealing the amount. The municipality verifies eligibility without storing the contents, and auditors confirm the same proof independently.

We don't replace your application/review system. We insert one attribute-proof step into the eligibility-check path.

• Selective disclosure: BBS+ over BLS12-381 — present only attributes needed for the eligibility decision.
• Requirement proof: prove "income tier ≤ threshold" etc. via Groth16 (Circom) range/predicate proofs; commit with Poseidon over BN254.
• Provenance: fix application/decision with docHash and issuer signature, leaving a fairness trail.

Raw data stays with the applicant/issuer; only the cryptographic fact "eligible" reaches the granting body.

• Proof that an applicant "meets the eligibility criteria"
• The decision's time and the docHash of referenced attributes
• The decision's cryptographic identity, unchanged years later
• A trail that the granting body, auditors, and third parties verify independently — without storing raw data

Not a standalone SaaS purchase. We enter through AI-adoption / data-governance consulting and a PoC, landing on an existing monthly plan.

1. A 30-minute review — identify eligibility checks where raw-data storage burden / leakage surface concentrates.
2. Narrow to 1–2 decisions (results) to prove — e.g. "income tier ≤ requirement," "residency in target area." Not the amounts/household contents.
3. Design connection and updates — connection to your application/review system, and eligibility renewal/withdrawal handling.
4. Prove one path via a (quote-based) PoC.
5. Land on an existing monthly plan (indicative) — Lemma Civic; pricing confirmed in conversation.

Tell us the one benefit/subsidy with the heaviest raw-data storage burden, in the first 30 minutes. No disclosure of sensitive data required.