How to write a grant milestone report

What funders ask for

Reporting rules differ by program in timing, audience and what the report triggers. Here is what ten programs in web3grant's directory require, from their own documentation as checked on October 1, 2026:

VeBetter grantees now post milestone reports on their proposal pages, and Akash's community pool asks funded teams for status updates and public spend records. Three of these programs carry notices on their web3grant pages: Rocket Pool says funds are tight, no outside team has won an Akash vote since August 2025, and VeBetter's activity is very low. Their reporting rules still show what funders expect.

The seven parts of a strong milestone report

A report that gets approved quickly answers seven questions, in this order:

1. What did you promise? Quote the milestone exactly as written in the agreement, with its due date. Reviewers check against the text, not your memory of it.
2. What shipped? List each deliverable with a plain status: done, partly done or not done.
3. Where is the evidence? Link something checkable for each deliverable: a merged pull request, a release tag, a deployed contract address, a transaction hash, a live URL, a published audit.
4. How do the numbers compare with the targets? If the milestone set metrics, give target, actual and the source of the actual number. Our guide to grant impact metrics covers which numbers to use.
5. How does spending compare with the budget? Show planned and actual spend by budget line, and explain any variance over about 10%.
6. What changed, and why? Name every change to scope, dates or budget, the reason and what you propose.
7. What comes next? Restate the next milestone's deliverables and date, and list anything you need from the funder.

Weak and strong answers

The difference is usually specificity. These examples are fictional.

Weak: "We made great progress on the SDK and the community response has been amazing."

Strong: "Deliverable 2, TypeScript SDK v0.3: done. Published to npm as v0.3.0 on October 14 (release link). 41 of the 45 planned functions are implemented; the remaining 4 move to milestone 3, see Changes."

Weak: "Adoption is growing fast."

Strong: "Target: 5 integrations by October 31. Actual: 3 live (links), 2 in review with partner teams. Source: our public integrations page, updated weekly."

Should a milestone report be public or private?

It depends on the funder, and DAO-run programs lean public. Proposals and milestone reports for the CKB Community Fund DAO are fully public, Zcash and TRON grantees report on forums, and Brink grantees give regular public progress updates. Foundation programs often take reports directly, as the Tezos Foundation and Kaia's IOK Fund do.

A public report has two audiences: the reviewer who approves the payment, and the token holders or community members who will vote on your next request. Write it so a stranger can follow it without your Discord history. For treasury-funded work, a clean public record is what voters check next time; our guide to blockchain treasury funding explains why.

Keep some things out of any public report: security vulnerabilities that aren't fixed yet, personal data, KYC documents, private user data and partner terms covered by an NDA. Send those to the funder privately, and say in the public version that you did.

Akash's public spend reporting: a real example

The Akash Community Pool shows what fully public reporting looks like. Every funding request starts as a public draft with a TL;DR, timeline, amount and a cost breakdown in hours and hourly rate. If the on-chain vote passes, the team posts status updates and records its spending in the Community Pool Spend Reporting folder in Akash's GitHub community repository, where anyone can compare it with the original request. The Akash grants page describes the process.

Two lessons carry over to any program. Report spending in the same format as the budget you proposed, so the comparison takes seconds. And because the grant is paid in AKT, record both the token amount and its dollar value when received, since the two drift apart. As of October 2026, no outside team has won an Akash community pool vote since August 2025, so this is an example of reporting practice rather than an easy source of funding.

How to write the report: tone and habits

The best milestone reports read like a status page, not a pitch:

• Lead with the status. The first sentence should say whether the milestone is complete, partly complete or late.
• Use numbers, not adjectives. "3 of 5 integrations live" beats "strong traction".
• Keep it short and link the detail. One or two pages, with links to code, dashboards and documents.
• Use the same structure every time. Reviewers learn where to look, and comparisons across milestones become easy.
• Answer earlier feedback. If the reviewer asked a question last time, answer it near the top.

When a milestone slips

Tell the funder before the due date, not after. Say what slipped, why, what it does to the rest of the plan and what you propose: a new date, a smaller scope or a reallocation. If the change affects scope or payments, ask for it to be recorded the way your grant agreement requires. A short, honest delay notice protects your next grant far more than a late report with excuses. Our guide on what happens after you win a Web3 grant covers the rest of the grantee's obligations.

Milestone report template

Copy this, fill in the brackets and delete what doesn't apply.

Milestone report: [project name], milestone [N] of [total]
Grant: [program name, grant ID]   Period: [start date] to [end date]
Submitted: [date]   Contact: [name, handle, email]

1. Summary
[Two or three sentences: complete / partly complete / late,
the main result, and anything the reviewer needs to decide.]

2. Milestone as agreed
[Paste the milestone text and due date from the agreement.]

3. Deliverables
- [Deliverable 1]: [done / partly done / not done]
  Evidence: [PR, release tag, contract address, tx hash, URL]
- [Deliverable 2]: [status]
  Evidence: [link]

4. Metrics against targets
- [Metric]: target [x], actual [y], source [dashboard or query]

5. Budget
- Planned for this milestone: [amount]
- Spent, by line: [engineering, audit, infrastructure, other]
- Received so far: [token, amount, value at receipt]
- Variance and reason: [explanation]

6. Changes and risks
- [What changed, why, effect on scope, dates or budget,
  and what you propose]

7. Next milestone
- Deliverables and due date: [list]
- Requests to the funder: [reviews, intros, approvals]

For the budget lines, mirror the structure you used in your proposal; our Web3 grant budget guide has one. If you are still writing the proposal, our guide on how to write a Web3 grant proposal shows how to set milestones you can report on cleanly.

FAQ

How long should a grant milestone report be?

A grant milestone report should usually be one or two pages, with links to the detail rather than the detail itself. Reviewers want status, evidence, numbers against targets and spending against budget, in that order. A long narrative slows approval. If a program gives you a template or form, follow it exactly and keep your answers within it.

What evidence do grant reviewers accept in a milestone report?

Grant reviewers accept evidence they can check themselves in a few minutes: merged pull requests, tagged releases, published packages, deployed contract addresses, transaction hashes, live URLs, public dashboards and audit reports. Screenshots and private demos are weaker because they can't be verified. For metrics, link the query or dashboard that produced the number, not just the number.

What should I do if I miss a grant milestone?

If you miss a grant milestone, tell the funder before the due date if you can, and send a short report anyway. Say what is done, what slipped, why, and propose a new date or a reduced scope. Programs that pay per milestone will usually hold that payment until the work is delivered, so an agreed revision is better than silence.

Should I publish my grant milestone report?

Whether to publish a grant milestone report depends on the program's rules. Many DAO-run programs, such as the CKB Community Fund DAO and Zcash Community Grants, expect public reports on their forums, while many foundations take them privately. Even when private reporting is allowed, a public summary builds the track record you will need for your next grant.