ZKP PRIVACY / VERIFICATION BBATON PROTOCOL

Without revealing you prove only what matters.

Zero-knowledge proof (ZKP) verifies only the fact required by a service instead of exposing a user's full personal information. BBATON applies this principle to anonymous verification so a service can receive only the result it needs, such as whether a user is an adult.

Prove what matters.
Reveal nothing else.

01 / Core Principles of ZKP

Why ZKP matters.

In real services, what matters is rarely a full identity record. ZKP is a proof system designed to verify only whether a claim is true or false without exposing the rest of the data.

01

Completeness

Completeness

If a claim is true, a valid proof must pass verification. In practice, this means legitimate users should be able to prove required conditions reliably.

02

Soundness

Soundness

If a claim is false, manipulation or bypass attempts must not fool the verifier. Operationally, that means false verification and forged results cannot pass.

03

Zero knowledge

Zero-Knowledge

The verifier should learn nothing beyond the fact that the claim is true. Names, birth dates, and original documents should not leak during verification.

02 / Verification Structure

A service-level verification model.

In production, the user secret, the proof generated on the device, and the service interpreting the result should remain separated. The key is that the service receives only the result it needs, without raw source data.

STEP 01
SECRET
PROVER / USER SIDE

Secrets stay
with the user.

A user's birth date, document details, and identifying values should stay on the device or in a user-controlled area. The service should not collect the full original record.

Example Inputs birthdate = 1985-06-14
nationality = KOR
Generate Proof
STEP 02
PROOF
PROOF / PROOF

Proofs are
generated per request.

When a service asks for a specific condition such as whether the user is an adult, the device computes a proof locally. Original documents and detailed attributes are not embedded directly in the proof.

Claim Requested by Service claim = age ≥ 19
proof = 0x8f3a...b2e1
Verify
STEP 03
VERIFIER / SERVICE

Services verify
results only.

The service verifies whether the proof is valid and receives only the results required by policy. Even after verification, the user's raw identity data remains unknown.

Result verify(proof) → true
knowledge leaked → none
BBATON / Implementation Direction

Keep source data on the user device, and let services receive only the result.

The structure BBATON is working toward avoids centralized storage of raw source data and instead keeps it on the user device while focusing on result-based verification. result-centered verification. The service sends a question, the device creates only the proof required for that question, and returns only the result.

01 · ENROLL
DEVICE / USER DEVICE

Register once,
store on device.

At initial enrollment, the required document information is read and converted into secret material and verification inputs that remain only on the user device.

Generated on device passport_data
biometric_template
secret_key (device-only)
On device
02 · CUSTODY
ON-DEVICE
CUSTODY / LOCAL STORAGE

Stored on the device,
not the server.

The model avoids uploading original passport images or full birth date values to a central server or blockchain. The operational system handles only the minimum required information.

Never sent externally Passport image, full birth date, name
selfie, facial landmarks
secret key
On request
03 · PROVE
SERVICE QUERY TRUE ✓
PROVE / RESULT DELIVERY

When requested,
prove only the claim.

When the service requests a condition, the user device creates a proof from local information and the server receives only the result and verifiable evidence. Raw identity data is never transmitted.

What the service receives claim: age ≥ 19
result: true
leaked info: none
03 / Example Use Cases

Check only the information required.

In most services, what is truly needed is not a full identity record but confirmation that a specific condition is met. A convenience-store age check is one of the clearest examples of why ZKP matters in live services.

BEFORE / Legacy model

Show the entire ID document.

What the clerk receives
NAME
Kim Min-su
ID NO.
950614-1******
ADDRESS
Teheran-ro, Gangnam-gu, Seoul ···
Exposed: name, national ID, address, photo, issue date

The service only needs to know whether the user is an adult, yet unnecessary personal data is exposed as well. The purpose of collection and the scope of exposed information do not match.

AFTER / ZKP model

Verify adulthood only.

What the clerk receives
CLAIM
Age 19+
♦ VERIFIED
Hidden: name, national ID, address, birth date

The service checks only the result required by policy and never sees raw values such as the name, address, or birth date. The verification purpose and the collected information now align.

04 / BBATON Roadmap

Current operations and Next Steps.

BBATON is already designing its verification structure around the principle of minimum necessary information. Going forward, the structure can expand toward reducing raw attribute exposure even further at verification time.

PHASE / CURRENT OPERATIONS

Hash-based
minimum-data verification.

attribute values + salt
keccak256 hash
recorded on Base L2
  • No raw information recorded on-chain
  • Integrity can be checked
  • An attribute-check step still exists during verification
  • Additional lookup may still be required depending on service policy
NEXT / Expansion direction

ZKP-based
result-centered verification.

attribute values (on device)
zk-SNARK Generate Proof
only the proof is sent / raw data is not sent
  • Raw information is never sent directly
  • Verifier evaluates only true / false
  • Service-visible information is minimized
  • Expansion under review

Review the developer guide
to see the implementation flow.

Developer Guide