How we compute this

• ZCG public spreadsheet: The disbursements ledger, recipient and classification pivots, and ZCG and Coinholder proposal history. Collection is scheduled every six hours. A successful collection does not mean the source was recently edited.
• GitHub issue tracker: Live grant applications (ZcashCommunityGrants/zcashcommunitygrants), read first-hand from open issues: applications carry the “Grant Application” label, and “Ready For ZCG Review” marks the queue awaiting the committee's judgement. Hand-filed re-applications can arrive without labels and are recognised by their title; an open application with no decision label counts as awaiting review. This is the rawest stage, before anything reaches the spreadsheet. The issue list is cached for about fifteen minutes.
• Zcash Community Forum: ZCG meeting minutes, imported from the Discourse #grants category during the six-hour cycle, best-effort: a failed forum import never marks the collection stale.
• On-chain (lightwalletd): The Lockbox / ZIP-1016 ZEC balance: the latest spreadsheet Lockbox snapshot plus protocol-deterministic accrual (0.1875 ZEC per block, ZIP-1015) up to the live chain tip, which lightwalletd supplies read-only. No viewing-key scans run. Market prices, grant approvals and milestone delivery are not facts supplied by the chain.
• CoinGecko, CoinPaprika, Coinbase: The current ZEC/USD market price from CoinGecko, or from CoinPaprika and then Coinbase when CoinGecko is unavailable, cached for approximately ten minutes; every quote names its provider and quote time. If all three are unavailable, the last cached price or the spreadsheet's recorded rate may be used. This price is not read from the Zcash chain.

When sources disagree, the disagreement is published rather than blended, and each figure names the source that wins for it:

• Grant payments, budgets and recipient totals: the official spreadsheet is the primary ledger. OpenZcash mirrors it; it does not correct it.
• Proposal status: a committee decision visible on GitHub is shown until the spreadsheet records the same verdict; once the spreadsheet's verdict is publication-eligible, it takes priority.
• Application text and requested amounts: the GitHub issue is first-hand.
• Third-party grant lists (for example the pgpz prototype API) are supplementary: never a substitute for ledger totals, and disagreements are flagged rather than silently resolved.
• The forum provides discussion and minutes, not figures.

Every source runs on its own schedule, and none of these timestamps describe when the underlying source was last edited. A stale pull does not imply a stale source; a fresh pull does not imply a recent one.

On the totals page every classification is labelled by its nature, so a reader can tell a grant apart from ZCG spending on itself:

• Grant: funding paid to an external project or contributor.
• ZCG operations: the committee's own budget (travel, conferences, tooling); the ZCG Discretionary Budget bucket.
• Committee stipends: salaries paid to ZCG members; see stipends.
• Security · audits: third-party security audits and bug bounties (the Audits classification). Bounties also appear as milestones inside individual grants.

The discretionary budget appears two ways, and the two numbers differ on purpose:

• The ZCG operations figure on the totals split (~$1.8M) comes from the totals pivot: the cumulative classification total published in the spreadsheet.
• The discretionary budget tab ($1M annual cap, ~$1.27M spent) is a separate annual worksheet.

Two readings of the same programme at different scopes (cumulative pivot vs. annual budget). That is why the totals page shows a live ledger-vs-published cross-check instead of asserting they match.

Three quantities appear across this site. They describe different things and must not be added together:

• Budgeted USD: includes paid and unpaid entries, including amounts recorded for cancelled grants.
• USD paid: the budgeted value of entries marked paid, not their current market value.
• ZEC paid: the quantity recorded by the spreadsheet, at its own recorded rate.

Historical ZEC is never revalued at today's price. Treasury USD valuations use the available market price; historical entries keep their recorded rate. The reconciliation page shows ZEC paid and USD paid side by side: read them as two columns of one ledger, not one total.

An approval is not a payment. A recorded payment is a ledger entry, not independent proof that a milestone was delivered or that it had impact. Unpaid entries are not necessarily outstanding commitments: check the grant's status and the original source. Cancelled grants remain inside some budgeted totals and are labelled as such.

This is the rule agents quoting these figures repeat: Zarvis and the published ZCG copilot skill state the same thing.

The transparent treasury reveals aggregate flow only: the Lockbox feeds ZCG's operating treasury, which moves ZEC into the shielded pool. Individual grantee payments leave the shielded pool and are private by design; auditing them one by one would require ZCG's shielded viewing key, which OpenZcash does not hold or use. The cross-check is stored treasury flow plus spreadsheet integrity — never a per-payment on-chain proof. Current figures and the stored scan: reconciliation.

Every number here is queryable. /api/zcg is a read-only JSON index of the endpoints; the data endpoints under /api/zcg/data/ (disbursements, recipients, grants) also return CSV via ?format=csv. Disbursement rows carry provenance: the source sheet and row, a link to the live source row, and the collection time — which is retrieval, not publication.

Spot a wrong figure? Open an issue at github.com/Michae2xl/openzcash/issues. Source corrections reach this site on the next scheduled collection and are recorded automatically in the overview changelog and the RSS feed. Errors in this site's own copy are fixed in the repository.