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).

Treat numbers and entities below as illustrative unless linked to a specific public proof.

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

Donation verification: pledge → commitment → on-chain anchor → public reference.

donation-proof.json (illustrative)

{
  "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…" }
}

---

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

If you claim “proof of reserves”, you must define scope (which accounts) and custody model (who controls keys).

---

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

asset-ownership.json (illustrative)

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

---

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

getSignatureStatuses (cURL)

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}]
  }'

Pass condition: signature exists and is finalized (or meets your confirmation policy).