In January 2016, CBS News and The New York Times reported that the Wounded Warrior Project – one of the most visible veterans’ charities in the United States, raising hundreds of millions of dollars a year – was spending around 40 percent of donor funds on overhead, including staff conferences at luxury resorts, first-class travel, and lavish team-building events, while building programs that former employees described as more useful for marketing than for actually helping veterans. After an independent audit commissioned by the board, the CEO and COO were fired that March. The story had been invisible to donors for years. It came out through investigative journalism and whistleblowers, not through any built-in accountability mechanism in how charitable giving works.
That is the structural problem. When a donor gives to a campaign, the money disappears into the charity’s internal systems. Annual reports and Form 990 filings eventually summarize what happened at an organization-wide level, but they arrive long after the fact, aggregate everything together, and are produced by the charity itself. The mechanisms that do provide independent oversight – Charity Navigator ratings, Candid’s transparency seals, BBB accreditation – evaluate organizations on an annual cycle rather than tracking where specific campaigns’ funds actually go. A donor who wants to follow their contribution to a particular relief effort and verify it was spent as promised has essentially no way to do so without the charity’s active cooperation.
We built a protocol and a working proof of concept that addresses this specifically. It uses a smart contract to hold donated funds in escrow, recording every step of the lifecycle – donation, allocation to a purpose, disbursement to a recipient – on a public blockchain. Anyone can query the contract and trace exactly where the money went, in real time, without the charity’s cooperation. We’re publishing a research paper with the full protocol design, architecture, and results, with the source code available on GitHub.
The Core Idea
A charity creates a campaign on-chain with a description hash, a funding goal, and a deadline. Donors send ETH directly to the contract, which holds the funds in escrow – the charity does not receive them yet. When the charity is ready to spend, it first allocates funds to a specific purpose (for example, “water purification equipment for region X”), attaching a hash that links to an off-chain invoice or purchase order. Allocation does not move money; it is a public commitment of intent. Later, the charity disburses allocated funds to a recipient address, attaching another hash that links to proof of delivery. Only at disbursement does ETH actually leave the contract.
Every step is a permanent, timestamped record. Donations, allocations, and disbursements are append-only. The charity retains full operational control – it decides what to fund, when, and who receives the money – but every decision is now a public act rather than an internal one. If a donor wants to see what happened to their contribution, they query the contract. If a journalist wants to investigate spending patterns, they index the events. If a regulator wants an audit trail, it is already there.
The content that matters to humans – campaign descriptions, invoice details, delivery photos – stays off-chain. The blockchain sees only SHA-256 hashes of those documents. This keeps gas costs low and avoids the scalability problems of storing large data on-chain, while still creating a tamper-proof commitment: anyone holding the off-chain document can verify it matches the hash that was recorded at the time.
What the Proof of Concept Demonstrates
The PoC is a single Solidity 0.8.28 contract (DonationTracker.sol) exercised by shell scripts running against a local Hardhat node. No web interface, no backend service, no off-chain storage infrastructure – just the protocol mechanics.
We ran two scenarios end to end. A “Clean Water Initiative” campaign received 5.5 ETH from three donors, allocated 5 ETH across two purposes (filtration equipment and distribution logistics), and disbursed to two recipients, leaving a 0.5 ETH surplus visible in the contract. The full audit trail – campaign state, every donation with its donor and timestamp, every allocation with its purpose and evidence hash, every disbursement with its recipient – was queryable at zero gas cost through plain JSON-RPC calls.
A second scenario demonstrated the refund path. A campaign was created with a high goal and a short deadline, received a single 1 ETH contribution, and failed to meet its target. We advanced the local chain’s clock past the deadline using Hardhat’s evm_increaseTime, and the donor successfully reclaimed their contribution. The refund mechanism uses a pull pattern – donors call refund() themselves rather than relying on the contract to push funds out – which avoids the well-known failure modes where one unreachable recipient can block everyone else.
The gas costs are what you would expect from EVM storage operations. Creating a campaign costs roughly 168,000 gas. Donations are 130,000-185,000 gas depending on whether the storage slots are cold or warm. Disbursements run 190,000-206,000 gas because they include an ETH transfer. At 20 Gwei and $3,000 ETH, the full Clean Water Initiative lifecycle – including contract deployment – came to around $80. Entirely reasonable for campaigns moving meaningful amounts of money, and a strong argument for deploying on an Ethereum L2 for campaigns with many small donors, where the per-transaction costs drop 10-100x.
Transparency, Not Truth
The distinction matters enough to name explicitly. The contract records every transaction accurately and permanently. It does not, and cannot, verify that off-chain evidence is genuine. An evidence hash proves that the charity committed to a specific document at a specific time – it does not prove the document is truthful. A photo of delivered supplies could be staged. An invoice could be inflated. A recipient address could belong to an insider.
This is the honest limit of what a blockchain can contribute here. The value is not that fraud becomes impossible, but that it becomes significantly harder to hide. Every allocation and disbursement is a public commitment. Any mismatch between what a charity claimed and what actually happened is visible to anyone who cares to look – and whatever they find is anchored in a record the charity cannot retroactively edit. That is a real shift from the status quo, where accountability depends on the charity’s own reporting cycles and the patience of external auditors.
There are other limitations worth naming. The PoC handles ETH only, while real charitable giving runs on fiat – stablecoin support and fiat on-ramp integration are the obvious next steps. Donor addresses and amounts are publicly visible, which is pseudonymous but not private. The allocationIndex field on disbursements is a label, not a constraint: the contract does not enforce that a disbursement’s actual purpose matches the allocation it references, though any mismatch is visible to auditors. And the protocol explicitly does not implement donor governance – the charity retains full operational control, and the blockchain only records its decisions. That is a design choice, not an oversight, but it means the protocol is not the right fit for use cases where donors expect a vote.
Where This Fits
The charitable giving space already has several blockchain projects, each solving a different slice of the problem. The Giving Block (acquired by Shift4 in 2022) is the dominant platform for crypto donations to nonprofits – over $300 million processed since 2018 – but it is a donation gateway, not a tracking protocol. Once funds reach the charity, visibility ends. Gitcoin Grants pioneered quadratic funding for public goods, an allocation mechanism rather than a spending one. Alice.si is the closest conceptual predecessor: it pioneered smart contract escrow for charitable funds on Ethereum, gating fund release on verified outcomes. The protocol in this paper takes a less restrictive approach – it records decisions transparently rather than gating them – but Alice’s pilot work with St Mungo’s established that this category of system is operationally practical, not just theoretical.
Outside the blockchain world, GiveDirectly is the reference point. Its model of unconditional cash transfers with a public real-time newsfeed of recipient updates consistently achieves 85-90% of donations reaching recipients, and it does all of this without any blockchain technology at all. The lesson is instructive: radical transparency is achievable and valued by donors. Blockchain is one way to provide it; it is not the only way, and it is not automatically the best way for every organization. What it does offer is independence – the transparency is not contingent on the charity running a particular platform, and the record does not disappear if the charity does.
What’s Next
Stablecoin support is the most immediate practical extension. The modification is straightforward – replace msg.value with ERC-20 transferFrom and whitelist approved tokens – but it removes the biggest adoption barrier for a protocol that charities might actually use. Milestone-based release (gating disbursements on verified outcomes, in the spirit of Alice.si) is a natural follow-up, though it moves the system from pure transparency into evidence verification, where the harder questions live.
Beyond the protocol itself, the evidence-verification gap connects to work we are planning on AI-assisted evidence analysis – extending the same ideas we explored for AI-verified software delivery into a charitable giving context where an automated evaluator checks whether an invoice is plausible, whether a delivery photo matches a claimed recipient, and flags anomalies for human review. The protocol here is the substrate that makes that future work possible: once every decision is on-chain with its evidence hash, an independent verifier – human or automated – can audit at any time, without waiting for an annual cycle.
The full protocol design, architecture, scenario results, and discussion of future directions is in the research paper. The source code, including the smart contract and both demo scenarios, is on GitHub. The code is provided for research and educational purposes and has not been audited for production use.