Funding & Value Flow

Hypercerts track the funding of activities without prescribing how funds flow — any payment method and any funding mechanism works.

What hypercerts add is a structured, verifiable record of who funded what.

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 tracks this accurately without double counting: every funding receipt references the specific activity claim it funds, making it possible to compute total funding per claim across all receipts.

Tracking funding#

Hypercerts separate the tracking of funding from the flow of funds. Any existing payment 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. The receipt references the activity claim it funds, linking the funding record to the work it supports.

Funding receipts are typically created by a facilitator — a payment processor, grant platform, funding app, or other intermediary that processes the payment and creates the receipt. The facilitator acts as a neutral third party, giving the receipt more credibility than a self-reported claim.

The funder or the contributor can then create an acknowledgement — a counter-signature confirming the receipt's accuracy — to strengthen its credibility.

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.

Tokenization#

A hypercert can optionally be wrapped in an on-chain token. This gives funders a programmable proof of their contribution. Tokenization is an optional wrapper around a claim snapshot; the canonical record remains the AT Protocol data.

When locking is available, a claim can be frozen before tokenization. This gives funders a stronger guarantee — the claim they reviewed is exactly the claim they funded, and it cannot change after the fact.

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

Example: from creation to funding#

There are many different flows that can be represented with hypercerts. Below is one example that follows a hypercert from creation to funding.

Stage 1 — Creation and evaluation#

Alice plants 500 trees in a reforestation project and creates an activity claim with measurements and attachments. Bob, an environmental auditor, evaluates the claim from his own PDS. See Quickstart for a walkthrough.

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 platform. The payment facilitator processes the payment and creates a funding receipt, recording Carol's contribution and referencing Alice's activity claim.

Either party can then create an acknowledgement — a counter-signature confirming the receipt's accuracy — to strengthen its credibility.

Stage 3 — Locking#

Alice locks the claim, freezing it so its contents can't change. This gives future funders a guarantee — the claim they review is exactly the claim they'll be funding.

Stage 4 — Retroactive funding#

Two years later, Eve assesses the health of Alice's trees and publishes a positive evaluation. Grace, a climate funder focused on proven outcomes, sees the original claim, both evaluations, and Carol's earlier funding. She funds the project retroactively with a new funding receipt referencing the same activity claim.

See also#

• Architecture Overview — how the full protocol stack fits together
• Data Flow & Lifecycle — how a hypercert moves through the system