The product

Hapybara offers a decentralized application (DApp) that allows schools to issue digital diplomas, giving students full control over how they access and manage their credentials. Unlike traditional credential management systems that store student data in centralized databases, Hapybara leverages the Self-Sovereign Identity (SSI) model, which enables students to own and control their identification data. With SSI, individuals no longer need to rely on third parties to store or verify their credentials, significantly reducing inefficiencies and the need for repetitive re-verification that occurs in traditional models. 

Institutions can issue verifiable digital credentials using the ERC-725 or ERC-735 standard (both are identity-related token standards) on the Ethereum blockchain. These tokens contain metadata pointing to off-chain data storage, including credential details and cryptographic proofs of authenticity. By using blockchain technology and zero-knowledge proofs (zk-proof), Hapybara ensures that user profiles are stored securely in a decentralized registry, while sensitive information remains confidential. This eliminates the risk of data breaches common in centralized systems, all while maintaining privacy. Moreover, SSI empowers students to share their credentials with employers or other institutions easily, without needing to rely on intermediaries for verification, reducing time and administrative burdens. 

To protect user privacity, sensitive identity documents, such as government-issued IDs and facial recognition data, are stored off-chain in decentralized storage networks like IPFS in private, encrypted databases with strong encryption standards (e.g., AES-256 or RSA).

The verifiable credentials ecosystem

1. Issuer: An authorized organization, such as a government department or a college, that issues Verifiable Credentials.
2. Holder: The individual who owns and stores the credential in their digital wallet.
3. Verifier: An entity, like a hiring company, responsible for validating the credential.

Hapybara verifies users’ identities through government-issued IDs and facial recognition during profile creation. Users can enhance their profiles by adding institutional affiliations, such as schools or employers, which are verified by the respective issuers on the platform. This verified affiliation enables users to join closed networks with similar communities. 

By providing a platform for users to store and manage their educational and professional credentials, Hapybara eliminates cumbersome verification requests for both users and institutions. Institutions can opt into the platform’s digital credential authentication service, reducing administrative burdens and enhancing efficiency. Employers can verify employee credentials, while residential buildings can confirm tenant history and rent payments. Once authenticated, users gain lifelong access to their credentials, which they can share at their discretion, as well as access to the inter-community networks.

To ensure a smooth user experience, account abstraction would be used to simplify onboarding experience. Our initial market consisting primarily of students will be required to register with their .edu email. The platform integrates a .edu email verification process with account abstraction (EIP-4337), allowing users to authenticate with their institutional identity without needing to manage a wallet or private keys. For later pilots, we will open registration to other verification methods such as phone number and other social accounts.

Unlike traditional players like Parchment and background check services that rely on centralized systems, Hapybara differentiates itself through its decentralized, privacy-preserving approach. By utilizing blockchain for credential storage and zk-proofs for verification, Hapybara provides students and institutions with a secure, transparent, and efficient alternative that ensures both data integrity and privacy. 

Execution

We conducted over 100 interviews across different user segments, including school administrators, students and community organizers. These conversations provided a deep understanding of the challenges faced by both B2C users (students/community organizers) and B2B institutional customers (administrators). From this research, we gained crucial insights into the inefficiencies in both the credential management process and cross-campus coordination.

Admin and IT Staff Interviews
We began by interviewing school administration teams to identify pain points with existing systems. While administrators were impressed with the platform’s potential, they expressed hesitancy about managing two separate systems unless other schools or entities also adopted it. A major barrier identified was the need for simultaneous adoption across multiple institutions to ensure widespread use.

Student Interviews
In the second wave of interviews, we spoke with MBA students to gain insights into the most compelling use cases for the consumer side. 

Based on these insights, we ran a few pilot programs focused on different cross-campus needs.

Pilot 1: Cross-campus housing subleases and exchanges

The first pilot was around summer housing coordination, when a lot of students relocate temporarily for internships. Since the MBA networks have a Google spreadsheet for this purpose, we gave ourselves a challenge to expand this existing network. Piggyback on the housing spreadsheet, we link to the “channels” created for various cities on our platform. Despite initial interest, students quickly disengaged after solving their immediate housing needs. Many reverted to using familiar tools like email or social media to communicate. 

Pilot 2: Cross-campus networking trips

After the first pilot failed, we conducted further research and brainstorming to refine our approach for the second pilot. We identified student trip leaders—those organizing large, multi-school trips and events for their peers—as our most promising early adopters. These leaders required a reliable, user-friendly platform to streamline the complex logistics involved in planning these trips.

Before using our platform, trip leaders managed logistics manually, relying on fragmented tools like Slack and email threads. Our platform’s centralized solution for managing RSVPs, travel details, and communication provided a significant improvement in efficiency and ease of use for these events.

To launch the second pilot, we created a sign-up page on our website and reached out to student group leaders across various MBA programs. This outreach helped us form a community of like-minded individuals who were more likely to join trips together. The student group leaders played a key role in promoting the pilot through their schools’ Slack channels, further driving awareness. As each trip attracted multiple participants, the user base grew organically, with students engaging to stay updated on trip-related details.

For each pilot and experiment, we utilized the Google Design Sprint methodology to generate initial concepts. We then validated our core value proposition—connecting groups across different campuses—through a beta launch, leveraging our website, a simple sign-up page, input form, email marketing, and other communication tools that MBA students use like Slack and Whatsapp. The project began as a web-based platform built to support student networking and event management, with initial features like housing coordination and event management, aiming to create a strong user base across multiple programs. As MBA programs are onboarded as credential issuers, decentralized identity standards and wallets would be integrated.

Lessons learned

Our initial approach encountered significant challenges. The use cases we targeted lacked stickiness. While users would engage with the platform initially to accomplish specific goals—such as securing housing or organizing trips—they quickly abandoned it after housing secured or trip concluded. We were unable to alter these ingrained user habits, which led to a drop in retention and overall engagement. In the end, we couldn’t secure funding. A key takeaway was that building a separate social network required far more resources and complexity than we initially anticipated. In essence, we fell into the trap of a startup that tried to be to many things at once.

A better approach in retrospect

Looking back, we realized that the core value proposition was the identity solution, not the social network. Instead of focusing on creating a new social layer, we should have prioritized building a robust Self-Sovereign Identity (SSI) platform that could address the most pressing issue: the slow, manual processes that schools and students face in credential verification, background checks, and other administrative workflows.

Had we concentrated on enterprise sales to educational institutions and offered a top-down adoption strategy, we could have more effectively solved schools’ pain points. We could have integrated the SSI solution with existing legacy systems—such as academic records vendors and background check platforms—allowing institutions to adopt the technology gradually without disrupting their current processes. Focusing on streamlining the fragmented and manual process of degree verification, credential sharing, and student data management among the different vendors would have made our positioning more attractive. 

Instead of focusing exclusively on creating an atomic network of MBA schools, we could have formed the atomic network by streamlining the credential management process between long-time employers involved in on-campus recruiting and the MBA program. 

Moreover, collaborating with accreditation bodies or forming partnerships with higher education associations could have helped establish the platform as a recognized standard for digital credentials. 

In hindsight, our focus should have been on solving the most critical pain points with a powerful identity solution that would be indispensable for educational institutions and employers alike. The lesson here is clear: start with the fundamental value proposition and build from there, rather than overextending into adjacent, resource-intensive areas.

other projects