ZKPPrivacy / VerificationBBaton Protocol

Even we cannot know who our users are.

Zero-knowledge proof (ZKP) verifies only the fact a service needs, instead of submitting full personal data. BBaton applies this principle to anonymous verification, delivering only the required result — such as whether a user is an adult.

PROVE WHAT MATTERS. REVEAL NOTHING ELSE.

01 · ZKP Fundamentals

Why ZKP matters.

A verification structure that confirms whether a condition is met without revealing identity. ZKP verifies only true/false and is designed to expose nothing else.

01

Completeness

Completeness

When a proof is checked, only a correct proof passes verification. The system is designed to attest user proofs reliably.

02

Integrity

Integrity

Proof values must not be forged or bypassed to deceive the verifier. Blockchain technology makes tampering and circumvention impossible.

03

Anonymity

Anonymity

The verifier learns nothing beyond whether the user holds a valid proof. Even BBaton is designed to be unable to know who the user is.

02 · Verification Structure

Verification, from the
service perspective.

In production, the user’s personal data, the proof generated on the device, and the service interpreting the result must be separated. The point: your service receives only the result — never the raw data.

STEP 01
SECRET
PROVER / User side

Original data stays with the user.

IDs and personal identifiers, including date of birth, remain on the user’s device or within user-controlled space. BBaton servers are designed to collect no personal data.

Sample inputbirthdate = 1985-06-14
nationality = KOR
STEP 02
PROOF
PROOF / Attestation

BBaton verifies only proof validity.

A request for a condition — such as adult status — goes to the user’s device, which returns a proof. BBaton verifies only whether that proof is valid.

Claim requested by serviceclaim = age ≥ 19
proof = 0x8f3a...b2e1
STEP 03
VERIFIER / Service

The client sees only the result.

The verified claim is delivered to the client. It contains no personal data — only whether the requested verification is true or false.

Resultverify(proof) → true
knowledge leaked → none
BBATON · How we apply it

Originals stay on the device.
Your service gets only the result.

BBaton never touches personal data. The client sends a request, the device generates the required proof, and BBaton only verifies and returns the result.

01 · ENROLL
DEVICE / User device

Enroll once, keep it on-device.

At first enrollment, document data is read and the personal data plus proof material are generated — stored on the device only.

Created on devicepassport_data
biometric_template
secret_key (device-only)
02 · CUSTODY
CUSTODY / Local storage

The device is the vault.

Original IDs never reach a central server or the blockchain. Everything that could identify the user stays in the user’s own hands.

Never transmittedPassport image, birthdate, name
Selfie, facial features
Secret key
03 · PROVE
PROVE / Result delivery

On request, prove the claim only.

When a client requests a condition, the device builds a proof from local data and BBaton verifies it. Original identity data is never transmitted.

What the service receivesclaim: age ≥ 19
result: true
leaked info: none
03 · In Practice

Verify only
what you need.

BBaton is not an identity service. It does not tell you who a user is — it confirms whether a specific condition is met.

BEFORE / Conventional

Show the whole ID.

What the clerk sees
NAMEMinsu Kim ID NO.950614-1****** ADDRESSTeheran-ro, Gangnam-gu, Seoul···
Exposed: name, ID number, address, photo, issue date

All that was needed was adult status — yet unnecessary personal data is exposed alongside it. Purpose and exposure do not match.

AFTER / With ZKP

Confirm adult status. Nothing else.

What the clerk sees
CLAIM
Age 19 or older
◆ VERIFIED
Private: name, ID number, address, birthdate

The service confirms only what its policy requires and never learns the underlying name, address, or birthdate. Purpose and data collected finally match.

Check out the developer guide.