Fees in. Forests and food out.
100% Autonomous & Auditable · by design
What this is
Transaction fees earned across the ponsfamily network land in a treasury no committee touches. Once a day an AI agent reads the balance, writes a plan and pays it out — inside limits it cannot raise, through screening it cannot skip, onto a ledger it cannot edit.
Spendable balance
Awaiting the next cycle
Total donated
0 settled transfers
Countries reached
Worldwide relief network
Payout ratio
Share of balance released per run
Live from the treasury
Read straight from the API on every revalidation. Nothing in these tiles is typed by hand, and the empty ones stay empty until a cycle fills them.
Project: Alms
One fee, one tree at a time.
Where
it went
No settled transfers yet. This chart fills itself from GET /api/donations/stats — it is not drawn by hand.
What this is
Three properties define it. Everything else on this page is a consequence of one of them.
The treasury is filled by transaction fees earned across the ponsfamily network. There is no fundraising drive and no separate collection: giving is a function of activity that already happened.
An AI agent sets the split and picks recipients on a fixed schedule, inside limits it cannot raise. No monthly meeting, no discretionary override, no single person deciding where a payout lands.
Every run, rejected plan and settled transfer is queryable, including the reasoning the agent gave at the time and the exact prompt it was operating under.
Capital flow
Each step commits before the next begins, so there is no window where money is in motion without a record of where it went.
Step 01
ponsfamily.com posts every network fee to a signed webhook. The signature is an HMAC over the raw bytes, and the provider event id makes the endpoint idempotent, so a retried delivery is acknowledged without crediting twice.
POST /api/webhooks/ponsfamily-feeStep 02
The fee row and the balance increment commit in one database transaction. There is no state where a fee is recorded but uncounted, or counted but unrecorded.
fee_transactions + treasuryStep 03
A cron job wakes the agent on a fixed schedule. Below the treasury floor the run is written down as skipped, with the reason, and nothing moves.
node-cron, single-run lockStep 04
Claude receives the released budget, the all-time category split and the countries funded recently, then returns a plan through a strict tool schema. Prose is rejected; only a valid tool call counts.
submit_donation_planStep 05
Budget, allocation count, duplicates and the geographic rule are checked before any money moves. One violation rejects the whole plan and the agent gets exactly one corrective retry.
reject-then-retry, onceStep 06
The debit and the ledger row commit together, then the transfer is attempted outside that transaction. A failure credits the money back and marks the row failed. Nothing disappears quietly.
donation_logsAutonomous reasoning engine
Every line below is a real record from the agent run log — the reasoning it gave, the screening it passed, and what actually settled. If no cycle has run, the stream says so rather than inventing one.
[ Run log ]
Each cycle runs on a fixed schedule. The agent cannot raise its own budget limits, skip screening, or withhold its reasoning.
What this shows
Real records from the agent run log, replayed in order. If the stream is empty, no cycle has run yet.
Data & need telemetry
Evaluates verified canopy survival rates and acute emergency indices, then balances the two categories against the all-time split it is shown at the start of the run.
Deterministic guardrails
Hardcoded budget ceilings, recipient deduplication and the compliance screen run over every plan before a single dollar moves.
Atomic vault & public ledger
Postgres commits the debit and the ledger row in one transaction. Receipts and rationale are public and append-only.
Treasury policy
Served live from GET /api/agent/policy. If an operator changes a limit, this section changes with it — the numbers are not copied into the page.
Below this the run is skipped and recorded
Share of the balance released per cycle
Hard cap, applied after the ratio
Forces a spread rather than one large bet
UTC · disabled
Full system prompt published at /api/agent/policy
Simulated transfers — live rails are Phase 3
Enforced in prompt, code and database
Allocation mandate
The agent balances between them and corrects for the all-time split it is shown at the start of every run.
ReforestationTree planting and forest restoration where a dollar buys the most surviving canopy — mangroves, degraded tropical land and watershed replanting, favouring organisations that report survival rates rather than planting counts.
Humanitarian reliefAcute crisis response routed to responders already operating in the country: famine and food security, displacement, clean water access and emergency medical care, with the reasoning for each choice recorded beside the payment.
Clean water
Medical
Direct aid
Local partnersGlobal giving without borders
Issue 01 // Field log
Cover story
Every claim on this page maps to an endpoint you can call without an account. If a number here disagrees with the API, the API is right.
No account, no key, no rate limit
Amount, recipient, country, category, status and receipt for every disbursement, cursor-paginated and public. No login required.
GET /api/donationsThe exact system prompt, model id, schedule and budget limits the agent runs under, served live from configuration rather than copied into a document.
GET /api/agent/policy
Every cycle including the ones that produced nothing: skipped for a low balance, or rejected because the plan broke a rule. Failures stay on the record.
GET /api/agent/runsEach settled donation carries a transaction hash or provider receipt id, so a third party can confirm the transfer independently of anything this site says.
tx_hash / receipt_urlControls
The interesting failure modes here are financial, so the guards are structural rather than procedural.
Fee webhooks are verified with HMAC-SHA256 over the raw request body, compared in constant time. An unsigned or mismatched delivery is refused before it reaches the database.
The treasury debit and the ledger row are one transaction, and the debit is a conditional update that cannot take the balance below zero even under concurrent runs.
Operational safety is enforced in the prompt, again in application code, and again as a database constraint. Two of the three can fail without integrity breaking.
The agent cannot raise its own limits. The floor, payout ratio and per-run ceiling live in configuration it never sees as writable, and manual triggers are behind an admin token.
For holders and observers
There is no reporting cycle to wait for. The ledger is the report.
Cadence
Every cycle writes a run record the moment it starts, and closes it with an outcome — completed, skipped, rejected or failed.
Granularity
One ledger row per donation, with amount, recipient, country, category, provider, receipt and the agent's stated reasoning.
Latency
Rows appear as soon as they commit. There is no reporting delay, no monthly roll-up, and no editorial pass between the decision and the record.
Retention
Ledger rows are never deleted through the API. A failed transfer stays visible as failed rather than being removed.
Roadmap
Statuses here reflect the state of the code, not intent. Phase 3 is not done, and the page says so.
Signed webhook, idempotent fee recording, atomic treasury accounting, and the public read endpoints behind the dashboard.
The scheduled decision cycle, the strict tool schema, plan validation with a corrective retry, and the three-layer deterministic filter.
Transfers currently run against a simulated provider. The Giving Block adapter is scaffolded but deliberately unimplemented until credentials and a partner agreement are in place — it fails loudly rather than pretending to send.
Third-party confirmation that a recipient received what the ledger claims, plus periodic impact reporting tied back to individual transfers.
Questions
Including the one most projects skip.
Risk and disclosure
Every run, every rejected plan and every settled transfer, with the reasoning the agent gave at the time.
Open the dashboard