How it works

Three things happen: a vault is created for the charity, a coin is launched pointing at it, and fees are pushed along a path that ends outside our control. Each is worth following precisely, because the guarantees come from the details.

The launch transaction

Pons’ launchToken takes a struct describing the coin. Two of its fields matter here:

struct TokenParams {
  string  name;
  string  symbol;
  string  logo;                 // ipfs://…
  string  description;
  Socials socials;
  address creatorFeeRecipient;  // ← the CharityVault
  uint16  creatorTaxBps;        // ← the charity fee, 0–1000 (max 10%)
  bool    buybackEnabled;
  bytes32 expectedEconomics;
  bytes32 salt;
}

creatorFeeRecipient is the address Pons will pay that coin’s creator fees to, forever. creatorTaxBps is an additional per-trade fee the creator chooses, capped by the protocol at 10%, which goes entirely to that same recipient. Setting the first to a CharityVault and the second above zero is the whole product.

Vaults are shared and deterministic

A vault is a minimal proxy deployed at an address derived from the charity’s EIN, the creator, and the split. Because the address is deterministic, the launch form can compute it before it exists. Because coins that give everything to the charity ignore the creator in that derivation, they all land on the same vault per charity — the tenth coin launched for a food bank costs nothing extra to bind, and every one of them feeds one address.

Where a fee goes

A trade’s fees do not arrive at the charity in one hop. They accumulate on the coin’s bonding curve, get swept into a shared Pons escrow, get claimed by the vault, and are forwarded to the treasury — after which a human moves them into Daffy.

Nobody needs our permission to move it

Pons restricts sweepFees to the coin’s fee recipient — anyone else gets NotFeeSweepOperator(). Since the recipient is the vault, and the vault’s sweep and harvest functions are open to any caller, the sequence can be triggered by anyone at all. Our keeper does it on a schedule, but it holds no privilege a stranger lacks.

What the vault can and cannot do

• Can: claim fees from the escrow, forward them to the treasury address, and pay the creator their split if one was set at launch.
• Cannot: send funds to any other address, change which charity it serves, or be upgraded. The EIN is written at deployment and the implementation is immutable.
• The one escape hatch is deliberately narrow: the factory owner can hand a token’s fee stream to a new recipient. It exists so a Pons redeployment cannot strand fees forever, and Pons enforces a three-day timelock on such changes.

From treasury to charity

The treasury accrues USDG — a dollar stablecoin — so the ledger is denominated in real dollars with no oracle in the path. An operator off-ramps it and contributes to a donor-advised fund at Daffy, logging the amount. The grants job then pays each charity what it is owed, in oldest-first order, and can never send more in total than has been logged as contributed.

Daffy enforces a $10 minimum per grant, so a charity below that carries forward rather than being rounded up. Amounts are never inflated to clear a threshold.