Use cases
Situations where many people are paid from one pool and the total has to be checkable.
Tally fits anyone who pays many people from one pool and has to account for it in public. The README names grant programmes, bounty platforms, public-goods funding and aid disbursement. The cases below follow the same pattern.
Tally has no users or integrations today. These are the situations it is built for, not deployments. Anything marked "needs the operator service" depends on work that is designed, not built.
What every case gets today
- Amounts sealed on the ledger; addresses public.
- A round declared on-chain before payment, with a fixed window.
- One zero-knowledge proof of the total from the declared lanes, checked by a donor or auditor with their own key.
Grant programmes
Situation. A programme pays many grantees. Publishing each award can expose grantees or create pressure on them, but funders want to see the money went out.
Today. Run each payout batch as a round. Give funders the round id and the funder address; they verify the total themselves.
Needs the operator service. An auditor reviewing a specific grantee's payment under a scoped request.
Hackathon prizes
Situation. Organisers pay several winners and want to show the full prize pool was paid.
Today. One round per event. The proof refuses to cover fewer than 5 transfers, so very small prize lists are not a fit without padding the round with more transfers. See Minimum group size.
Payroll
Situation. Salaries on a public ledger are visible to everyone, including colleagues.
Today. Each pay run is a round; an auditor or finance reviewer can check the payroll total.
Needs the operator service. Per-employee statements for tax purposes, and auditor access to individual payments under a scoped request.
Aid disbursement
Situation. Publishing what each recipient received can make them a target.
Today. Amounts stay sealed; donors verify the total per round.
Limit. The proof does not show that recipients are independent of the payer. See Known limits.
DAO contributor payouts
Situation. A DAO pays contributors from its treasury and wants members to check outflows without exposing each contributor's payment.
Today. One round per payout cycle, with the treasury's lane accounts declared on-chain.
Tax and audit reporting
Situation. An account holder needs a statement of what they paid or received for a period; an auditor needs access to specific payments.
Needs the operator service. Both are designed, not built: a tax-export statement generated by the holder with their own key, and scoped audit requests answered by split-custody auditor keys. See Operator design.