The product

Hapybara is an identity and credential layer that lets institutions issue verifiable digital diplomas and memberships, and lets individuals hold and reuse them across many contexts.

At the core, Hapybara follows the standard verifiable credentials (VC) model:

• Issuer – an authorized organization (university, accelerator, licensing body) that issues a credential.

• Holder – the individual who stores that credential in a wallet they control.

• Verifier – a relying party (employer, landlord, community, fund) that checks the credential against the issuer’s public key and revocation status.

The SSI (self-sovereign identity) implementation enables credentials to be bound to a user-controlled identifier, not to a specific vendor. Practically, that means:

• Users don’t have to re-upload the same documents to every school, employer, or Discord server.

• Issuers can publish, update, or revoke credentials without sending PDFs around.

• Verifiers get a yes/no + minimal attributes, instead of raw PII.

In this model, credentials are encoded following the W3C Verifiable Credentials model, signed by the issuer’s key. A blockchain (e.g., Ethereum) is used as a registry of issuer keys and schemas and a  revocation / status log.

We opt to implement issuer identities and registries using ERC-725/735, but these are internal details. For schools and employers, the visible behavior is:

• “Issue credential” → Hapybara generates and signs a VC, registers its status on the ledger, and hands the credential to the student’s wallet.

• “Verify credential” → the verifier checks the signature against the issuer’s registered key and consults the status list for revocation or expiry.

The ledger is there to make trust auditable and portable. Hapybara’s design is “on-chain proofs, off-chain data”:

• Sensitive artifacts—government IDs, selfie/face biometrics, transcripts—are never stored on-chain.

• They live in encrypted form in off-chain storage (e.g., IPFS-like or other object stores), with access controlled by the holder and issuer.

• Strong encryption (e.g., AES-256 for data at rest, public-key crypto for sharing) protects documents; the ledger only stores minimal references and status flags.

Where appropriate, selective disclosure and zero-knowledge proofs can be used so verifiers see only what their policy requires.

On the user side, we abstract away the SSI machinery. Students sign up using their .edu email and a passkey-style login (WebAuthn / device biometrics). Behind the scenes, Hapybara provisions a custodial smart wallet for each user (via account abstraction such as EIP-4337 or an equivalent pattern). When they “present” a credential, it feels like “Continue with school account” or “Share proof with employer” in one tap consent, no seed phrase, no gas, no jargon.

For advanced users or later phases, credentials can be exported to self-custodial wallets without changing how verifiers integrate.

Verifiers always see the same verification flow: a signed proof from a recognized issuer and a status check in the registry.

Once users hold reusable credentials (program, cohort, club, licenses, accreditation), those same proofs can unlock other networks:

• Portable proofs across tools.
  A user verifies once, then passes gates in Slack, Discord, Notion, job boards, or background checks without re-uploading documents each time.

• Minimal disclosure.
  Communities check “meets policy” (e.g., “current MBA”, “alumni of X”, “accredited investor”) instead of storing transcripts, SSNs, or passport scans.

• Multi-issuer, multi-verifier.
  Schools and licensing bodies can all issue credentials in a neutral, interoperable format; employers, funds, and communities consume them without custom one-off integrations per issuer.

• Revocation at scale.
  Issuers can update or revoke credentials (graduation verified, license lapsed, code-of-conduct breach), and relying parties see that status in real time instead of relying on stale PDFs.

The value proposition: one issued credential can be reused in many high-value contexts. From an institution’s perspective, Hapybara is an identity and credential rail that reduces repetitive verification work and PII sprawl. From a member’s perspective, it’s “verify once, then walk through more doors with fewer forms and access high-signal communities without noise.”

High level architecture

Hapybara separates what must be globally auditable (issuer trust, credential status) from what must remain private (documents, biometrics, detailed attributes). On-chain components handle trust and status; off-chain components handle data and UX.

On-chain components

User identifiers

Each user is associated with an EVM address that acts as their on-chain identifier.
In practice, most users do not interact with wallets directly. A smart-account / account-abstraction layer (e.g., EIP-4337 pattern) sits behind a standard login flow. For the initial student market:

• Users register with their .edu email.

• The platform verifies the email domain and binds the resulting identity to a smart account in the background.

• Sign-in feels like “Continue with school email,” not “Create a wallet.”

Over time, additional identity proofs (phone number, corporate email, social logins) can be bound to the same or related accounts without changing the verification flow for relying parties.

Issuer registry and credential status

A set of smart contracts maintains:

• The list of authorized issuers (universities, accelerators, licensing bodies).

• The public keys and metadata needed to verify their signatures.

• References to credential schemas and status lists (e.g., active, expired, revoked).

  When an institution is onboarded, its issuer entry is added or updated in the registry contract through an admin/governance flow.

   When credentials are issued or revoked, the issuer updates a status list (on-chain or anchored on-chain) so verifiers can check that a credential is still valid without calling the institution synchronously.

  No PII are stored on-chain; only identifiers, keys, hashes, and status flags.

Off-chain components

User identity and documents

Government IDs, facial biometrics (if used), transcripts, and other sensitive artifacts are stored off-chain. Storage is a combination of:

• Encrypted blobs in object storage or decentralized storage (e.g., IPFS-backed solutions).

• Application databases holding only the minimum metadata required for UX and auditing.

  Access to these documents is controlled by application-level access controls for custodial flows, and cryptographic access controls where users or institutions encrypt data for specific verifiers.

  Credential payloads (the VC JSON) are also off-chain; on-chain entries only anchor their existence and status.

Issuer and verifier services

Issuer dashboards and APIs:

• Allow institutions to create, sign, and update verifiable credentials.

• Manage issuer keys, schemas, and revocation events.

  Verifier APIs / SDKs:

• Accept a presented credential or proof.

• Validate signatures against the on-chain registry.

• Check status/revocation.

• Optionally enforce policy (e.g., degree type, date range) without exposing extra attributes to the verifier’s systems.

Security and consent model

Zero-knowledge / selective disclosure

For use cases that require minimal disclosure, the system can support:

• Proofs that a credential meets a policy (e.g., “Top-20 MBA graduate”) without revealing full transcripts or ID numbers.

• Attribute-level disclosure (e.g., degree type and graduation year, but not GPA).

  In early phases, this can start with simple selective-disclosure VC formats and evolve into full ZK circuits where justified by value and complexity.

Encryption

Data at rest off-chain is encrypted using modern symmetric algorithms (e.g., AES-256) with keys managed by the platform and, where appropriate, by the user. Data in transit uses TLS.
For high-sensitivity flows, public-key encryption can be used so only specific verifiers can decrypt specific payloads, even if stored in shared infrastructure.

Consent and revocation

Every verification flow is explicitly consent-based:

• The user sees what is being requested (e.g., “verify degree from X, year Y”).

• They approve or deny from their device.

  Issuers can revoke or expire credentials via the status registry; communities and employers see revocation in real time without holding their own copies of sensitive documents.
  Users can revoke previously granted application-level access (e.g., disconnect an app or integration), after which that app can no longer request fresh proofs.

Overall, the architecture keeps trust anchors and revocation globally visible on-chain, pushes all sensitive data off-chain with encryption, and hides cryptographic complexity behind familiar login and consent flows.

(Flawed) execution

We executed a rigorous discovery process, combining over 100 conversations with university administrators, IT staff managing SIS/credential systems, and MBA community organizers. This effort was designed to validate the initial assumptions and locate the highest-friction areas in the market.

Institutional constraints (The barrier to entry)

Conversations with university staff consistently confirmed the logic and long-term potential of a shared credential and verification layer, but established two non-negotiable constraints that prevented immediate adoption:

• Institutions are highly cautious about running a second system alongside their existing Student Information Systems (SIS) and credential vendors. The perceived administrative and security risk of a parallel platform was too high.

• No single school would be the sole adopter. They required definitive evidence that peers and downstream consumers (employers, background check vendors) were already committed to the platform. The bar for operational stability and security was exceptionally high.

Consumer-side pilots (The flawed wedge)

While there is a high demand to coordinate across different communities, coordination without identity-aware infrastructure is a known pain point. Within a single school, communication lives in Slack or similar workspaces. For cross-school or cross-community coordination, people fall back to email threads, shared Google Sheets, and WhatsApp or GroupMe chats. These tools are not designed for structured, cross-campus initiatives: conversations, files, and decisions are fragmented across channels, limiting the scale of cross-campus participation.

Assuming that driving adoption on the consumer side would compel institutional compliance, we decided to locate highest-friction cross-campus coordination use cases, with the aim to form an initial “atomic network” of multiple MBA programs. Our assumption: Once students were regularly using Hapybara to coordinate across schools, programs could begin issuing higher-value credentials (degrees, cohort memberships, club roles) on the same rails, which students would then share with employers and other verifiers.

We designed pilots to test if high-need cross-campus coordination could successfully drive platform adoption.

• The result: While users engaged with the platform initially to accomplish specific goals (e.g., securing housing, organizing trips), they quickly abandoned it after the goal was achieved (e.g., housing secured or trip concluded).

• The insight: These uses cases were transactional and time-bound, confirming that the platform lacked the stickiness necessary to establish a durable network and serve as the necessary “pull” for institutional adoption.

This failure to establish persistent usage confirmed the flaw in our consumer wedge, resulting in a loss of focus on our defensible core and the inability to secure follow-on funding.

Lessons learned

By misunderstanding where the defensible value lies and underestimating the difficulty of building a network, we led with a low-retention, non-essential social coordination feature that lacked stickiness instead of immediately anchoring the product on the high-value, B2B infrastructure problem of automated, verifiable credential issuance.

Building a separate social network required far more resources and complexity than we initially anticipated. We fell into the trap of a startup that tried to be to many things at once.

A better approach in retrospect

With hindsight, the durable asset was always the identity and credential infrastructure. The work that is painful and expensive at scale is:

• Degree and enrollment verification.

• Background checks that re-verify the same facts.

• Manual, repeated sharing of transcripts and documents across noisy vendor chains.

A more disciplined strategy would have looked like:

1. Lead with infra, not a social graph.
Anchor the product on a narrow, high-value problem: make verification between a small set of MBA programs and their top recruiters faster, cheaper, and less manual. The “interesting” part is the SSI / VC plumbing; the sellable part is reduced cycle time and fewer tickets.

2. Integrate into the existing stack instead of running in parallel.
Rather than trying to pull schools into a new front-end platform, a better approach is to build a connector that pulls data where the institution already pushes it, or to focus on APIs designed for external vendors. That lets institutions adopt gradually, without asking them to discard sunk investments or retrain teams on a new system.

3. Define a very small but complete “atomic network.”

Instead of chasing a large, simultaneous launch (e.g., “six M7s all at once”), we should have focused on securing a tight, end-to-end circuit that proves repeatable value.

The school’s career/recruiting Slack gated by a bot that checks Hapybara proofs.

• A cross-school alliance that uses the same proof.
• A couple long-standing employers who agree to accept the credential for fast-track applications.

In fact, leveraging Chicago Booth as our home base, we should have focused on securing a lighthouse employer partner (e.g., a major consulting firm or investment bank that heavily recruits MBAs) willing to run a small “fast-track” pilot. This creates an immediate pull for both schools (as issuers) and students (as holders).

That gives one program and a couple of employers all using the same credential in different contexts. It’s small, but it’s a full circuit.

Once a credential is actually useful in multiple high-value flows (eg. recruiting Slack, alliance events, fast-track hiring), other issuers and verifiers have a tangible incentive to join. The “atomic network” is then defined by repeated transactions.

4. Work with standards bodies and associations early.

Instead of selling to each school in isolation, we should have leaned into a partnership-forward GTM plan with bodies like AACSB and 1EdTech. They provide the third-party validation that reduces the M7 schools’ perception of risk and helps overcome the “no school wants to be the only adopter” problem.

5. “Gated Community” comes later to drive reuse

The consumer side – the gated community features for MBA students – is an essential component, but its function should be viewed as a “Network Effect Engine” built on top of the infrastructure, not the infrastructure itself.

The community use case is necessary to complete the value circuit that locks in the initial institutional and employer partners. Attempting the community side first, as the initial GTM plan showed, fails because the community features are only defensible when they are tied to a verifiable, external identity source.

other projects