01Overview

Vouch is a payment layer between on-chain communities and fundraisers that do not accept crypto. A community points a token’s creator fees at an Impact Vault. The vault sweeps those fees to USDC, delivers them to the fundraiser through a rail the fundraiser already accepts, and publishes a receipt for every delivery. The receipt is hashed and the hash is anchored on Solana so it can be verified by anyone, forever, without trusting Vouch.

Nothing about this requires the fundraiser to know what a token is. The organizer sees a donation on their page, the same as any other. The community sees a public ledger of where every dollar went.

02Fee routing

Attribution is done at the address level. Every token connected to a vault gets its own route address: a fresh keypair whose secret is held by Vouch and whose public key is the only place the token’s creator fees should land. Because the route address is unique per token, any SOL arriving there is that token’s revenue with no further inference.

pump.fun

pump.fun creator fees pay to a single creator wallet, and the creator can redirect them exactly once. Connecting a pump.fun token means submitting that one-time redirect to the token’s route address. The redirect transaction is recorded as the route proof and the route is marked locked. Because it cannot be changed again, a locked pump.fun route is the strongest form of commitment Vouch supports: 100% of creator fees, permanently.

Bags

Bags supports fee-share configurations with up to 100 claimers, each assigned a share in basis points. Connecting a Bags token means adding the route address as a claimer with a stated share. Vouch records the share as the token’s route bps and only counts fees actually received at the route address, so a 5,000 bps share claims exactly half of what the token earns.

Meteora and manual routes

Tokens on other launchpads can be connected by pointing their fee destination at a route address by whatever mechanism the launchpad offers. Where the mechanism is not on-chain-immutable, the route is shown as unlocked. Unlocked routes are eligible for delivery but not for the $VOUCH fee match.

03Vault & sweep

A vault is a custodial USDC treasury on Solana with one cause attached. Its keypair is generated at creation and stored encrypted under a KMS key; the secret is never returned by any query or API. A vault has two policy numbers set by its owner: the donate share in basis points (how much of swept USDC must be delivered, with the remainder kept for gas and operations) and the delivery threshold in USD (deliveries queue automatically once treasury USDC crosses it).

Sweep

A worker watches every route address. When fees accumulate above a small dust threshold, they are swapped to USDC through Jupiter and sent to the vault treasury. Each sweep records the input asset and amount, the USDC received, the swap signature, and which fee events it consumed. Fee events are priced in USD at block time so the ledger totals do not move with the market afterwards.

• A fee event belongs to exactly one sweep once swept, and to exactly one token always.
• Sweep slippage is real and shown: the USDC received is what gets delivered, not the USD value at fee time.
• Treasury balance is read from chain; the ledger is a record, not a source of funds.

04Delivery rails

A rail is how USDC becomes a payment the fundraiser can receive. The honest version of the situation is this: consumer fundraising platforms such as GoFundMe, LaunchGood, and JustGiving do not have a donation API. Automating their checkout with a script or browser bot violates their terms of service and puts the campaign at risk of being frozen. Vouch does not do that.

Operator card (live)

Vault USDC funds a top-up to a Zentro card. A named operator with the operator role makes the donation on the fundraiser’s own page with that card, then attaches the confirmation (email, page screenshot, card statement line) as artifacts. The operator signs off in the operator desk; the delivery is finalized with the card reference, fiat amount, FX rate, and any platform fee. The operator’s user id is part of the receipt.

This is a human step by design. It is auditable rather than automatic. Each artifact is stored by hash, so evidence cannot be substituted after the receipt is anchored.

On-chain USDC (live)

When a cause holds a Solana address, delivery is one USDC transfer from the vault treasury to that address. The transfer signature is the rail reference. No FX, no platform fee, no operator in the loop beyond finalizing the receipt.

Issuing card (in integration)

For platforms whose terms permit programmatic card donations, a virtual card can be issued per vault through Rain or Bridge and funded directly from USDC. This removes the operator from execution. It has not been used for any delivery yet and is shown as in integration until it has.

GoFundMe Pro (nonprofits only)

Registered nonprofits on GoFundMe Pro can authorize Vouch via OAuth, after which donations are posted through the official API with the receipt id in the donation memo. Personal campaigns cannot use this rail.

05Receipt spec

A receipt is the canonical JSON for a delivery. It is built once at finalize time, hashed with SHA-256, and the hash is written into a Solana memo. The canonical form is deterministic: keys sorted at every level, no whitespace, nulls preserved, timestamps as ISO 8601 strings in UTC. Delivery status is deliberately excluded so the bytes never change once the delivery is delivered.

{
  "v": 1,
  "id": "dlv_basmalah_4",
  "ordinal": 4,
  "vault": { "id": "vlt_basmalah", "slug": "basmalah", "name": "Basmalah Vault", "treasuryAddress": "<base58>" },
  "cause": { "id": "cau_basmalah", "slug": "basmalah-sma", "title": "Basmalah's fight against SMA Type 1", "platform": "gofundme", "url": "https://www.gofundme.com/f/help-basmalah-fight-sma" },
  "amountUsdc": 14638.02,
  "amountFiat": 14638.02,
  "fiatCurrency": "USD",
  "fxRate": 1,
  "platformFeeFiat": 424.8,
  "rail": "operator_card",
  "railRef": "Visa •••• 4821 · auth 512930",
  "fundingTxSig": "<solana signature>",
  "allocations": [
    { "tokenId": "tok_basma", "symbol": "BASMA", "amountUsdc": 7088.29 },
    { "tokenId": "tok_dose",  "symbol": "DOSE",  "amountUsdc": 5224.95 },
    { "tokenId": "tok_hope",  "symbol": "HOPE",  "amountUsdc": 2324.78 }
  ],
  "artifacts": [
    { "kind": "confirmation", "label": "GoFundMe confirmation email", "sha256": "<hex>", "bytes": 48213 },
    { "kind": "statement",    "label": "Card statement line",         "sha256": "<hex>", "bytes": 1024 }
  ],
  "period": { "label": "Week 4", "startsAt": "2026-09-12T00:00:00.000Z", "endsAt": "2026-09-19T00:00:00.000Z" },
  "deliveredAt": "2026-09-19T14:09:52.484Z"
}

Hash and memo

hash = sha256(canonical), hex encoded. The memo transaction carries vouch:v1:<deliveryId>:<hash> through the Solana Memo program and is signed by the vault treasury key, so the anchor is attributable to the vault that made the delivery.

06Verification

Every receipt page shows the canonical string, the stored hash, and the anchor signature, and recomputes the hash in front of you. You do not have to trust that page. Recompute it yourself from the public export:

# 1. fetch the public receipt export for the vault
curl -s https://vouch.fund/api/vaults/basmalah/receipts.json > receipts.json

# 2. take one receipt's canonical string and hash it
jq -r '.[] | select(.id=="dlv_basmalah_4") | .canonical' receipts.json \
  | tr -d '\n' | sha256sum

# 3. compare with the stored hash and the on-chain memo
jq -r '.[] | select(.id=="dlv_basmalah_4") | .hash, .anchorTxSig' receipts.json
# memo in that transaction must read:
#   vouch:v1:dlv_basmalah_4:<hash>

• If the recomputed hash matches the stored hash, the receipt content has not changed since finalize.
• If the on-chain memo carries the same hash, the receipt existed at that block time and was signed by the vault treasury.
• If an artifact's hash matches the file you were shown, that file is the evidence the operator attached.
• The verify endpoint GET /api/receipts/<id>/verify does the same three checks and returns them as JSON.

07Periods

Vaults report in weekly periods. A period records fees in and USDC delivered out for its window. Deliveries reference the period they close, so a vault page can show, for any week, what came in, what went out, and the receipts behind it. Periods do not change accounting; they are the reading frame.

08Roles

Sign-in is Google, directly. Each account gets a custodial Solana wallet whose key is held encrypted by Vouch. The operator role is granted by email allow-list and is shown on the operator’s public profile on every receipt they finalize.

09FAQ