[DMP 2026]: Finternet: Verifiable Presentations and ZK-Based Selective Disclosure for UNITS Credential Token

[vineet-finternet]

Ticket Contents

Description

Finternet's UNITS system has an existing credential token implementation conforming to W3C Verifiable Credentials 2.0. This credential token powers compliance enforcement at transfer time — a token transfer policy references a required VC type (e.g., KYC, accredited investor status), and UNITS checks the holder's credential store before permitting the transfer.
However, the current implementation does not support two critical privacy-preserving capabilities:

Verifiable Presentations (VPs): A user cannot yet construct a presentation containing only a subset of claims from one or more VCs to share with a verifier, without exposing the full credential.
Zero-Knowledge based selective disclosure: A user cannot yet prove that a credential claim meets a threshold (e.g., age > 18, credit_score > 750) without revealing the raw value.

This project extends the existing W3C VC 2.0 credential token to add both capabilities, making UNITS the first open financial infrastructure layer to support privacy-preserving credential verification natively at the token policy layer.

Goals & Mid-Point Milestone

Goals

Current State

UNITS credential token issues and stores W3C VC 2.0 compliant credentials
Credentials are verified at transfer time by checking validity and expiry against the holder's credential store
No VP construction or selective disclosure is supported — the full credential must be presented

Proposed Extensions

• Verifiable Presentation (VP) layer:

  • VP builder: user-side SDK or internal service within finternet App to construct a W3C VC 2.0 compliant Verifiable Presentation containing a specified subset of claims from one or more VCs held in the credential store
  • VP signing: VP signed with the holder's Finternet account key, binding the presentation to the presenting identity
  • VP verification: A verifier module that accepts a VP in place of a raw VC at transfer policy evaluation time

• ZK selective disclosure:

  • Contributor to evaluate and propose the most suitable ZK scheme for the Finternet context (candidates: BBS+ signatures for unlinkable selective disclosure; circom/Groth16 for arithmetic threshold proofs; SD-JWT as a lighter-weight alternative)
  • Implement ZK proof generation for at least two claim types: boolean membership (e.g., jurisdiction ∈ {IN, SG}) and threshold (e.g., credit_score > threshold)
  • UNITS verifier extended to accept and verify ZK proofs during transfer policy evaluation without accessing the raw claim value

• Integration with token transfer policy:

  • Token Manager can specify in token class policy whether a full VC, a VP, or a ZK proof is acceptable for a given compliance check
  • Policy evaluation log records proof type used (VC / VP / ZKP) without storing the credential data itself

Mid-Point Milestone:

• VP builder and VP verifier fully functional for single-credential, single-claim-subset presentations. VP accepted by UNITS transfer policy evaluator in a test token class. ZK scheme selection documented with rationale.

Setup/Installation

Builds on the existing UNITS credential token codebase. ZK tooling setup (circom, snarkjs, or any chosen scheme) to be documented as part of deliverable. All new capabilities to be runnable locally via Docker Compose against a development UNITS instance.

Expected Outcome

• VP builder SDK: constructs W3C VC 2.0 compliant Verifiable Presentations with configurable claim subsets
  VP verifier module integrated into UNITS transfer policy evaluation
• ZK selective disclosure: proof generation and verification for ≥2 claim types (boolean + threshold)
  Scheme selection document: rationale for chosen ZK approach, tradeoffs vs. alternatives (BBS+, SD-JWT, Groth16), and recommendation for future claim types
• Full test suite: VP round-trip, ZK proof round-trip, policy evaluation with VP and ZKP inputs, rejection of tampered proofs
• Developer documentation: how to configure a token policy to require VP or ZK proof, how to build and present a VP as a holder

Acceptance Criteria

VP conforms to W3C VC 2.0 Verifiable Presentations specification

• VP is signed with holder's key and verifiable without contacting the issuing Trust Provider
• UNITS transfer policy evaluator correctly accepts a valid VP and rejects a tampered or expired one
• ZK proof generation produces a valid proof for boolean membership and threshold claim types
• UNITS verifier accepts ZK proofs without accessing the raw claim value
• Token Manager can configure token policy to accept VC / VP / ZKP interchangeably per claim type
• Policy evaluation log records proof type without storing credential data
• Test suite covers: valid VP, expired VP, tampered VP, valid ZKP, invalid ZKP, policy with VP requirement, policy with ZKP requirement

Implementation Details

• Base: Existing UNITS W3C VC 2.0 credential token implementation
• VP format: W3C Verifiable Presentations Data Model 2.0; JSON-LD or CBOR-LD serialisation
• VP signing: ECDSA and EdDSA with holder's Finternet account key
• ZK scheme: Contributor to evaluate and select from different schemes. Recommendation expected by week 3.
• Verifier integration: UNITS policy evaluator extended with a ProofVerifier interface accepting {type: "VC" | "VP" | "ZKP", proof: ...}; each type dispatched to its respective verification module

Mockups/Wireframes

No response

Product Name

Finternet Verifiable Credentials

Organisation Name

FinternetLabs

Domain

Financial Inclusion

Tech Skills Needed

TypeScript or Rust, W3C Verifiable Credentials 2.0, Zero-Knowledge Proofs (BBS+, circom/snarkjs, or SD-JWT), JSON-LD, Cryptography, Docker, Technical Documentation

Mentor(s)

Finternet Engineering Team Member

Category

Backend

[anuragShingare30]

Hey @vineet-finternet , I'm Anurag Shingare an Blockchain and Backend engineer currently working as a developer at Protocol labs(Libp2p, Akave, Storacha). I'm interested in this project for DMP2026 as it aligns with my tech skills, I have experience in working with ZKs and cryptography.

Here is the quick questions:

1. Can you provide current UNITS credential token implementation repos?
2. Can you provide public repo where I can start the pre-contribution before submitting proposal?
3. Can you provide any public repo/docs for UNITS credential token?

[pradhyum6144]

Hi @vineet-finternet

I'm interested in working on this issue for DMP 2026 and would love to contribute to making UNITS the first open financial infrastructure layer with native privacy-preserving credential verification.

About me:
I'm Sai (GitHub: @pradhyum6144), a CS student at Medhavi Skills University / Polaris School of Technology, India. I have a published Rust library (btc-tx-parser) for Bitcoin transaction parsing, contributions to OpenTelemetry/CNCF, and am currently a Summer of Bitcoin contributor. My experience with cryptographic systems from Bitcoin protocol engineering (PSBT, P2WPKH/P2TR, BIP-174/141) maps directly to the skills this project requires.

My understanding of the problem:
The current UNITS credential token checks the holder's full VC against a transfer policy but this exposes more data than necessary. The two gaps are:

VP support the holder needs to construct a W3C VerifiablePresentation revealing only the claim subset the policy requires, signed with their Finternet account key, so the raw credential never leaves the wallet.
ZK-based selective disclosure for threshold checks like age > 18 or credit_score > 750, and boolean membership checks like jurisdiction ∈ {IN, SG}, we need a ZK proof that satisfies the predicate without revealing the raw value.
Proposed approach (aligned with the mid-point milestone):

Phase 1 (Mid-point):

Build a VPBuilder that constructs a W3C VC 2.0 compliant VerifiablePresentation with DataIntegrityProof (ECDSA/EdDSA), supporting single-credential, single-claim-subset presentations
Implement VPVerifier integrated into the UNITS transfer policy evaluator accepting valid VPs and rejecting tampered/expired ones
Deliver a ZK scheme selection document with a formal comparison of BBS+ signatures (W3C vc-di-bbs), SD-JWT, and circom/Groth16, with a recommendation for the Finternet context
Phase 2 (Final):

Implement ZK proof generation and verification for the selected scheme, covering both boolean membership and threshold claim types
Extend CredentialTokenPolicy so Token Managers can configure whether a full VC, VP, or ZKP is acceptable per claim type via a ProofVerifier interface ({type: "VC" | "VP" | "ZKP", proof: ...})
Policy evaluation logging that records proof type without storing credential data
Full test suite: VP round-trip, ZK proof round-trip, policy evaluation with VP/ZKP inputs, tampered proof rejection
I've studied the W3C VC Data Integrity BBS Cryptosuites working draft, the IETF CFRG BBS signature spec, and the LegoGroth16 + BBS+ PoC from Dock Labs. My initial lean is toward BBS+ for selective disclosure combined with Groth16-style circuits for predicate proofs, but I'll deliver a rigorous comparison before committing to a scheme as the issue requests.

A couple of questions:

1. Could you point me to the existing UNITS credential token codebase/repo so I can start exploring the current VC implementation?
2. Is there a preference for TypeScript or Rust for this project, or is that open for the contributor to decide?

Happy to discuss the architecture further on Discord or here. Looking forward to contributing to Finternet!