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.mdbecause the project is in transition between legacy token-centric materials and the newer ATProto-based design. - Sources:
- https://hypercerts.org/
- https://docs.hypercerts.org/
- https://docs.hypercerts.org/core-concepts/what-is-hypercerts
- https://docs.hypercerts.org/core-concepts/hypercerts-core-data-model
- https://docs.hypercerts.org/core-concepts/why-at-protocol
- https://docs.hypercerts.org/core-concepts/funding-and-value-flow
- https://docs.hypercerts.org/architecture/data-flow-and-lifecycle
- https://github.com/hypercerts-org
- https://raw.githubusercontent.com/hypercerts-org/hypercerts-protocol/main/README.md
- https://network-goods.github.io/hypercerts-docs/
Internal linkages
- Best upward reads: allo-protocol for funding workflow and ethereum-attestation-service for the broader shared-claims rail.
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