> 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/core-capabilities.md).

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

<figure><img src="https://3069195333-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvPzgXEMNpAWMLYXanq7T%2Fuploads%2FJhi6xgf7JrI2yaGHtBad%2FUntitled%20design%20(15).gif?alt=media&amp;token=32c9eb01-1896-4a4c-9954-30ee1b1f2c94" alt=""><figcaption></figcaption></figure>

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

<div align="left"><figure><img src="https://3069195333-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvPzgXEMNpAWMLYXanq7T%2Fuploads%2FlbPJkYPMIMU1djPCKM9o%2FUntitled%20design%20(12).gif?alt=media&amp;token=af5cfe2f-bb48-428b-b03b-5a31752601ee" alt=""><figcaption></figcaption></figure></div>

#### 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": "<SIG>",
  "commitment": {
    "type": "sha256",
    "value": "<HEX_HASH_OR_MERKLE_ROOT>"
  },
  "subject": {
    "type": "payment | ownership | reserves",
    "id": "<INTERNAL_OR_PLATFORM_ID>"
  },
  "amount": {
    "asset": "USDC",
    "quantity": "1250.00"
  },
  "fiat": {
    "currency": "USD",
    "amount": "1250.00"
  },
  "timestamp": "2026-01-22T17:20:12Z",
  "metadata": {
    "uri": "https://…/proof/<id>",
    "sha256": "<HEX_SHA256_OF_METADATA_BLOB>"
  }
}
```

{% 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.

<details>

<summary>Batching model (why Merkle roots show up)</summary>

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.

</details>

#### 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":[["<TX_SIGNATURE>"], {"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.

<figure><img src="https://3069195333-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvPzgXEMNpAWMLYXanq7T%2Fuploads%2FsI8q93RtU0eTecak2PXs%2Fimage.png?alt=media&amp;token=03768e6f-16ce-4c3d-a948-9dfc0bd19a00" alt=""><figcaption><p>Example asset ownership / tokenization flow (illustrative).</p></figcaption></figure>

#### Example: ownership proof record (illustrative)

{% code title="ownership-proof.json" %}

```json
{
  "assetId": "<MINT_OR_REGISTRY_ADDRESS>",
  "owner": "<WALLET_OR_CUSTODY_ACCOUNT>",
  "txSignature": "<SIG>",
  "commitment": { "type": "sha256", "value": "b3f1…" },
  "metadata": {
    "schema": "rwa-v1",
    "sha256": "2a9d…",
    "uri": "https://…/asset/<id>"
  }
}
```

{% 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": "<ACCOUNT_1>", "asset": "USDC", "balance": "10400000.12" },
    { "tokenAccount": "<ACCOUNT_2>", "asset": "USDC", "balance": "250000.00" }
  ],
  "commitment": { "type": "sha256", "value": "7dd0…9a1c" },
  "txSignature": "<SIG>"
}
```

{% 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":["<TOKEN_ACCOUNT_ADDRESS>"]
  }'
```

{% 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