Hypercerts

  • Name: Hypercerts
  • URL: https://hypercerts.org/
  • Category: impact-funding data protocol / retrospective-reward infrastructure / evaluation-and-funding context layer
  • Summary: Hypercerts is now mostly an impact-record protocol with optional future tokenization, not a live onchain funding primitive. The useful surface is claims, evaluations, rights records, and funding receipts moving through AT Protocol.
  • What it does:
    • Lets contributors create structured activity claims describing who did what work, when, and where, then enrich those claims over time with attachments, measurements, contribution records, and rights records
    • Lets third parties publish independent evaluation records from their own servers, so trust and assessment accumulate around the claim instead of staying trapped inside one funding app
    • Tracks funding through funding-receipt and acknowledgement records that reference specific claims, creating a verifiable trail of who funded what without forcing one payment rail or one funding mechanism
    • Uses AT Protocol repositories, DIDs, strong references, relays, and indexers so records can move across apps and servers while remaining signed and portable
    • Plans an optional onchain tokenization / locking layer for cases where immutable claim snapshots and programmable settlement matter, while keeping the richer record layer offchain
    • Maintains protocol, docs, and code repositories that show both a current ATProto-based design and legacy onchain-token history
  • Key claims:
    • Current docs explicitly say a hypercert is a living record of impact work, not merely a token, and that tokenization is planned but not yet implemented. That is the main classification update.
    • The real mechanism is a portable graph of claims, evaluations, evidence, rights records, and funding receipts that different applications can read and write through shared schemas.
    • Hypercerts moved record creation off wallets and gas by putting the data layer on AT Protocol, leaving onchain machinery as a later settlement or tokenization option rather than the current core product.
    • Practical authority can migrate into relays, indexers, evaluators, funding facilitators, and rights-definition records, not just whoever might later wrap a claim onchain.
    • Funding receipts are evidence records, not payment rails. Hypercerts is standardizing attribution and context more than custody or settlement.
    • The old ERC-1155 framing still matters mostly as lineage. The sharper current read is open impact-data plumbing.
  • Whitepaper: Hypercerts publishes current protocol docs plus historical whitepaper / documentation material, but the most useful primary-source packet for this pass is ../whitepapers/hypercerts-primary-sources-2026-05-09.md because the project is in transition between legacy token-centric materials and the newer ATProto-based design.
  • Sources:

Internal linkages

Control surface

  • Power sits with schema and record conventions, relays and indexers, evaluator adoption, funding-facilitator behavior, and any future tokenization wrapper that turns records into harder settlement objects.

  • Read Hypercerts as impact-context and attribution plumbing, not as a payment rail.

  • Last reviewed: 2026-06-12 UTC