Skip to content
Menu

Transparency ledger / 2026-09

Ledger 2026-09

Open. The month has not locked. Under the lock-before-sweep rule each payout's allocation is locked before its transfer; the payouts credited in a month are locked together after the month ends, and each listed recipient's share is sent directly from the fees account in a transfer normally initiated on the first bank working day of the following month, within sixty days of each payout's credit. Nothing in this month is allocated or transferred yet; allocation data arriving after the lock counts for the next month, forward-only.

The lines the bank books on the fees account in 2026-09 are published once the month locks: the fees account statement 2026-09.

Totals

Every total is a sum over the rows below and over nothing else. Computed at 2026-10-26T05:37:42Z · rebuilt every six hours.

Rows 0
Intake so far CHF 0
Refunds and chargebacks CHF 0
Received — allocation pending, locks before the sweep CHF 0
Month digest 4f53cda18c2baa0c0354bb5f9a3ecbe5ed12ab4d8e11ba873c2f11161202b945
Chain head after this month 0000000000000000000000000000000000000000000000000000000000000000

Rows carrying a figure

This month has no rows

No money has moved yet, so there is nothing to list here. The month is published all the same, with the digest shown under Totals above: an empty month and an absent month are not the same thing.

How this month was produced

  • Append-only: a committed row is never edited or deleted. Corrections are new rows; annotations render as annotations, never as edits (FS07-042).
  • Row hashes chain globally in seq order: rowHash = SHA-256(prevHash ‖ JCS(row minus its two hash fields)), RFC 8785 canonical JSON. The published row is the hashed row — the same member names, nothing renamed on the way out — plus its date, which sits outside the hashed body. Drop those three and the chain re-walks from the export alone.
  • Month digest: SHA-256 of the RFC 8785 canonical text of this month’s rows as published here — an array in seq order, complete rows including their two hash fields.
  • Lock before sweep, one clock per payout: each payout’s allocation is locked before its transfer; the payouts credited in a month are locked together after the month ends, and each listed recipient’s share is sent directly from the fees account in a transfer normally initiated on the first bank working day of the following month, within sixty days of each payout’s credit. Allocation data arriving after the lock counts for the next month, forward-only; a reversal after a transfer is a forward-only row, and a recipient’s share is never clawed back, except an amount paid twice, beyond the share, to the wrong recipient or through deception.
  • The annual cap on direct costs charged to fees: charged to fees is the period’s itemised direct invoices paid from the fees account that no listed supporter settled — including the transfer charges on the outbound transfers — one row per invoice, tested against the cap over the financial year, never a percentage of the pool.
  • The whole methodology, in words: where the money goes.

Machine access: /v1/ledger/2026-09.json and /v1/ledger/2026-09.csv, which carries the same rows flat. Same-origin copies at /artifacts/ledger/2026-09.json and this month's rows as CSV. Chain head and month digests: /v1/ledger/chain.json.