Most grant applications are decided in the milestone section. The thesis says what you believe and the team section says who you are, but the milestone is where a reviewer finds out what the money buys. If that is not clear in a few lines, the rest of the application rarely makes up for it.
It is a learnable skill, and the same one for every program. Below: what a reviewer checks, three before-and-after examples, the most common mistakes, and how milestone size should match the ask.
What a reviewer checks in a milestone
A reviewer reading your milestone is asking one question: on the date you named, will I be able to tell whether this happened? Four things answer it.
- One verifiable deliverable. A single thing that either exists or does not: a contract deployed to testnet, a library release, a hosted demo, a published benchmark. Not an activity (“work on”, “explore”), and not several things joined with “and”.
- A date. A calendar date or a number of weeks from funding. A vague date reads as a vague plan.
- A budget line. What reaching this milestone costs and nothing else, in a few lines (engineering time, infrastructure, review or audit) that add up to the ask.
- An acceptance test anyone can run. A command, a link, a transaction hash, a script with expected output. Someone who has never spoken to you should get a yes or a no from it without asking you anything.
The fourth point is the easiest to skip, and it does the most work. Writing the acceptance test first is the quickest way to find out that the deliverable is not concrete yet.
Example 1: an on-chain AI agent
A fictional agent that rebalances a wallet between a few tokens by rules the owner sets.
Before: “Milestone 1: research and develop the core agent architecture and integrate with DeFi protocols. Timeline: Q1. Budget: $40K.”
After: “Milestone 1, six weeks from funding: the agent runs on a public testnet against one DEX, rebalancing a test wallet between three tokens according to a rule file the owner edits. Spending limits are enforced by the wallet contract, not by the agent. Budget: $18K (two engineers for five weeks, $15K; hosting and RPC, $1K; external review of the wallet contract, $2K). Acceptance: the README links the deployed contract and a public log of the agent’s transactions; a test script tries to exceed the spending limit and the transaction reverts.”
The after version is smaller, names one integration instead of “DeFi protocols”, and answers the question a reviewer would ask anyway: what stops the agent from draining the wallet?
Example 2: a zero-knowledge tooling project
A fictional team making proofs for a common circuit cheaper to generate.
Before: “Research efficient ZK proving techniques and build an SDK for developers. Timeline: 3 months. Budget: $60K.”
After: “Milestone 1, eight weeks from funding: an open-source v0.1 release of a library implementing a Merkle-membership circuit, with documentation and a benchmark script. Budget: $24K (one cryptography engineer for eight weeks, $20K; two weeks of docs and examples, $3K; benchmark hardware, $1K). Acceptance: one command builds the library, runs the tests and prints proving and verification times for three tree sizes, together with the machine specification. Results are committed to the repo so anyone can reproduce them.”
“Research” became a release with a reproducible benchmark. It promises a measurement anyone can repeat rather than a speed-up nobody can check; if you have a performance target, state it as the bar the benchmark must clear.
Example 3: a DeFAI app
A fictional app where a user describes a change to a lending position in plain language and an agent proposes the transaction.
Before: “Launch our AI-powered DeFi platform and onboard our first users. Budget: $75K.”
After: “Milestone 1, seven weeks from funding: a hosted testnet app where a user connects a wallet, types an instruction such as ‘repay half my loan’, sees the proposed transaction with a simulated result, and signs or rejects it. The agent never signs on the user’s behalf. Budget: $30K (two engineers for six weeks, $26K; model and hosting costs, $2K; interface design, $2K). Acceptance: a public demo link, plus a repo script that runs twenty scripted instructions against a test deployment and logs each proposed transaction and its simulation.”
“Onboard our first users” is a hope, not a deliverable. The after version promises only what the team controls: a working flow, a clear safety boundary and evidence anyone can check.
Common mistakes
- Vague “research”. Research is fundable only with an output: a report answering stated questions, a benchmark, a prototype that settles one question.
- Bundling. “The contracts, the agent and the front end” is three milestones. Bundled, one late piece makes the whole milestone late, and a reviewer cannot fund part of it. Split it and ask for the first piece.
- No demo link. “We will present it on a call” makes the milestone depend on you being in the room. A link, a repo or a recording does not.
- Outcomes you do not control. User numbers, partnerships, listings and token prices depend on other people. Tie the milestone to what you ship.
- A budget that does not match the work. A round number with no breakdown, or lines that fund the next quarter, tells a reviewer the milestone has not been thought through.
How milestone size maps to grant size
Size the milestone first and let the ask follow from it, not the other way round. A rough frame, using a range like ours ($5K–$75K):
- Lower end. One component or one question: a proof of concept, a single integration, a benchmark. A few weeks of work for one or two people.
- Middle. An MVP on testnet that someone outside the team can use, like the examples above.
- Upper end. A larger testnet product with several components, often including an external review. Split it into two or three milestones, each with its own date, budget and acceptance test.
These bands are a sanity check, not any program’s rules, ours included: an ask at the top of a range for a proof of concept is a gap reviewers notice first.
How we read milestones
Our one-page grant application template on GitHub has a milestone section built around the four checks above. Fork it for any program, not only ours; to decide where to send it, our Web3 Grants Tracker lists the programs we follow, with stated tickets and stages.
ZK Prime Capital funds on-chain AI agents, DeFAI and zero-knowledge infrastructure through grants of $5K–$75K, with no equity taken. Idea and prototype stage are both welcome, every application gets a reply within 5 business days, and we read milestones with the same four checks. When a funded milestone ships, the team can continue into a $50K–$250K round and a 3–6 month incubation towards a token launch. So far 60+ teams have been funded with $3.1M.
Have a milestone you can test? Write down the deliverable, date, budget lines and acceptance test, then send it to us. Apply with your project ▸