# 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
This site has an agentic ask interface you may use to query the documentation dynamically by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.gotproof.xyz/index.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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

---

# Enter: PROOF

$PROOF Technical Documentation

This GitBook is the technical overview for **$PROOF** (gotproof.xyz).

Use it to understand **what gets verified**, **where it’s recorded**, and **how to audit it**.

<figure><img src="https://3069195333-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvPzgXEMNpAWMLYXanq7T%2Fuploads%2FhnyrUBG18kbuOrkyKsXR%2FUntitled%20design%20(8).gif?alt=media&amp;token=e2890539-bc0d-4201-87db-b090aec50c55" alt=""><figcaption></figcaption></figure>

## Introduction

**$PROOF** is an on-chain verification layer for **payments** and **on-chain assets**.

It’s designed for:

* **Enterprises**: payroll, expenses, capex, vendor payouts.
* **Creators / communities**: donations, memberships, subscriptions.
* **Individuals**: proving spend, ownership, and allocation decisions.

It’s built primarily on **Solana** and targets a simple outcome:

* A payment event becomes **publicly auditable**.
* Verification data becomes **tamper-evident** (on-chain anchoring).
* Audit trails can be **shared automatically** for transparency.

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

### At a glance (what you get)

* **On-chain verification**: payment / donation activity is recorded on-chain with cryptographic proofs.
* **Crypto → fiat bridging**: supports conversions (e.g. `ETH`, `SOL`, `USDC` → `USD`, `EUR`, `GBP`).
* **Platform integrations**: supports 100+ platforms (e.g. YouTube, Patreon, Twitch, GoFundMe, PayPal).
* **Public auditability**: automated sharing of verification posts to **X** (formerly Twitter).
* **Token utility**: `$PROOF` enables product tiers and spend verification workflows.

{% hint style="info" %}
Recipients can be **non-crypto**. No wallet required on the recipient side.
{% endhint %}

<figure><img src="https://3069195333-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvPzgXEMNpAWMLYXanq7T%2Fuploads%2FYAyeRz5rnstG2mHIHLfT%2FUntitled%20design%20(13).gif?alt=media&amp;token=09a0ad2f-c417-4fe8-979f-7c18d48d294c" alt=""><figcaption></figcaption></figure>

### Core workflow (high level)

1. **Initiate** a payment or spend event (crypto or fiat-connected).
2. **Anchor** a verification record on-chain (Solana-first).
3. **Expose** a public reference for audit (transaction signature + metadata).
4. **Optionally broadcast** the verification to public channels (e.g. X).

### Verification primitives (auditor view)

When you audit a $PROOF verification, you generally want to answer:

* **What happened?** (amounts, assets, counterparties, timing)
* **Where is the anchor?** (chain, tx signature, program/account references)
* **Is it immutable?** (on-chain data + hash/merkle commitments)
* **Is the off-chain context consistent?** (receipts, platform payout IDs, etc.)

#### Minimal record you should expect to be able to reference

Even if metadata lives off-chain, an auditable verification typically includes:

* **Network**: e.g. `solana`
* **Transaction signature**: the canonical on-chain pointer
* **Asset + amount**: e.g. `USDC`, `10.5`
* **Timestamp / slot**
* **Metadata reference**: URI and/or content hash

<details>

<summary>Example (illustrative) verification record shape</summary>

```json
{
  "network": "solana",
  "txSignature": "5y7...h2K",
  "asset": "USDC",
  "amount": "10.5",
  "fiatCurrency": "USD",
  "fiatAmount": "10.50",
  "timestamp": "2026-01-22T17:20:12Z",
  "metadata": {
    "uri": "https://…",
    "sha256": "b3f1…"
  }
}
```

This is an example format for integrators and auditors. It’s not a guarantee of the exact production schema.

</details>

<figure><img src="https://3069195333-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvPzgXEMNpAWMLYXanq7T%2Fuploads%2FioXkuFViuOJybrCl8Vb7%2Fimage.png?alt=media&amp;token=2e881e6d-ec0a-48b7-a4a5-cbf5cd697e63" alt=""><figcaption></figcaption></figure>

### Developer quickstart: verify a Solana anchor

These snippets show how to validate the **existence** and **finality** of an on-chain anchor. They work for any Solana transaction signature.

{% hint style="warning" %}
If $PROOF uses a dedicated Solana program, add program-specific account decoding here once the program ID + account layouts are published.
{% endhint %}

#### 1) Fetch and inspect a transaction (Node.js)

{% code title="verify-tx.ts" %}

```ts
import { Connection, clusterApiUrl } from "@solana/web3.js";

const connection = new Connection(clusterApiUrl("mainnet-beta"), "confirmed");

export async function verifySolanaTx(signature: string) {
  const tx = await connection.getParsedTransaction(signature, {
    maxSupportedTransactionVersion: 0,
  });

  if (!tx) {
    throw new Error("Transaction not found (or pruned).");
  }

  const err = tx.meta?.err;
  if (err) {
    throw new Error(`Transaction failed: ${JSON.stringify(err)}`);
  }

  return {
    slot: tx.slot,
    blockTime: tx.blockTime,
    feeLamports: tx.meta?.fee,
    instructions: tx.transaction.message.instructions.length,
  };
}
```

{% endcode %}

#### 2) Confirm finality (Node.js)

{% code title="finality.ts" %}

```ts
import { Connection, clusterApiUrl } from "@solana/web3.js";

const connection = new Connection(clusterApiUrl("mainnet-beta"), "finalized");

export async function isFinalized(signature: string) {
  const status = await connection.getSignatureStatus(signature, {
    searchTransactionHistory: true,
  });

  return status.value?.confirmationStatus === "finalized";
}
```

{% endcode %}

#### 3) Minimal RPC equivalent (cURL)

{% code title="getSignatureStatuses (Solana JSON-RPC)" %}

```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 %}

<figure><img src="https://3069195333-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvPzgXEMNpAWMLYXanq7T%2Fuploads%2FYtcDPsZkFZhMrF62OfW6%2Fphoto_2026-01-18_09-55-30.jpg?alt=media&amp;token=b7f95a29-23b5-4a2f-9e73-f74f6446340a" alt=""><figcaption></figcaption></figure>

### Token tiers (utility gates)

If you reference tiers in integrations or customer docs, keep them explicit:

* **1M $PROOF**: tier unlock (feature set depends on product policy)
* **5M $PROOF**: higher tier unlock
* **10M $PROOF**: highest tier unlock

{% hint style="info" %}
Document tier-to-feature mapping in the relevant product pages. This intro keeps it intentionally high-level.
{% endhint %}


# 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


# Technical Architecture

This page describes how $PROOF turns real-world actions into **verifiable on-chain anchors**.

It’s Solana-first. It’s built for **high volume** and **fast auditability**.

<figure><img src="https://3069195333-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvPzgXEMNpAWMLYXanq7T%2Fuploads%2FkuC724R8OOc4HrkVbhH5%2FUntitled%20design%20(13).gif?alt=media&amp;token=762f469d-ce2e-46e5-8f51-f46b041d3bbe" alt=""><figcaption></figcaption></figure>

### System layers (mental model)

* **Execution Layer**: collects intent, does batching, optional conversion routing.
* **Verification Layer**: produces commitments and anchors them on-chain.
* **Integration Layer**: APIs, webhooks, and platform connectors (100+ integrations).

{% hint style="info" %}
The core invariant: **off-chain context** → **commitment** → **on-chain anchor** → **auditable reference**.
{% endhint %}

### Chain + verification model

#### Primary chain

* **Solana mainnet** for throughput and low latency.
* Anchors are referenced by **transaction signature**.

#### What “Proof-of-History” means here

Solana uses **PoH** as a verifiable time source.\
Finality and ordering come from Solana’s **PoS + Tower BFT** consensus.

#### Anchor contents (minimum)

Every verification should be able to point to:

* `txSignature` (the anchor)
* a `commitment` (hash or Merkle root)
* optional: program/account references for richer proofs

<details>

<summary>Why commitments exist</summary>

Blockchains are good at **immutability**, not storing large receipts.

So you store a small commitment on-chain.\
You store rich metadata off-chain.\
You prove linkage by re-hashing the metadata and matching the commitment.

</details>

### Data flow (end-to-end)

#### 1) User / system initiates an event

Examples:

* creator donation
* invoice payment
* payroll line
* reserve snapshot

**Inputs** typically include:

* `amount` + `asset` (and optional fiat conversion context)
* subject identifiers (platform payout ID, invoice ID, asset ID)
* metadata blob (receipt bundle, line items, memo, policy tags)

#### 2) Build a commitment

Two common patterns:

* **Single event hash**: `sha256(metadataBlob)`
* **Batch Merkle root**: `root(sha256(item1), sha256(item2), …)`

{% code title="commitment-examples.txt" %}

```
single: sha256(metadata_json)
batch:  merkle_root([sha256(item_0), sha256(item_1), ...])
```

{% endcode %}

#### 3) Anchor on-chain (Solana)

<div align="left"><figure><img src="https://3069195333-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvPzgXEMNpAWMLYXanq7T%2Fuploads%2FuOiT8gngQB1pUGLUgkrN%2FUntitled%20design%20(11).gif?alt=media&amp;token=7b110535-6adc-42e8-adba-4a6c338c6377" alt="" width="344"><figcaption></figcaption></figure></div>

The system submits a transaction that commits to the event/batch.

What an auditor should be able to get from the chain:

* signature exists
* transaction succeeded (`meta.err == null`)
* transaction is finalized (per policy)

#### 4) Publish an audit reference

Typical outputs:

* a public URL to the verification object
* a transaction signature
* optional broadcast to public channels (e.g., X)

#### 5) Observe in a dashboard

Dashboards should be **derived** from:

* on-chain anchors
* the metadata store
* your internal event IDs (for dedupe and reconciliation)

### Developer verification recipes

#### Check finality (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:** `confirmationStatus` is `finalized` (or your chosen threshold).
{% endhint %}

#### Fetch and validate a transaction succeeded (Node.js)

{% code title="audit-anchor.ts" %}

```ts
import { Connection, clusterApiUrl } from "@solana/web3.js";

const connection = new Connection(clusterApiUrl("mainnet-beta"), "confirmed");

export async function auditAnchor(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,
    feeLamports: tx.meta?.fee
  };
}
```

{% endcode %}

#### Wallet connectivity (Solana-first)

Users typically connect via Solana wallets:

* Phantom
* Solflare
* Backpack

{% hint style="info" %}
If you later support EVM rails, document them separately as a multi-chain adapter. Avoid mixing Solana wallets with EVM wallet examples in the same flow.
{% endhint %}

### Security model

#### What you get “for free”

* **Immutability** of anchors once finalized.
* **Public verifiability** of signatures and confirmations.

#### What you must specify

* **Scope**: which accounts/programs count as “official” anchors.
* **Metadata integrity**: how metadata is hashed and canonicalized.
* **Key management**: who can publish anchors and with what controls.

#### Enterprise controls

* **Multisig** for high-value treasury operations.
* **Role separation** between execution (payout) and verification (anchor).

#### “No trusted setup”

Hash/Merkle commitments do not require trusted setup.\
You rely on Solana’s consensus security for finality and ordering.

### What’s intentionally unspecified (for now)

Some details depend on the production program design:

* program IDs
* account layouts (PDAs)
* exact metadata schemas

Publish those and we can upgrade this page with **program-level decoding** and **strict verification rules**.


# 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="https://3069195333-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvPzgXEMNpAWMLYXanq7T%2Fuploads%2FHsPJguw9CRoMN8JEx2KG%2Fimage.png?alt=media&amp;token=7dcf5ea0-b840-4404-87d5-3b39c5b6b242" 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 %}


# Implementation Guide

This page is for **builders** integrating $PROOF into a product or workflow.

It focuses on two tasks:

* **Create** verifications (payments / ownership / reserves).
* **Audit** verifications (reproduce commitments and validate on-chain anchors).

{% hint style="info" %}
If you only need the mental model first, read [Technical Architecture](/technical-architecture) and [Core Capabilities](/core-capabilities).
{% endhint %}

### Prerequisites

* A **Solana RPC endpoint** (mainnet + optional devnet).
* A wallet + signer for publishing anchors (server key or multisig).
* A place to store verification metadata (object storage, DB, or both).

{% hint style="warning" %}
Define canonicalization rules before hashing metadata.\
If two systems serialize JSON differently, hashes won’t match.
{% endhint %}

### Integration modes

#### Mode A — No-code / dashboard

Best for pilots.

1. Visit `gotproof.xyz`.
2. Connect a Solana wallet (Phantom / Solflare / Backpack).
3. Create verification events via UI.
4. Copy the `txSignature` + public proof URL for audit sharing.

#### Mode B — Platform integration (API + webhooks)

Best for production.

You typically implement:

* `POST /verifications` (create)
* `GET /verifications/:id` (fetch)
* `POST /webhooks` (receive events like `anchored`, `finalized`)

{% hint style="info" %}
Exact endpoints and auth depend on your deployment and product tier.\
This guide documents the **flow** and **verification logic**.
{% endhint %}

### Reference flow (create → anchor → verify)

{% stepper %}
{% step %}

### 1) Build metadata (the thing you want to prove)

Examples:

* donation receipt bundle + platform payout ID
* payroll batch register
* reserve snapshot (list of accounts + balances + timestamp)

Minimum fields to include:

* stable identifiers (`subject.type`, `subject.id`)
* amounts (`asset`, `quantity`, optional fiat context)
* timestamps (ISO 8601)
* any external references (invoice IDs, payout IDs, etc.)
  {% endstep %}

{% step %}

### 2) Compute a commitment

Use either:

* **Single proof hash**: `sha256(metadataBlob)`
* **Batch root**: Merkle root over per-item leaf hashes

Persist:

* the commitment value
* the exact metadata blob used to produce it
  {% endstep %}

{% step %}

### 3) Anchor on-chain (Solana)

Submit a Solana transaction that commits to the hash/root.

At minimum you need to retain:

* `txSignature`
* commitment value
* network (`mainnet-beta`, `devnet`)
  {% endstep %}

{% step %}

### 4) Verify (auditor / support / customer success)

Verification checks:

1. **Transaction exists**
2. **Transaction succeeded**
3. **Transaction is finalized** (per your policy)
4. **Commitment matches** the published metadata
   {% endstep %}
   {% endstepper %}

### Solana: verification snippets

#### Check finality (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 %}

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

{% code title="verify-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
  };
}
```

{% endcode %}

{% hint style="warning" %}
If anchors live in a dedicated Solana program, add **program ID checks** and **account decoding** once published.
{% endhint %}

### Webhooks (recommended)

Use webhooks to avoid polling and to separate concerns:

* your system emits the event (payment/payroll/ownership/snapshot)
* $PROOF emits the state transition (anchored → confirmed → finalized)

Suggested events:

* `verification.created`
* `verification.anchored` (has `txSignature`)
* `verification.finalized`
* `verification.failed` (include reason)

{% hint style="info" %}
Always design webhook handlers to be **idempotent**.\
Expect retries and out-of-order delivery.
{% endhint %}

### Pseudocode (legacy)

The diagram below is a conceptual sketch of the integration path.

<figure><img src="https://3069195333-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvPzgXEMNpAWMLYXanq7T%2Fuploads%2FVPviSYmbgn11qV3PA8gI%2Fimage.png?alt=media&amp;token=1ba63d4e-f751-4ae9-9990-bc737fee5e64" alt=""><figcaption><p>Illustrative integration pseudocode.</p></figcaption></figure>

### Token utility (tiers)

Use tiers as **feature gates**, not as vague marketing.

* **1M $PROOF**: tier unlock (feature set depends on product policy)
* **5M $PROOF**: higher tier unlock
* **10M $PROOF**: highest tier unlock (often “DAO / enterprise” tier)

{% hint style="info" %}
Publish a tier → feature matrix somewhere.\
This page only documents how tiers are used operationally.
{% endhint %}

### Revenue share (if applicable)

If you advertise revenue share:

* specify **who** receives it (holders, stakers, LPs)
* specify **how** it’s calculated (basis, cadence, exclusions)
* link to on-chain references (distribution txs) when possible

Avoid one-off numbers without context.


# Epilogue

<figure><img src="https://3069195333-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FvPzgXEMNpAWMLYXanq7T%2Fuploads%2FNa25PpgOo2vEpYF2GPRm%2FUntitled%20design%20(10).gif?alt=media&amp;token=7821edf0-30c2-43ed-9c0e-e5eddab614dd" alt=""><figcaption></figcaption></figure>

$PROOF is a decentralized verification layer that transforms on-chain assets into operational tools for real-world finance. By leveraging Solana's high-performance blockchain, $PROOF provides verifiable proofs for payments, asset ownership, and expenditures without requiring fiat-native infrastructure.IntroductionIn a world where $600 trillion in global assets await tokenization and $60 trillion in annual payroll needs on-chain efficiency, $PROOF bridges the gap. It enables 1M+ non-crypto creators to receive verified payments seamlessly.Architecture

* Layers:
  * Execution Layer: Handles transaction batching and fiat conversion.
  * Verification Layer: Generates proofs using Solana's native cryptography.
  * Integration Layer: APIs for 100+ platforms.
* Protocols:
  * Proof Generation: Uses transaction hashes and Merkle trees for verifiability.
  * Consensus Integration: Aligns with Solana's Tower BFT for security.

Security Model

* Assumptions: Relies on Solana's economic security.
* Mitigations: Multi-sig for high-value operations; immutable proofs.

Token Economics

* Utility: Governance, staking for revenue share.
* Distribution: Community-driven launches with rev share.

Future Roadmap

* Expand to multi-chain (e.g., Ethereum integration).
* Advanced ZK proofs for privacy-enhanced verifications.

Conclusion$PROOF redefines on-chain finance by making verifiability standard.References: Solana Docs, gotproof.xyz updates.This GitBook can be hosted on GitBook.com using Markdown files for each page. For full implementation, clone the repo and customize.