vote pending
Midnight-enabled ZK-Identity (zkID) protocol for DeFi, Governance, Healthcare, etc. [open Source]
Current Project Status
vote pending
Amount
Received
₳0
Amount
Requested
₳200,000
Percentage
Received
0.00%
Solution

An open-source DID protocol on Midnight, integrating ZKPs, VCs and reputation metadata. This protocol can easily be integrated by dApps, increasing transactions and improving DID solutions on Cardano.

Problem

Most DID solutions expose too much personal data, lack reputation-based trust or Zero-Knowledge Proofs - making it hard for users to prove trustworthiness without risking personal data exposure.

Team

2 members

Midnight-enabled ZK-Identity (zkID) protocol for DeFi, Governance, Healthcare, etc. [open Source]

Please describe your proposed solution

<u>=&gt; Overview:</u>

This ZK Digital Identity Framework is an open-source protocol built on Cardano’s Midnight sidechain, designed to enable privacy-preserving decentralized identity management using Zero-Knowledge Proofs (zk-SNARKs). This framework focuses on allowing users and dApps to verify identity credentials and reputation without exposing sensitive personal information. By integrating Decentralized Identifiers (DIDs) and Verifiable Credentials (VCs), the framework will provide privacy-focused, decentralized identity solutions tailored for DeFi, governance, and healthcare applications.

<u>=&gt; How the framework can be used</u>

This framework will be open-source, which allows developers and potential applications to customize and build cross-platform identity solutions for their use cases:

  • DApp Integration: Developers can integrate the framework to add identity verification and credential management (like KYC) into decentralized applications using zk-SNARKs for privacy.
  • Issuing VCs: Organizations can issue and manage VCs (e.g., certifications or KYC compliance) using the framework, ensuring privacy while verifying credentials off-chain.
  • Reputation-Based Access: Platforms can use the framework to verify reputation scores and trustworthiness without disclosing users’ complete histories, especially for DeFi and governance.
  • Governance and Voting: The framework can enable private voting systems for decentralized governance, ensuring eligible users can vote without revealing their identity or choice.
  • Healthcare Credentialing: Healthcare providers can verify professional certifications or medical credentials using zk-SNARKs, to ensure privacy and trust.

<u>=&gt; Technical Framework:</u>

1. Decentralized Identity Management

Indentus (Atala Prism) will be used to manage DIDs, allowing for secure issuance, update, and revocation of DIDs. Each DID is cryptographically tied to a private key, which the user controls, ensuring self-sovereign identity management.

<u>How it works:</u>

  • The DID is linked to Verifiable Credentials (VCs) such as KYC compliance or academic certificates.
  • Each DID is stored on-chain as a reference, but the actual data and credentials are kept off-chain for privacy.

2. Verifiable Credentials (VCs) and Reputation Metadata

  • VCs are digital credentials issued by a trusted authority (e.g., a university or KYC provider) and are stored off-chain, and only a cryptographic reference (hash) is stored on-chain.
  • Reputation Metadata: Reputation data, like governance participation or DeFi trust scores, can be issued as VCs. Users can share reputation proofs selectively using zk-SNARKs, allowing others to trust them without revealing unnecessary data.

<u>Technical Flow:</u>

  • A trusted authority issues a VC to a user, which is stored off-chain.
  • A cryptographic hash of the VC is stored on-chain, referencing the off-chain data.
  • Users generate zk-SNARK proofs to verify these credentials, ensuring privacy.

3. Zero-Knowledge Proofs (zk-SNARKs)

zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) allow users to prove the validity of their credentials (e.g., “I’m over 18” or “I passed KYC”) without revealing the actual credential. The zk-SNARK proofs are generated using the Midnight sidechain on Cardano, which specializes in privacy-preserving computations.

<u>How it works:</u>

  • When a user needs to prove their credentials (e.g., to access a DeFi platform), they generate a zk-SNARK proof using their private key.
  • This proof is sent to a verifier (e.g., a dApp), which verifies the proof using on-chain data without accessing the user’s personal information.
  • The smart contract on Cardano can verify the zk-SNARK proof, ensuring that the credential is valid while maintaining privacy.

4. Smart Contracts

Aiken smart contracts handle the on-chain logic for the ZK Digital Identity Framework. These smart contracts manage the issuance, verification, and revocation of DIDs, VCs, and reputation data.

<u>Functionality:</u>

  • Credential Issuance: When a trusted authority issues a VC, the associated cryptographic reference is stored on-chain through a smart contract.
  • Credential Verification: When a user provides a zk-SNARK proof, the smart contract verifies the proof by checking it against the on-chain reference.
  • Revocation/Updates: If a credential becomes invalid or needs updating, the smart contract handles revocation or updates, ensuring that only valid credentials can be verified.

<u>Data Flow:</u>

  • On-chain: Only cryptographic hashes or proofs are stored on-chain to minimize data exposure and maintain efficiency.
  • Off-chain: Sensitive information, such as the actual credentials, is stored securely off-chain, ensuring that personal data remains private.

5. Off-Chain Data Storage

Sensitive personal data (e.g., medical certificates, educational credentials) is stored off-chain. This ensures privacy and reduces on-chain data bloat. The on-chain record holds a hash of the off-chain data, ensuring that anyone verifying the credential can trust that the off-chain data hasn’t been tampered with.

<u>How it works:</u>

  • Off-chain storage provides scalability and privacy since only a reference (cryptographic hash) is stored on-chain.
  • When a user provides a proof, the verifier can check the on-chain hash to ensure that the off-chain data hasn’t been altered.

<u>=&gt; What is unique about this proposal?</u>

  • Privacy-Preserving Verification: Unlike many identity solutions that expose personal data during verification, this framework leverages Zero-Knowledge Proofs (zk-SNARKs) to enable privacy-preserving verifications. Users can prove attributes (e.g., KYC compliance, age, or reputation) without reveal actually private data.
  • Reputation Metadata Integration: A unique feature of the framework is the integration of reputation metadata. This allows users to build and verify reputation scores based on their activities in DeFi, governance participation, or other decentralized applications.
  • Separation of Identity and Credentials: The framework separates identity management (DIDs) from credential verification, ensuring that sensitive personal data (e.g., credentials) is stored off-chain, while only cryptographic hashes are stored on-chain.

=&gt; Related Proposal:

We want to inform that we have submitted a complementary but independent proposal as part of the ‘Concept’ challenge (https://cardano.ideascale.com/c/idea/132171), which is about developing a zkID wallet. This protocol here would extend the functionality of the wallet. At the same time, the wallet would make this protocol easier to use because in some cases you would only need to connect the wallet instead of implementing the whole protocol. But both proposals work independently of each other and create unique value even if just one of them gets funded.

Please define the positive impact your project will have on the wider Cardano community

=&gt; Benefits for Cardano:

Our project will improve privacy, security, and scalability for identity management across Cardano’s ecosystem by integrating DIDs, reputation management and ZKPs. This framework will enable trust-based interactions in DeFi, governance and real-world asset tokenization, expanding Cardano’s transactional diversity while maintaining privacy and compliance.

=&gt;How We Measure Success:

<u>Quantitative Metrics:</u>

  • User Adoption:
  • Metric: Number of Decentralized Identifiers (DIDs) created through the zkID protocol.
  • Goal: Achieve 5,000 DIDs created within the first 12 months.
  • Transaction Volume:
  • Metric: Number of ZKP-based transactions using the zkID protocol for identity verification or reputation validation.
  • Goal: At least 2,000 ZKP-based transactions within the first year.
  • dApp Integrations:
  • Metric: Number of dApps adopting the zkID protocol.
  • Goal: Target integration with 5 dApps across different sectors in the first year.
  • Protocol Usage Across Verticals:
  • Metric: Track the distribution of zkID protocol usage across different sectors (like DeFI, Governance, Healthcare), to ensure broad adoption of the protocol
  • Goal: Target integration with 3 different sectors in the first year.

<u>Qualitative Metrics:</u>

  • Community Feedback:
  • Metric: Gather feedback from users and developers on the protocol’s ease of integration.
  • Goal: Achieve an 80% satisfaction rate based on surveys.
  • Governance Feedback:
  • Metric: Measure the trust and effectiveness of using zkID in governance participation.
  • Goal: Ensure 70% positive feedback on the zkID protocol’s impact on enhancing privacy and fairness in governance.

==&gt; Sharing Outputs:

  • Open-Source: All code and development will be shared on GitHub, with comprehensive documentation.
  • Reporting: We will provide regular updates through Project Catalyst and blog posts.

What is your capability to deliver your project with high levels of trust and accountability? How do you intend to validate if your approach is feasible?

=&gt; Previous Funding and Experience:

TrustLevel and Dominik Tilman have a proven track record of delivering successful Catalyst-funded projects since Fund 3. Over several Catalyst rounds, we’ve be awarded with complex blockchain project such as Aiken Smart Contract Library in F11 (will be implemented here: https://MeshJS.dev/) and zero-knowledge protocols in F12 (link: https://projectcatalyst.io/funds/12/f12-cardano-open-developers/zero-knowledge-zksnark-voting-protocol-on-cardano-for-dao-governance-open-source

=&gt; Team Capabilities:

  1. Technical expertise: We are experts in Cardano's blockchain, Aiken smart contracts and zk protocols.
  2. Catalyst Experience: Our experience in implementing funded projects with strong community engagement demonstrates our ability to manage resources and meet deadlines.
  3. Community engagement: We have strong connections within the Cardano ecosystem and work will continue to work with relevant teams to ensure adoption and value creation of our projects

=&gt; Active Ecosystem Collaborations:

We are currently engaged in several collaborations across the Cardano ecosystem:

  • SidanLab and MeshJS: We are collaborating on smart contract development, particularly within the open-source Aiken Smart Contract Library, a project funded in Fund 11.
  • LidoNation: Working on reputation scores for Catalyst reviewers, where we focus on analyzing user behavior and building models to assess reputation and trustworthiness in the Cardano Catalyst ecosystem.
  • Photrek: Involved in the development of a community tool for voting calculations and community engagement in SingularityNet, building and testing decentralized voting mechanisms (https://proposals.deepfunding.ai/graduated/accepted/ed600af3-885c-45bc-a874-56d2dde371ce)

What are the key milestones you need to achieve in order to complete your project successfully?

Milestone 1: Framework / Protocol Design

Goal: Define the technical foundation and architecture for the decentralized identity (DID) framework with ZKP integration on Midnight.

Deliverable:

• Comprehensive system architecture and design document, including the flow of DID creation, verifiable credentials (VC) management, and ZKP-based proof generation and verification.

• Smart contract interaction diagrams and technical specifications for integrating with Midnight.

• Initial user interface (UI) wireframes.

Acceptance Criteria:

• The system architecture must account for DID creation, off-chain storage, ZKP proof generation, and on-chain verification via smart contracts.

• The design must be privacy-preserving, with proper handling of sensitive data.

Evidence:

• Published system design and architecture documentation on a shared platform (e.g., Github

Milestone 2: Reputation Metadata and Credential Management

Goal: Develop smart contracts to handle the creation and management of DIDs, Verifiable Credentials (VCs), and reputation metadata without privacy-preserving proofs. This milestone will focus on building the basic infrastructure for decentralized identity and reputation systems.

Deliverable:

  • Smart contracts for DID creation, VC issuance, and reputation metadata management.
  • The foundation for managing reputation scores linked to DIDs and VCs, ensuring that reputation can be updated and verified on-chain without exposing private data (but not yet using zk-SNARKs).
  • Integration of basic VC management logic to store and reference credentials off-chain.

Acceptance Criteria:

  • Smart contracts must enable the creation and updating of DIDs, VCs, and reputation metadata on-chain without zk-SNARKs.
  • The system must support the management of multiple credentials and reputation scores, ready for future zk-SNARK integration.

Evidence:

  • Published smart contract code on GitHub, along with documentation explaining the processes of DID creation, VC management and reputation metadata.
  • Video demonstration of VC issuance and reputation metadata management in a test environment, showcasing basic operations.

Milestone 3: zk-SNARK Integration with Midnight

Goal: This milestone focuses on ensuring verifications remain confidential and private while maintaining trust.

Deliverable:

  • Integration of zk-SNARKs using Midnight’s privacy infrastructure.
  • Smart contract logic enabling selective disclosure of credential data, allowing users to prove specific attributes (e.g., age or KYC compliance) while maintaining privacy.
  • Reputation verification integration using zk-SNARKs, ensuring reputation scores can be verified without exposing detailed interaction history.

Acceptance Criteria:

  • Smart contracts must support zk-SNARK proofs generated by Midnight, allowing for private verification of credentials and reputation.
  • Contracts must allow users to disclose specific credential attributes while keeping the rest of the information private.

Evidence:

  • Updated smart contract code published on GitHub with detailed documentation on the integration of Midnight for zk-SNARK-based verification.
  • Video demonstration showcasing the use of zk-SNARK proofs for private credential verification in a test environment, using Midnight for zk-SNARK generation and verification.

Milestone 4: Integration with Third-Party dApps

Goal: Demonstrate the utility of the decentralized identity framework by integrating it with at least 2 third-party dApps (like DeFi platforms, voting systems, wallets, etc.).

Deliverable:

  • Integration of the DID framework into third-party dApps that require identity verification or selective credential disclosure.
  • End-to-end demonstration of ZKP-based proof verification in real-world scenarios.

Acceptance Criteria:

  • The integrated dApps must successfully request and verify identity attributes using ZKPs through the DID framework.
  • Data privacy must be maintained, with no exposure of sensitive information.

Evidence:

  • Demonstration videos showing the integration of the DID framework with third-party dApps.
  • Published integration guides and code on Github.

Final Milestone: Project Close-Out Report

Goal: Deliver a comprehensive report summarizing the project’s outcomes, challenges, and future potential.

Deliverable:

• A detailed project close-out report, including an overview of the project’s achievements, technical outcomes, lessons learned, and recommendations for future development.

• Final documentation and guides for developers and users.

Acceptance Criteria:

• The report must comprehensively summarize all milestones and include evidence of successful completion.

• All code, documentation, and other materials must be made publicly available.

Evidence:

• Final project close-out report published online.

• All relevant code, documentation, and deliverables available on Github or other shared platforms.

Who is in the project team and what are their roles?

TrustLevel was founded by Dominik Tilman with the vision to develop methods and protocols to make the reliability of data and information measurable. Since then, we have received various grants (Cardano, SingularityNet, Arbitrum) and projects that have continuously improved our knowledge and developed tools and enabled us to provide better reviewing and voting processes and systems in decentralised communities. All our outputs are open-source.

=&gt; TrustLevel Core Team:

  • Dominik Tilman: Project and Technical Lead. Dominik has been actively engaged since Fund 3 in Project Catalyst and involved in multiple funded projects. All proposals are either successfully delivered or on track. He is founder of TrustLevel.io &amp; Conu21.com and has 15+ years experience in innovation management and company building.
  • Roman Preuss: Full-Stack Developer
  • Josch Rossa: Full-stack developer and LLMs
  • Alex Ramalho: Full Stack AI Developer
  • Sergey K: Blockchain Developer

Please provide a cost breakdown of the proposed work and resources

Milestone 1: Framework Design55,000 ADA

  • System design and architecture for DID creation, ZKP integration, and smart contracts.
  • Initial UI wireframes and technical documentation.

Milestone 2: Smart Contract Development and Reputation Integration55,000 ADA

  • Smart contracts for managing DIDs, VCs, and reputation data.
  • Off-chain storage setup and on-chain referencing (IPFS, Arweave).
  • Testing of the DID creation, VC issuance, and reputation score tracking.

Milestone 3: zk-SNARK Integration with Midnight55,000 ADA

  • Full integration of zk-SNARKs into the framework using Midnight.
  • Smart contract logic for selective disclosure of credential attributes.
  • Implementation of reputation verification using zk-SNARKs.
  • Testing and validation of zk-SNARK-based proofs in a test environment.

Milestone 4: Integration with Third-Party dApps25,000 ADA

  • Integration of the DID framework with at least 2 dApps to demonstrate ZKP-based identity verification.
  • Testing and implementation of dApp interactions.

Milestone 5: Project Close-Out Report10,000 ADA

  • Comprehensive project report summarizing achievements, challenges, and recommendations.
  • Documentation and publishing of code and deliverables.

We have calculated with an hourly rate of 75 USD (at 1 ADA = 0,4 USD).

Currently (as of October 24), Midnight is only available on the Testnet. In order to fully launch our proposed framework Midnight needs to be available on the Mainnet. We expect that to happen with the timeframe of our proposal.

How does the cost of the project represent value for money for the Cardano ecosystem?

  • Strategic Investment: The investment in this project represents substantial value for money by providing crucial improvements to zk protocols in Cardano.
  • Expertise and Complexity: Costs reflect fair compensation for specialized skills in data analysis and software development. The budget allocations align with prevailing rates in the industry, determined by the experience and skill set of professionals.
  • Risk mitigation: As a team, we willingly accept the currency risk of being paid in ADA, demonstrating our commitment and adaptability in a dynamic cryptocurrency environment. A decrease in the ADA price is a risk we bear, while any increase allows us to expand the scope.
close

Playlist

  • EP2: epoch_length

    Authored by: Darlington Kofa

    3m 24s
    Darlington Kofa
  • EP1: 'd' parameter

    Authored by: Darlington Kofa

    4m 3s
    Darlington Kofa
  • EP3: key_deposit

    Authored by: Darlington Kofa

    3m 48s
    Darlington Kofa
  • EP4: epoch_no

    Authored by: Darlington Kofa

    2m 16s
    Darlington Kofa
  • EP5: max_block_size

    Authored by: Darlington Kofa

    3m 14s
    Darlington Kofa
  • EP6: pool_deposit

    Authored by: Darlington Kofa

    3m 19s
    Darlington Kofa
  • EP7: max_tx_size

    Authored by: Darlington Kofa

    4m 59s
    Darlington Kofa
0:00
/
~0:00