Transparency ledger

Methodology

• Append-only. A committed row is never edited and never deleted. A correction is a new row that references the row it corrects; an annotation renders as an annotation, never as a change to the figure it annotates.
• Hash-chained. rowHash = SHA-256(prevHash ‖ JCS(row minus its two hash fields)), over RFC 8785 canonical JSON, in global sequence order. A published row is the hashed row under the same member names, plus its date, which sits outside the hashed body: drop those three and the row reproduces its own hash. Every month publishes a digest over its own rows — the SHA-256 of the RFC 8785 canonical text of that month's rows as published in its export, an array in sequence order carrying complete rows including their two hash fields — and the chain publishes the head and every month's digest. Recomputing all of it needs nothing from us but the published bytes, which is what "independently reconcilable" means. The CSV twin carries the same rows flat; a divergence between the two is a defect, not a formatting difference.
• Lock before sweep. Every payout has its own clock: its allocation is locked before the transfer, and each listed recipient's share is sent directly from the fees account in a transfer normally initiated on the 25th of the month the payout is credited, within thirty days of its credit — one transfer per recipient; a month's payouts may be locked together when no payout's deadline is missed; nothing stands between the fees account and a listed recipient: no pooled vehicle, no instruction that carries no money, no handling fee. Card chargebacks that arrive before the lock land against the month they belong to; allocation data arriving after the lock — a late payer designation, a contributor vote — counts for the next month, forward-only. A reversal after a transfer is netted by the rail inside a later payout and recorded as a forward-only row; nothing is ever clawed back from a recipient.
• Three outgoing lines, each capped, each published. The month's running costs charged to fees (within the one annual cap, which covers everything the movement costs to run — third-party invoices and the people who do the work alike); the operations reserve's retention (at most a published share of the Purpose Fees of each payout, until the reserve holds its target, its own row even at zero); and the transfers to the listed recipients. Nothing else ever leaves the fees account. People are published as one line per function, never by name, and pay to a board member stays within a maximum per function that the general assembly approves and needs the prior minuted approval of the other board members, the payee taking no part in it; that approval is published with the month.
• Two partitions of the same money. The cost-support table below counts Purpose Fees by rail payout period; this allocation ledger counts intake by transaction month. The two differ month by month and are reconciled by payout matching and by the annual aggregate.
• No roll-forward. Every payout the payment provider makes to the fee account is passed on within thirty days of its credit, however small, in one transfer per listed recipient with a share: small transfers are the price of the thirty-day rule. The provider pays out once a month, and only over its minimum payout threshold; a smaller balance waits with it, and a month without a payout has no transfer. The transfer charges are a running cost, published per transfer.
• Integer minor units. Money is stored and hashed as integers with an ISO currency code; foreign-exchange rates are captured per transaction as decimal strings. No floating-point number ever reaches a hash.
• Allocation is deterministic. Re-running the allocator on the same month and the same inputs produces byte-identical rows. A ledger that could not be reproduced would only be a record of what we said we did.

What the money passed through to get here

100% of net Purpose Fees go to the listed charities within 30 days of each payout, after published, capped costs: running costs at most 15% of a year's net fees, and the reserve at most 5% of each payout until it holds six months of costs, so at least 80% every year. Listed supporters lower the costs, never what is passed on. No cap is ever raised for a purchase already made. Every cost and transfer is published monthly. Worst case, published as such: at least 80% of a financial year's net Purpose Fee proceeds (after the payment provider's fee, without the taxes charged at purchase, and after refunds and chargebacks) pass on to the listed recipients (100 − 15 − 5), every cap drawn in full. The operations reserve starts at zero, so up to 5% of every payout can be retained until it reaches its published target; the numbers are adopted in the statutes of 2026-10-01; no cap is ever raised for a purchase already made. The deductions between a payer's card and a listed recipient are published in full — as components and as one end-to-end figure — on the fee schedule, and the methodology behind the caps is on the money page.

The Association is registrar and witness. It never receives the licence grant and has no distributable private profit — structurally, not by policy: what is passed on goes directly, from the fees account, to the public-benefit organisations on the published Recipient List, which the board keeps — usually about ten to fifteen named organisations anywhere in the world, each in one of the seven categories, each checked by the Association under the Recipient Standard, paid by bank transfer in published shares — and the routing is the row. No recipient is ever added by free text or by a payer's or contributor's nomination alone; a change to the list takes effect only after thirty days' public notice, except a removal for cause or at the recipient's own request, which takes effect at once.