Whitepaper · 4
Trust & transparency
Some of this system is guaranteed by contracts and some of it depends on people doing what they said. Any honest description has to say which is which, because a reader who assumes the whole thing is trustless will be wrong in exactly the place that matters.
What is guaranteed, and by what
| Claim | Enforced by | Kind |
|---|---|---|
| A coin's fees go to the charity it names | The charity's vault is the fee recipient in the launch transaction | code |
| The charity cannot be swapped later | The vault stores its EIN at deployment; there is no setter | code |
| We cannot take a coin's charity fees | The vault's only outputs are the treasury and the creator's split | code |
| Fees can always be moved along | Sweep and harvest are callable by anyone, not just our keeper | code |
| Amounts raised are verifiable | Every credit is an on-chain event; the vault balance is public | code |
| A graduated coin keeps earning | Pons runs the pool sweeper; we only claim what it credits | external |
| Treasury funds reach Daffy | An operator off-ramps and contributes by hand, then logs it | operator |
| Grants are sent promptly | A scheduled job, capped by what has actually been contributed | operator |
| The treasury is not misused | A Safe, plus the public gap between raised and granted | operator |
One row is marked external: after a coin graduates, its fees are moved off the shared pool by a sweeper that Pons operates, not us. Their operator runs roughly every thirty blocks and each sweep credits our vault, which we then claim — so the income keeps arriving. But we cannot trigger it, and a call from any address other than theirs reverts.
Two numbers, never one
Every charity page shows what a cause has raised on-chain and what has been granted via Daffy, with the difference labelled in transit. Those are computed from different sources — the first from chain events, the second from Daffy grant receipts — and they are never added together or shown as one figure.
A single “total donated” number would be the easy thing to display and would conceal precisely the part of the pipeline that requires trust. The gap between the two numbers is the honest measure of how well this is being run, and it is on the front page.
Keys and what they can do
- Keeper key. Signs sweeps and harvests. It only pays gas: vault destinations are fixed, so compromising it cannot redirect a single dollar. It never touches the web deployment.
- Factory owner. Can change the treasury address and repoint vaults at a redeployed Pons escrow. This is the most powerful key in the system and belongs on a Safe.
- Daffy API key. Grants from the operator’s donor-advised fund. It can send money to charities; it cannot send money anywhere else.
Verifying it yourself
Nothing here needs to be taken on faith. A coin’s page links to its vault on the block explorer; the vault’s ein() returns the charity it is bound to, and its Harvested events are the complete record of what has left it. Pons’ own getLaunchedToken confirms which address is the fee recipient.
Our own launch API does this check before it will list a coin: it re-reads the transaction, pulls the fee recipient, and asks the factory to derive the vault address for the claimed charity. If those do not match, the coin is refused — a coin cannot claim a cause it does not pay.
Legal framing
Grants come from the operator’s donor-advised fund, not from coin buyers. Buyers therefore receive no tax deduction and are not donors in any legal sense. Product copy says “proceeds routed to charity” and never “your donation”.
A treasury that custodies charity-bound funds raises money-transmission and charitable solicitation questions that vary by jurisdiction. This is a description of a mechanism, not legal advice, and the mechanism should be reviewed by counsel before it holds anyone’s money at scale.
Contract addresses and interfaces are listed in the protocol reference.
NextProtocol referenceAddresses, interfaces, and the findings behind them