Roadmap

Written as a status report rather than a promise. Every item below is either something that exists and has been tested, or something specific that is missing — with the reason it is missing named. Nothing here has a date attached, because none of the remaining work is blocked on time.

Where it stands

The mechanism works end to end. It has been exercised against a fork of Robinhood Chain carrying real Pons contracts: a coin launched with a CharityVault as its fee recipient, a trade generated 550 USDG of fees, the keeper swept and harvested them, and 535 USDG arrived in the charity treasury with correct per-coin attribution.

What has not happened is any of it on mainnet with real money. The vault factory is not deployed, no coin has launched, and no grant has been sent to a charity.

What is blocking launch

Four things, in the order they need to happen. The first three are not engineering work.

1. A contract audit

The vaults will custody money belonging to charities. The contracts are small and the test suite is thorough — 22 unit tests plus five that run against live Pons — but a test suite written by the same author as the contract is not an audit, and this is exactly the category of code where that distinction matters.

2. A treasury Safe and a funded operator wallet

TREASURY_ADDRESS should be a multisig, not an individual key, because it holds charity-bound funds between harvest and grant. The keeper wallet needs only gas.

3. Legal review

A treasury that custodies funds destined for charities raises money-transmission and charitable-solicitation questions that differ by jurisdiction. The product copy is already careful — buyers are never called donors and no tax deduction is implied — but the structure itself needs an opinion before it holds meaningful sums.

4. The first real grant

The Daffy integration is built and its search half is verified against the live API. The grant half is deliberately untested: creating a donation with a production key moves real money, so it stays unrun until there is a real balance to move. Until that path has completed once, treat it as unproven.

Known gaps in what is built

These are honest holes in the current implementation, not future features.

Post-graduation collection depends on Pons

Before graduation, a coin’s fees sit on its own bonding curve and its vault sweeps them — a call anyone can trigger. After graduation they accrue on a pool shared by every graduated coin, and moving them requires sweepPoolFees on the Pons meme hook, which is gated to a single global operator that Pons runs. A call from any other address reverts with NotFeeSweepOperator().

In practice that operator sweeps roughly every thirty blocks, and each sweep credits the escrow per recipient — so a graduated coin’s fees reach its vault without us doing anything, and our own harvest step claims them like any other credit. The income keeps flowing. But the trigger is not ours, and if Pons stopped running that sweeper, fees would accrue on the hook with no way for us to pull them out.

Coins quoted in tokenised equities cannot be granted

Pons approves pair tokens beyond USDG, including Robinhood Chain’s tokenised equities. A coin quoted in one earns fees in that asset, which the dollar-denominated grant pipeline cannot process without a conversion step. Those balances are shown in their own asset and excluded from grants rather than converted at a guessed rate.

The off-ramp is manual

Daffy offers no API for funding a donor-advised fund, so an operator moves money from the treasury into Daffy by hand. This is the single largest operational weakness and the part of the system that most depends on trust. It can be narrowed — smaller, more frequent batches shorten the window — but not closed without Daffy shipping a funding endpoint or the product moving to a different grant rail.

Smaller ones

• Quick-buy only buys. Selling runs through the curve’s sell function, which is wired in the ABI but has no interface.
• Coin pages show curve progress but no price history — there is no indexer of trades, only of fee events.
• Grant receipts show a Daffy donation ID but do not link to a public receipt page.
• A coin funds exactly one charity. Splitting across several is a plausible feature and would need the vault to carry a distribution rather than a single EIN.

Worth building, once the above is true

• Charity-side visibility. A nonprofit should be able to find its own page, see what is accruing, and verify it without talking to us.
• Matching. A sponsor could escrow funds that match what a coin raises, on-chain, with the same guarantees as the vault itself.
• Automated off-ramp. If a grant rail with a funding API exists, the manual hop disappears and the trust model improves materially.
• Vault migration path. Pons could redeploy. The factory can already repoint at a new escrow, but the migration has never been rehearsed.

What this will not do

• Custody funds without showing the gap. If raised and granted ever get collapsed into one number, the most important property of the product is gone.
• Describe buyers as donors, or imply a tax deduction that does not exist.
• Guarantee a coin’s price. The charity is paid from volume; the coin is a speculative asset and most such assets end at zero.