# Enter: PROOF

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&#x26;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&#x26;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&#x26;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&#x26;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&#x26;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 %}