> For the complete documentation index, see [llms.txt](https://docs.gotproof.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.gotproof.xyz/use-cases.md).

# Use Cases

This page maps common real-world flows to **what $PROOF verifies** and **how to audit it**.

Each use case follows the same pattern:

1. **Create metadata** (context, receipts, IDs).
2. **Commit** (hash or Merkle root).
3. **Anchor** (Solana transaction signature).
4. **Expose** (public reference + optional broadcast).

{% hint style="info" %}
Treat numbers and entities below as **illustrative** unless linked to a specific public proof.
{% endhint %}

### 1) Donation verification (creator payouts)

**Problem:** donors want proof the money actually reached the creator.

**Actors**

* Donor (crypto)
* Platform (Twitch / Patreon / YouTube / GoFundMe / etc.)
* Creator (often fiat-native)

**Inputs**

* pledge amount/asset (e.g., `USDC 500`)
* platform reference (`campaignId`, `payoutId`, `receiptId`)
* optional conversion context (`USD` settlement)

**Outputs**

* `txSignature` anchoring the donation proof
* public verification object (URL + commitment hash)

**What an auditor verifies**

* anchor is finalized (`txSignature`)
* commitment matches metadata (re-hash)
* metadata links to the platform payout reference

<figure><img src="/files/82oHdJ3pdDoNrRkFbBok" alt=""><figcaption><p>Donation verification: pledge → commitment → on-chain anchor → public reference.</p></figcaption></figure>

{% code title="donation-proof.json (illustrative)" %}

```json
{
  "subject": { "type": "payment", "id": "gofundme:payout_8c1…" },
  "amount": { "asset": "USDC", "quantity": "500.00" },
  "fiat": { "currency": "USD", "amount": "500.00" },
  "txSignature": "<SIG>",
  "commitment": { "type": "sha256", "value": "b3f1…" }
}
```

{% endcode %}

***

### 2) Enterprise payroll (stablecoin rails + audit trail)

**Problem:** payroll needs speed, predictable settlement, and auditability.

**Actors**

* Employer treasury
* Employees (wallet or custodial account)
* Optional: fiat off-ramp provider

**Typical model**

* payroll is represented as a **batch**
* each line item becomes a **leaf**
* the batch anchor stores/references a **Merkle root**

**What gets anchored**

* batch root commitment
* optional: payout execution signatures (per transfer)

**Auditor checklist**

* batch anchor exists + is finalized
* each employee line item proves membership in the batch (Merkle proof path)
* totals match internal payroll register

{% hint style="warning" %}
If you claim “proof of reserves”, you must define **scope** (which accounts) and **custody model** (who controls keys).
{% endhint %}

***

### 3) Asset tokenization (RWA + on-chain ownership state)

**Problem:** prove who owns what, and when ownership changed.

**Actors**

* Issuer / SPV / custodian
* Owners (wallets / custody accounts)
* Auditors / investors

**What gets anchored**

* asset metadata commitment (legal docs, appraisals, disclosures)
* ownership state transitions (transfers, burns, re-issuance)

**Auditor checklist**

* asset ID (mint/registry) is canonical
* ownership transitions are backed by successful Solana transactions
* metadata commitment matches the published asset docs

{% code title="asset-ownership.json (illustrative)" %}

```json
{
  "subject": { "type": "ownership", "id": "<MINT_OR_REGISTRY>" },
  "owner": "<WALLET_OR_CUSTODY_ACCOUNT>",
  "txSignature": "<SIG>",
  "commitment": { "type": "sha256", "value": "2a9d…" }
}
```

{% endcode %}

***

### 4) CAPEX tracking (treasury spend + misuse prevention)

**Problem:** prevent “trust me” spending. Make budgets enforceable and auditable.

**Actors**

* Treasury / finance team
* Vendors and recipients
* Governance / stakeholders

**What gets anchored**

* per-payment anchors (for large items)
* batch anchors (for high volume)
* optional: reserve snapshots (for “runway” and custody claims)

**Auditor checklist**

* treasury accounts are declared (scope)
* disbursements are consistent with approvals/policies
* reserve snapshots are reproducible (balance queries + commitment)

#### Minimal RPC check: anchor finality

{% code title="getSignatureStatuses (cURL)" %}

```bash
curl https://api.mainnet-beta.solana.com \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc":"2.0",
    "id":1,
    "method":"getSignatureStatuses",
    "params":[["<TX_SIGNATURE>"], {"searchTransactionHistory": true}]
  }'
```

{% endcode %}

{% hint style="success" %}
**Pass condition:** signature exists and is `finalized` (or meets your confirmation policy).
{% endhint %}


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.gotproof.xyz/use-cases.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.