Funding & Tokenization

Hypercerts track the funding of activities without prescribing how funds flow. Any payment technology works — credit cards, PayPal, bank transfers, onchain payments. Any funding mechanism works — grants, crowdfunding, retroactive funding, and more.

What hypercerts add is a structured, verifiable record of who funded what. Optionally, a hypercert can be wrapped in an onchain token, enabling programmable funding and transferable proof of contribution.

Funding tracking is available today. The tokenization layer is under active development. For what exists today, see Architecture Overview.

Hypercerts work with any funding mechanism

Funding can be prospective (before work begins) or retroactive (after outcomes are demonstrated). Different mechanisms suit different contexts, for example:

Multiple mechanisms can coexist for the same activity — a project might receive a grant prospectively and sell impact certificates retroactively. Hypercerts allows us to track it accurately without double counting.

Tracking funding

Hypercerts separate the tracking of funding from the flow of funds. Any existing funding infrastructure can work with hypercerts — the protocol simply records the fact that funding happened.

The protocol tracks funding through the org.hypercerts.funding.receipt record. A funding receipt records who funded which activity, how much, and when — creating a verifiable funding trail on ATProto.

The receipt references the activity claim it funds, linking the funding record to the work it supports.

The protocol does not enforce that projects or funders disclose their funding — creating a receipt is voluntary. Funders can also choose to remain anonymous in the public record; a receipt can track a contribution without revealing the funder's identity.

Who creates the receipt

How a funding receipt gets created depends on where the funding happens:

Self-reported receipts are the most accessible option — anyone can create one. But they carry less weight without independent verification. When a funder reports their own contribution, the project can confirm it (and vice versa), strengthening the credibility of the record.

Tokenization

Tokenization is under active development. This section describes the planned architecture.

A hypercert can optionally be wrapped in an onchain token. This gives funders a programmable proof of their contribution.

A token can represent either a mutable or a locked claim. If the underlying hypercert is locked before tokenization, funders get a stronger guarantee — the claim they reviewed is exactly the claim they funded, and it cannot change after the fact. If the claim is not locked (which can make sense for prospective funding, where the work hasn't happened yet), funders should be clearly informed that the data behind their token may still evolve.

Tokenization enables programmable funding — smart contract logic can enforce distribution rules, vesting schedules, matching formulas, and other mechanisms that would be difficult to coordinate offchain.

Example: from creation to funding

This example follows a hypercert through its lifecycle — from creation to funding, with optional tokenization.

Stage 1 — Creation and first evaluation

Alice plants 500 trees in a reforestation project and creates an activity claim on her PDS, along with measurements and evidence. Bob, an environmental auditor, evaluates the activity claim and its attached measurements of the new trees and evidence from his own PDS.

At this point, all records are mutable ATProto data. Alice can still update her claim, and Bob can revise his evaluation.

Stage 2 — Funding

Carol, a climate funder, reviews Alice's claim and Bob's evaluation. She decides to fund Alice's work through her organization's grant program. A funding receipt is created on ATProto, recording Carol's contribution and referencing Alice's activity claim.

The receipt links to Alice's activity claim, creating a verifiable record that Carol funded this work. The actual payment — whether by bank transfer, credit card, or any other method — happens outside the protocol.

Stage 3 — Lock and tokenize (optional)

Alice can lock the hypercert by wrapping it in an onchain token or anchoring it onchain without a token. This can happen at any time; a good time to do so is when the actual work is completed.

If she creates a token, she can distribute some to Carol in recognition of her earlier funding. Another funder, Dave, can then fund the activity by acquiring tokens — directly receiving proof of his contribution.

Stage 4 — Retroactive funding

Two years later, a second evaluator assesses the health of Alice's trees and publishes a positive evaluation. Eve, a climate funder focused on proven outcomes, sees the original claim, both evaluations, and Carol's earlier funding. She decides to fund the project retroactively — either through a new funding receipt referencing the same activity claim, or by acquiring tokens if the hypercert was tokenized.

What this enables

See also

• Architecture Overview — how the full protocol stack fits together
• Data Flow & Lifecycle — how a hypercert moves through the system
• The Hypercerts Infrastructure — the two-layer architecture
• Roadmap — current build priorities and development phases