Summary: Hypercerts is best understood not as a simple token format, but as a protocol for making impact work legible, portable, and fundable across applications. Its reusable mechanism is the separation of a living offchain record layer — claims, attachments, measurements, evaluations, contributions, and funding receipts — from an optional future onchain settlement layer. That makes Hypercerts a useful comparison class for retroactive public-goods funding, attestation systems, and any protocol that claims to turn messy real-world work into composable funding objects without locking users into one platform.
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 Hypercerts 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, which is the most important classification update versus older Hypercerts material
The protocol’s central mechanism is not retro funding by itself but a portable graph of claims, evaluations, evidence, and funding receipts that different applications can read and write through shared schemas
Hypercerts moved away from requiring wallets and gas for record creation by putting the data layer on AT Protocol, reserving onchain machinery for funding and settlement where immutability matters more
The lifecycle docs show that practical authority can migrate into relays, indexers, evaluators, funding facilitators, and rights-definition records, not just into whoever eventually wraps a claim onchain
Funding receipts are facilitator-created records rather than direct payment rails, which means Hypercerts is trying to standardize funding evidence and attribution more than custody or settlement itself
Legacy documentation still describes Hypercerts as an ERC-1155 semi-fungible token with IPFS metadata, which is analytically useful because it shows the project has evolved from an onchain impact-certificate primitive toward a broader open-context data protocol
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.