Services & retail

Membership and entitlement checks, settled at the counter.

Decide on the spot from what the customer presents, with no query to head office. Because customer data is never pushed out to every store, most of the waiting disappears.

Talk to us Verify a proof yourself

Store terminal — checking membership

Verified

DOC HASH0x68d4…9f01

IssuerGroup head office

Issued2026-07-28

SubjectMembership status

Proof classProvenance

Signature matches Tamper check Issuer confirmed

The proof layer
is running now

Verification Center live 3 proof-backed data feeds Verification is free

See it for yourself →

01 — Why LemmaWhat keeps the customer waiting is the call to head office.

You want group-wide benefits and member perks to actually work across sites. But every store that isn't the issuing one has to check with head office, so nothing can be settled at the counter — and those few minutes of waiting are what the customer actually experiences. Pushing the data out to every store only moves the problem: now each of them carries the storage and the breach exposure. What you need is a way to confirm without distributing anything.

Share the trust,
not the customer data.

02 — What changesThree things Lemma changes

Store checks that never wait on a query

Settle on the spot whether the membership or entitlement presented is genuine. No call to head office in between.

Front-desk terminal

Record presentedMembership (Premier)

IssuerGroup head office

Query to issuerNot needed

VerdictVerified

Checks that cross stores

Membership statusValidProof attached

Entitlement conditionsValidProof attached

Age check (20+)ValidProof attached

Student statusValidProof attached

The same verdict at every store

A proof still verifies after it has been forwarded, so any store and any member of staff reach the same answer. Answers stop varying from store to store.

Live before any development work starts

Permissions and checks are configured from the admin screen, so stores can start before any development work begins.

POST /v1/proofs/verify

// The same verification, by API or from the admin screen { "docHash": "0x68d4…9f01" } // What comes back { "valid": true, "issuer": "hq" }

03 — Threat casesWhat happened when the check became a formality.

Three cases from this area, drawn from the Lemma Critical Briefs. In each one, the receiving side could not independently establish that the other party was who they claimed to be.

No. 051Asking the AI support bot was enough to take over someone else's accountIdentity & Auth No. 064A trusted integration's tokens were stolen, and hundreds of tenants' customer data was queriedAgent Infrastructure No. 086The vendor handling identity checks was inside for 18 months before anyone noticedKYC / AML Disclosure

See every Brief in this area →

04 — How it worksThree steps, and that's it.

Issuing the proof

RecordMembership status

IssuerGroup head office

What is sentHash only

Issued 0x68d4…9f01

01Attach a proof

Why it holdsChange one character in the record and it no longer matches the proof.

One API call at issuance, or register it from the admin screen. The record itself is never sent.

What the customer presents