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.

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.

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.

Recipients can be non-crypto. No wallet required on the recipient side.

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

Example (illustrative) verification record shape

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

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.

If $PROOF uses a dedicated Solana program, add program-specific account decoding here once the program ID + account layouts are published.

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

verify-tx.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,
  };
}

2) Confirm finality (Node.js)

finality.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";
}

3) Minimal RPC equivalent (cURL)

getSignatureStatuses (Solana JSON-RPC)

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

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

Document tier-to-feature mapping in the relevant product pages. This intro keeps it intentionally high-level.