Overview
A hypercert is an open, on-chain certificate of impact: a token that states that a specific piece of work was done, by whom, over what time period, and toward what goal. It is not itself a funding mechanism – it is the shared accounting layer that funding mechanisms point at. The name is a contraction of "hyperstructure certificate," and the pitch is that public-goods work should have a durable, transferable record the same way a company's output has equity.
The primitive was introduced by David Dalrymple at the Funding the Commons conference in June 2022 and written up by Protocol Labs in August 2022. It sits directly upstream of the retroactive public goods funding experiments run by Optimism and Gitcoin: those programmes need a canonical object to reward, and a hypercert is designed to be that object.
How a hypercert works
Each hypercert is an ERC-1155 semi-fungible token whose claim data lives as metadata on IPFS. The claim is structured along a fixed set of dimensions, so two hypercerts can be compared, merged, or split without ambiguity. Per the Protocol Labs specification, a claim records:
- Scope of work – what was actually done.
- Time of work – the period over which the work happened.
- Contributors – the accounts credited for it.
- Scope of impact and time of impact – what the work is claimed to have affected, and when.
- Rights – what a holder of the certificate is actually entitled to (e.g. the right to claim credit for retroactive funding).
Because the token is semi-fungible, a single claim can be fractionalized and its fractions sold to, or held by, many funders – and hypercerts can be split and merged along those dimensions, so multiple backers can support distinct slices of one project's impact. The design is deliberately mechanism-agnostic: hypercerts are meant to feed "private sales, public auctions, expert panels, and quadratic voting systems" alike, avoiding a new silo for every funding round.
The retroactive-funding thesis
Hypercerts exist to make one idea practical: it is easier to agree on what was useful than to predict what will be. Retroactive funding pays for outcomes after they land rather than proposals before they start – the same "results, not promises" logic Vitalik Buterin and others set out in the original retroactive public goods funding essay. The catch is a coordination gap: a builder who works now on the expectation of being paid later needs a credible, non-duplicable record that they did the work. As the Protocol Labs write-up puts it, "if you can reasonably expect to get funded retroactively for your work once you produce a positive impact, then you can work now, in expectation of a probabilistic future cash flow."
A hypercert is that record. It turns a diffuse "we did some good" into an ownable, auditable claim that a later retro round – or a market, or a panel – can price. It also gives the record persistence: once minted, an impact claim is not forgotten when the round that might have funded it moves on.
Where it is used
The clearest adopters are the public-goods funders whose whole model depends on rewarding realized impact:
- Gitcoin. Gitcoin ran a GreenPill hypercerts experiment to fund chapter activity, and its Grants 24 round (donations Oct 14–28, 2025) offered "peer-reviewed hypercerts" as one of the round-specific mechanisms allocators could choose, alongside quadratic funding and conviction voting.
- Celo Public Goods. Celo's public-goods programme uses hypercerts to represent claimed impact in its retroactive rounds, built on the same EasyRetroPGF tooling lineage.
- DeSci funders. The impact-certificate model is a natural fit for research, where a paper, dataset, or replication is a discrete unit of impact that funders may want to reward after the fact rather than via a grant proposal.
The protocol itself is stewarded by the Hypercerts Foundation and developed in the open at github.com/hypercerts-org.
Limits and open questions
A certificate standardizes the claim; it does not settle the hardest part, which is measuring impact and deciding who judges it. A hypercert can faithfully record that work happened without establishing that the work mattered, and the valuation step still falls to a market or an evaluator – exactly the load that overwhelmed human reviewers in Optimism's RetroPGF rounds. Fractionalization also invites speculation: if fractions trade freely, the price of a hypercert can drift toward what buyers expect it to be worth to future funders rather than its underlying impact, reintroducing the guess-the-future problem retro funding set out to avoid. Adoption, too, remains concentrated in the crypto public-goods niche rather than broad philanthropy. None of this is fatal – a shared, persistent record is genuinely useful – but a hypercert is best read as plumbing for impact funding, not a verdict on impact.
How Caper approaches this
Caper is a DAO protocol, not a grants programme, and it does not issue impact certificates or run retro rounds. But it shares the load-bearing instinct behind hypercerts: what you actually did, not what you promised or what you hold, should decide your claim.
In a caper, voting mints a non-transferable proof-of-vote token – an indivisible resource you cannot buy, sell, or be airdropped; it accrues only by having voted. Governance weight is then computed on-chain as (tokens held × your votes) / (vote supply × tokens in circulation), and the same figure sets your share of the treasury when you exit. Your participation record and your claim on the money are one number. Where a hypercert is a transferable, tradeable certificate of impact, Caper's is the opposite: an earned, soulbound record that cannot change hands. Both refuse to let a promise or a purchase stand in for a contribution – they just draw the line in different places, and Caper draws it so that the earned half of the product cannot be bought at any price. (Holdings are still a multiplicative factor, so capital counts; a large bag alone simply cannot capture control.)