# Core Capabilities This page defines **what $PROOF does** and **what gets anchored on-chain**. You can read it as: * **Integrator view**: inputs/outputs + where to plug in. * **Auditor view**: what to fetch from chain + what to validate.
### Capability map (3 domains) * **Spend Verification**: subscriptions, invoices, payroll lines, high-volume payouts. * **Asset Ownership**: tokenize + track ownership and transfers (RWA or on-chain assets). * **CAPEX Management**: treasury ops, proof-of-reserves, on-chain disbursement controls. {% hint style="info" %} All three domains rely on the same idea: **off-chain context** becomes **tamper-evident** via an **on-chain anchor** (signature + commitment hash). {% endhint %} ### Shared primitives (used everywhere) #### 1) On-chain anchor At minimum, a verification should reference: * **Network** (Solana-first) * **Transaction signature** (canonical pointer) * **Commitment** (hash or Merkle root that binds metadata)
#### 2) Minimal record shape (illustrative) Use this shape in your own systems. Treat it as a *contract you control*. {% code title="verification-record.json" %} ```json { "network": "solana", "txSignature": "", "commitment": { "type": "sha256", "value": "" }, "subject": { "type": "payment | ownership | reserves", "id": "" }, "amount": { "asset": "USDC", "quantity": "1250.00" }, "fiat": { "currency": "USD", "amount": "1250.00" }, "timestamp": "2026-01-22T17:20:12Z", "metadata": { "uri": "https://…/proof/", "sha256": "" } } ``` {% endcode %} {% hint style="warning" %} If the commitment is a **Merkle root**, the verifier must also have the **leaf** and **Merkle proof path**. {% endhint %} *** ### Spend Verification **Goal:** turn a spend event into a **publicly auditable record**. #### What it covers * Subscriptions and recurring billing. * High-volume payouts (creators, vendors, payroll lines). * Enterprise expense batches (AP runs, reimbursements). #### Inputs (typical) * `payer` / `payee` identifiers (wallet, account, or platform handle) * `amount` + `asset` (+ optional fiat conversion context) * platform reference IDs (invoice ID, payout ID, receipt ID) * metadata blob (receipt bundle, line items, memo, policy tags) #### On-chain artifacts (auditor view) * **Transaction signature** that anchors the verification. * **Commitment** to the metadata (hash or Merkle root). * Optional: program logs / accounts, if a dedicated program is used.
Batching model (why Merkle roots show up) Batching reduces fees and improves throughput. * Each spend item becomes a **leaf hash**. * The batch anchor stores or references a **Merkle root**. * A verifier checks membership with a Merkle proof.
#### Example: batch commitment (illustrative) {% code title="batch-commitment.json" %} ```json { "batchId": "ap-run-2026-01-22", "merkleRoot": "9c2a…f31b", "items": 24847, "total": { "asset": "USDC", "quantity": "2400000.00" } } ``` {% endcode %} #### Verify the anchor exists (Solana RPC) {% 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":[[""], {"searchTransactionHistory": true}] }' ``` {% endcode %} {% hint style="success" %} **Pass condition:** signature is found and `confirmationStatus` is `finalized` (or your policy threshold). {% endhint %} *** ### Asset Ownership **Goal:** represent assets with **verifiable ownership state**, then make transfers auditable. #### What it covers * Asset tokenization (RWA or on-chain-native assets). * Ownership proofs tied to a mint / registry primitive. * Distributions (airdrops, dividends, allocations) with verifiable recipients. #### On-chain artifacts (auditor view) Depending on implementation, you’ll typically reference: * **Mint address / asset ID** (token mint, registry address, or program state). * **Current owner or custody account** (token account / PDA / multisig). * **Transfer signatures** for ownership changes. * **Metadata commitment** (hash) that binds off-chain legal/asset docs.

Example asset ownership / tokenization flow (illustrative).

#### Example: ownership proof record (illustrative) {% code title="ownership-proof.json" %} ```json { "assetId": "", "owner": "", "txSignature": "", "commitment": { "type": "sha256", "value": "b3f1…" }, "metadata": { "schema": "rwa-v1", "sha256": "2a9d…", "uri": "https://…/asset/" } } ``` {% endcode %} #### Fetch a transaction and ensure it succeeded (Node.js) {% code title="verify-ownership-anchor.ts" %} ```ts import { Connection, clusterApiUrl } from "@solana/web3.js"; const connection = new Connection(clusterApiUrl("mainnet-beta"), "confirmed"); export async function verifyAnchor(signature: string) { const tx = await connection.getParsedTransaction(signature, { maxSupportedTransactionVersion: 0 }); if (!tx) throw new Error("Transaction not found (or pruned)."); if (tx.meta?.err) throw new Error(`Transaction failed: ${JSON.stringify(tx.meta.err)}`); return { slot: tx.slot, blockTime: tx.blockTime, instructions: tx.transaction.message.instructions.length }; } ``` {% endcode %} {% hint style="warning" %} Ownership verification usually requires **program-specific decoding** (mint state, PDAs, metadata). Add those checks once the program IDs and account layouts are published. {% endhint %} *** ### CAPEX Management (treasury + reserves) **Goal:** make treasury operations **verifiable** and reserves **provable**. #### What it covers * Stablecoin payroll and vendor payouts. * Treasury holdings verification (balances + movement history). * Proof-of-reserves style attestations (balance snapshots + commitments). #### On-chain artifacts (auditor view) * Treasury wallet(s) or custody accounts. * Token accounts holding reserves (`USDC`, etc.). * Payout transaction signatures for disbursements. * Snapshot commitments (hash of balances + time) for PoR-style proofs. #### Example: reserve snapshot commitment (illustrative) {% code title="reserve-snapshot.json" %} ```json { "snapshotTime": "2026-01-22T00:00:00Z", "accounts": [ { "tokenAccount": "", "asset": "USDC", "balance": "10400000.12" }, { "tokenAccount": "", "asset": "USDC", "balance": "250000.00" } ], "commitment": { "type": "sha256", "value": "7dd0…9a1c" }, "txSignature": "" } ``` {% endcode %} #### Verify a token account balance (Solana RPC) {% code title="getTokenAccountBalance (cURL)" %} ```bash curl https://api.mainnet-beta.solana.com \ -H "Content-Type: application/json" \ -d '{ "jsonrpc":"2.0", "id":1, "method":"getTokenAccountBalance", "params":[""] }' ``` {% endcode %} {% hint style="info" %} For strong PoR claims, document **which accounts** are in-scope and how custody works. “Proof” without scope is just a balance screenshot. {% endhint %} *** ### What “backed by the $PROOF Protocol” means (operationally) **Expectation:** a third party can independently verify: * the **anchor exists** on-chain (signature is real) * the **anchor is final** (confirmation policy) * the **commitment matches** the referenced metadata (hash/Merkle validation) * the **subject** (payment/ownership/reserves) is consistent with that metadata --- # Agent Instructions: 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: ``` GET https://docs.gotproof.xyz/core-capabilities.md?ask= ``` The question should be specific, self-contained, and written in natural language. 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.