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.

All three domains rely on the same idea: off-chain context becomes tamper-evident via an on-chain anchor (signature + commitment hash).

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.

verification-record.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>"
  }
}

If the commitment is a Merkle root, the verifier must also have the leaf and Merkle proof path.

---

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)

batch-commitment.json

{
  "batchId": "ap-run-2026-01-22",
  "merkleRoot": "9c2a…f31b",
  "items": 24847,
  "total": { "asset": "USDC", "quantity": "2400000.00" }
}

Verify the anchor exists (Solana RPC)

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 is found and confirmationStatus is finalized (or your policy threshold).

---

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)

ownership-proof.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>"
  }
}

Fetch a transaction and ensure it succeeded (Node.js)

verify-ownership-anchor.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
  };
}

Ownership verification usually requires program-specific decoding (mint state, PDAs, metadata). Add those checks once the program IDs and account layouts are published.

---

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)

reserve-snapshot.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>"
}

Verify a token account balance (Solana RPC)

getTokenAccountBalance (cURL)

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

For strong PoR claims, document which accounts are in-scope and how custody works. “Proof” without scope is just a balance screenshot.

---

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