Rewrite Funding & Tokenization page

documentation/lib/navigation.js

@@ -34,7 +34,7 @@ export const navigation = [
       },
       { title: 'Architecture Overview', path: '/architecture/overview' },
       { title: 'Data Flow & Lifecycle', path: '/architecture/data-flow-and-lifecycle' },
-      { title: 'Funding & Tokenization', path: '/architecture/planned-funding-and-tokenization' },
+      { title: 'Funding & Tokenization', path: '/architecture/funding-and-tokenization' },
     ],
   },
   {

documentation/pages/architecture/data-flow-and-lifecycle.md

@@ -19,7 +19,7 @@ Every hypercert follows a similar path through the system, though the timeline a
 
 **Discovery** makes the hypercert findable. Relays aggregate records from many servers. Indexers build searchable databases. Platforms query indexers to surface hypercerts to users.
 
-**Funding** connects ownership to the claim. The on-chain funding layer is [planned but not yet implemented](/architecture/planned-funding-and-tokenization). The intended design freezes ATProto records before funding to ensure funders know exactly what they are paying for.
+**Funding** connects ownership to the claim. The on-chain funding layer is [planned but not yet implemented](/architecture/funding-and-tokenization). The intended design freezes ATProto records before funding to ensure funders know exactly what they are paying for.
 
 **Accumulation** continues indefinitely. More evaluations arrive. Additional evidence gets attached. The data layer continues evolving.
 
@@ -29,7 +29,7 @@ Creation → Enrichment → Evaluation → Discovery → Funding → Accumulatio
   PDS      PDS/SDS      Other PDS     Indexer   On-chain*   Ongoing
 ```
 
-*On-chain layer is planned. See [Planned: Funding & Tokenization](/architecture/planned-funding-and-tokenization).
+*On-chain layer is planned. See [Funding & Tokenization](/architecture/funding-and-tokenization).
 
 ## Stage 1: Creation
 
@@ -149,7 +149,7 @@ Many PDS Instances
 
 The on-chain funding layer is not yet implemented. The planned design: before a hypercert can be funded, its ATProto records are frozen and the snapshot is anchored on-chain. This ensures funders know exactly what they are paying for — the cert's contents cannot change after freezing.
 
-For the full planned design — including anchoring, tokenization, funding mechanisms, and funding readiness patterns — see [Planned: Funding & Tokenization](/architecture/planned-funding-and-tokenization).
+For the full planned design — including anchoring, tokenization, funding mechanisms, and funding readiness patterns — see [Funding & Tokenization](/architecture/funding-and-tokenization).
 
 ## Stage 6: Accumulation
 

documentation/pages/architecture/funding-and-tokenization.md

@@ -0,0 +1,136 @@
+---
+title: "Funding & Tokenization"
+description: How hypercerts track funding of activities and optionally wrap claims in onchain tokens.
+---
+
+# 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.
+
+{% callout type="note" %}
+Funding tracking is available today. The tokenization layer is under active development. For what exists today, see [Architecture Overview](/architecture/overview).
+{% /callout %}
+
+---
+
+## 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:
+
+| Mechanism | Description | Timing |
+|-----------|-------------|--------|
+| **Grant funding** | Funders award grants to support planned activities | Prospective |
+| **Milestone-based funding** | Funds are released as work reaches defined milestones | Prospective |
+| **Prize competitions** | Awards for achieving specific outcomes | Retroactive |
+| **Quadratic funding** | Small donations amplified through matching pools | Either |
+| **Sale of impact certificates** | Funders purchase certificates representing completed work | Either |
+| **Auction of impact certificates** | Competitive bidding on verified impact claims | Retroactive (mainly) |
+
+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:
+
+| Scenario | Who creates the receipt | Verification |
+|----------|------------------------|--------------|
+| **Onchain funding** | The funding transaction is linked directly in the receipt (transaction hash, chain ID) | Verifiable onchain |
+| **Third-party oracle** | An intermediary — a payment processor, grant platform, or fiscal sponsor — creates the receipt on behalf of the funder | Trust in the oracle |
+| **Self-reported** | The project or funder creates the receipt themselves | Ideally verified by the counterparty |
+
+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
+
+{% callout type="note" %}
+Tokenization is under active development. This section describes the planned architecture.
+{% /callout %}
+
+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.
+
+| Property | Detail |
+|----------|--------|
+| **Token standards** | ERC-20, ERC-1155, or custom — different standards on different chains |
+| **Transferability** | Ranges from non-transferable recognition to fully transferable certificates |
+| **Single-wrap constraint** | Every claim can only be wrapped in a token once, preventing double counting |
+| **Rights** | Optional definition of the rights of the owners, set in the hypercert's `org.hypercerts.claim.rights` record |
+
+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.
+
+| Record | Owner | Location |
+|--------|-------|----------|
+| Activity claim | Alice | `at://did:plc:alice/org.hypercerts.claim.activity/3k7` |
+| Measurement | Alice | `at://did:plc:alice/org.hypercerts.claim.measurement/5m1` |
+| Evidence | Alice | `at://did:plc:alice/org.hypercerts.claim.evidence/7e4` |
+| Evaluation | Bob | `at://did:plc:bob/org.hypercerts.claim.evaluation/9x2` |
+
+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.
+
+| Record | Owner | Location |
+|--------|-------|----------|
+| Funding receipt | Carol | `at://did:plc:carol/org.hypercerts.funding.receipt/2f8` |
+
+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
+
+| Capability | Description |
+|------------|-------------|
+| **Works with any funding mechanism** | Any payment method works — the protocol tracks the funding, not the payment |
+| **Prospective and retroactive funding** | Fund planned work or reward demonstrated outcomes |
+| **Composable mechanisms** | Different funding models operate on the same underlying data |
+| **Portable proof of funding** | Funders can prove what they funded, whether onchain or off |
+| **Independent evolution** | Data and ownership layers evolve separately — evaluations accumulate on ATProto while ownership transfers onchain |
+
+---
+
+## See also
+
+- [Architecture Overview](/architecture/overview) — how the full protocol stack fits together
+- [Data Flow & Lifecycle](/architecture/data-flow-and-lifecycle) — how a hypercert moves through the system
+- [The Hypercerts Infrastructure](/getting-started/the-hypercerts-infrastructure) — the two-layer architecture
+- [Roadmap](/roadmap) — current build priorities and development phases

documentation/pages/architecture/overview.md

@@ -5,7 +5,7 @@ description: How the Hypercerts Protocol stack fits together.
 
 # Architecture Overview
 
-The Hypercerts Protocol uses AT Protocol for data portability. On-chain anchoring for ownership and funding is [planned](/architecture/planned-funding-and-tokenization).
+The Hypercerts Protocol uses AT Protocol for data portability. On-chain anchoring for ownership and funding is [planned](/architecture/funding-and-tokenization).
 
 ## The Hypercerts Stack
 
@@ -15,7 +15,7 @@ The **Data Layer** is the foundation. AT Protocol stores claims, evidence, and e
 
 The **Application Layer** sits on top of the data layer. Funding platforms, dashboards, and evaluation tools live here. These applications read from and write to the data layer below.
 
-The **Ownership Layer** is planned but not yet implemented. The intended design uses a freeze-then-fund model where hypercerts are frozen and anchored on-chain before funding — ensuring funders know exactly what they are paying for. See [Planned: Funding & Tokenization](/architecture/planned-funding-and-tokenization) for details.
+The **Ownership Layer** is planned but not yet implemented. The intended design uses a freeze-then-fund model where hypercerts are frozen and anchored on-chain before funding — ensuring funders know exactly what they are paying for. See [Funding & Tokenization](/architecture/funding-and-tokenization) for details.
 
 ![The Hypercerts Stack](/images/architecture-stack.svg)
 
@@ -71,13 +71,13 @@ These properties combine into an auditable chain:
 
 ## Ownership Layer (Planned)
 
-The ownership layer is not yet implemented. The planned design freezes ATProto records and anchors them on-chain before funding, ensuring funders know exactly what they are paying for. For the full planned design — including anchoring, tokenization, and funding mechanisms — see [Planned: Funding & Tokenization](/architecture/planned-funding-and-tokenization).
+The ownership layer is not yet implemented. The planned design freezes ATProto records and anchors them on-chain before funding, ensuring funders know exactly what they are paying for. For the full planned design — including anchoring, tokenization, and funding mechanisms — see [Funding & Tokenization](/architecture/funding-and-tokenization).
 
 ## How the Layers Connect
 
 A hypercert's **content** lives on ATProto. The activity claim, evidence records, measurements, and evaluations are all ATProto records. This data is portable — users control it, can migrate it, and applications can read it without blockchain access.
 
-A hypercert's **ownership and funding state** will live on-chain once the tokenization layer is built. The planned bridge is a freeze-then-fund mechanism. See [Planned: Funding & Tokenization](/architecture/planned-funding-and-tokenization) for the full cross-layer design.
+A hypercert's **ownership and funding state** will live on-chain once the tokenization layer is built. The planned bridge is a freeze-then-fund mechanism. See [Funding & Tokenization](/architecture/funding-and-tokenization) for the full cross-layer design.
 
 {% callout type="note" %}
 The separation matters. ATProto provides data portability — users can switch servers, applications can read across the network, and records outlive any single platform. On-chain anchoring will provide ownership and funding guarantees. Neither layer can provide both properties alone.
@@ -93,7 +93,7 @@ Storing rich data on-chain is expensive. A single activity claim with evidence a
 
 #### Why Not Fully Off-Chain?
 
-Mutable records are fine for collaboration, but funding requires immutability. Without on-chain anchoring, there's no way to freeze a hypercert's state and guarantee that the claim a funder evaluates is the same claim they end up funding. Additionally, funding mechanisms like retroactive public goods funding require on-chain logic to distribute funds according to rules. See [Planned: Funding & Tokenization](/architecture/planned-funding-and-tokenization) for the planned freeze-then-fund design.
+Mutable records are fine for collaboration, but funding requires immutability. Without on-chain anchoring, there's no way to freeze a hypercert's state and guarantee that the claim a funder evaluates is the same claim they end up funding. Additionally, funding mechanisms like retroactive public goods funding require on-chain logic to distribute funds according to rules. See [Funding & Tokenization](/architecture/funding-and-tokenization) for the planned freeze-then-fund design.
 
 #### Why ATProto Over IPFS, Ceramic, or Other Alternatives?
 
@@ -109,17 +109,17 @@ Each layer does what it does best. ATProto handles identity, data portability, a
 
 **Cross-platform evaluation.** An evaluator on Platform A can assess a contribution created on Platform B. The evaluation is stored on the evaluator's PDS, references the original claim via AT-URI, and is visible to any application that queries the indexer. This works today with the ATProto data layer.
 
-**Retroactive funding.** Planned — see [Planned: Funding & Tokenization](/architecture/planned-funding-and-tokenization).
+**Retroactive funding.** Planned — see [Funding & Tokenization](/architecture/funding-and-tokenization).
 
 **Portable reputation.** A contributor's entire history — all claims, contributions, and evaluations — follows them across platforms. Their DID is the persistent identifier. Applications can compute trust scores based on the full history. This works today with the ATProto data layer.
 
-**Composable funding mechanisms.** Planned — see [Planned: Funding & Tokenization](/architecture/planned-funding-and-tokenization).
+**Composable funding mechanisms.** Planned — see [Funding & Tokenization](/architecture/funding-and-tokenization).
 
 ## Next Steps
 
 For a detailed walkthrough of how a hypercert moves through the system, see [Data Flow & Lifecycle](/architecture/data-flow-and-lifecycle).
 
-For the planned on-chain funding and tokenization design, see [Planned: Funding & Tokenization](/architecture/planned-funding-and-tokenization).
+For the planned on-chain funding and tokenization design, see [Funding & Tokenization](/architecture/funding-and-tokenization).
 
 To understand the specific record types and their schemas, see [Introduction to Lexicons](/lexicons/introduction-to-lexicons).