Size an ecosystem fund from the deployment plan you can actually run, release it in tranches against milestones, and measure what remains after the money stops. The headline number matters less than people think. Arbitrum’s 50 million ARB short-term incentive programme went to 30 protocols, and about 736,000 claimed ARB came back unused when it ended in March 2024.
Who decides this
The head of ecosystem designs and runs the fund, and the foundation council approves its size, mandate and controls. The head of ecosystem is accountable for what the money produces: live projects, users and liquidity that stay. The council is accountable for whether the fund was a sound use of the treasury, whether its rules were followed, and whether the records would satisfy token holders, auditors or a regulator who asks later. When one person both chooses recipients and approves their own budget, the council has given up that second job.
How big should an ecosystem fund be?
An ecosystem fund should be no larger than what the team can deploy well within 12 to 24 months, with the rest held in the treasury until a tranche earns its release. Big announced numbers attract attention. They also attract grant farmers, and they lock the foundation into a figure it then has to defend.
There is a second problem with ecosystem fund sizing when the fund is denominated in the chain’s own token. Arbitrum’s Gaming Catalyst Program allocated 225 million ARB, which The Block reported was worth about $215 million when approved and about $122 million by October 2024, before most of it had been deployed. Avalanche’s 2022 Multiverse programme was announced as four million AVAX, about $290 million at the prices of the day. A dollar headline on a token budget is a snapshot, not a commitment.
We would size from the bottom up. Count the projects the chain needs in its first two years, by category. Estimate what each needs to ship and reach users. Add the operating cost of running the fund properly. Then hold a reserve, because the best projects often appear after the announcement, not before it.
Grants, investments or incentives: which instrument should the fund use?
Use grants for work the chain needs but no one will pay for, investments for teams that can build a business, and usage incentives only for live products with a measurable target. A fund can mix all three. The mistake is running them under one set of rules, because each needs different diligence, controls and measures.
| Instrument | What it buys | Who should decide | How you get money back | What to measure |
|---|---|---|---|---|
| Upfront grant | Infrastructure, tooling, public goods | Small committee with published criteria | Milestone tranches; unpaid tranches stay in the fund | Shipped deliverables, adoption by other builders |
| Retroactive reward | Proven impact, paid after the fact | Reviewers or metrics, published in advance | Not needed; money follows results | Usage and dependency data |
| Investment (equity or tokens) | Teams building businesses on the chain | Investment team with council oversight | Exit, token unlocks, or write-off | Revenue, users, follow-on capital |
| Usage incentive | Liquidity and activity on live products | Programme rules plus per-project caps | Unclaimed tokens returned; clawback for misuse | Activity that remains after incentives end |
In our view, retroactive funding deserves more weight in fund design. Optimism has set aside 850 million OP for Retro Funding and, in 2024, paid 20 million OP to more than 400 builders across three rounds. Paying after impact removes the hardest diligence call: guessing which team will deliver. It cannot fund a team that needs capital to start, so it complements upfront grants rather than replacing them.
Who should control deployment, and how?
A council the foundation or DAO can hold to account should set the mandate, and a small operating team with defined authority should make individual decisions. Reporting should run on a fixed schedule from the first month.
Arbitrum’s gaming programme is a useful design reference. The original proposal, which asked for 200 million ARB before the approved programme was reported at 225 million, put a five-member, DAO-elected council over a venture team housed in a foundation subsidiary. Game publishers had to contribute at least 10% of any grant. A quarterly transparency report was required, and any unused ARB was to return to the DAO.
The design was sound on paper. Execution is where it was challenged. In October 2024, The Block reported that a DAO member argued the programme had not yet issued requests for proposals or considered grants, and proposed recalling 220 million ARB from its 3-of-5 multisig. Offchain Labs representatives responded that legal structure, oversight and hiring made the setup slow. In March 2025, a further proposal to claw back funds alleged opaque reporting and management turnover, according to its authors; the article reported no outcome.
The lesson for a council is narrow and practical. Before approving the fund, require a named operating lead, a hiring plan and a start date. Make the first report due in month one, not month six. Write the conditions under which unused money returns to the treasury into the mandate itself.
How should the fund release money?
Release money in tranches tied to milestones, and phase the fund itself so later cohorts benefit from what the first one teaches. Avalanche planned Multiverse in at least six phases for successive cohorts, which gives a foundation room to adjust between them.
Within each grant or investment, pay a first tranche on signing and later tranches on shipped work. For a developer fund, the milestones should be deliverables other teams can verify: an audited contract, a mainnet deployment, a public integration. For usage incentives, cap the amount per project and per period, and publish the target metric before the programme starts.
Measure after the money stops, not only during the programme. OpenBlock’s analysis of Arbitrum’s incentive programme found grantees added about $13.95 of TVL per $1 of ARB claimed, and that grantee TVL grew 118.2% against 35.6% for other protocols. Those figures cover only the programme period. The analysis did not report what stayed after incentives ended, and that is the number a council should ask for.
What should the council approve before the first token moves?
The council should approve a written mandate, not a number. A good mandate fits on two pages and answers six questions: what the fund is for, which instruments it may use, who decides at each size of commitment, how money is released, what is reported and when, and what happens to unused funds.
Decision rights deserve the most care. Small grants can sit with the operating team under published criteria. Larger commitments, investments and anything that touches a related party should go to the council, with the reasoning recorded. Conflicts should be declared in writing before each decision, not once a year.
The mandate should also say how the fund ends. Set a deployment period, a review point halfway through, and a rule for what happens if the fund is behind plan at that review. A fund with no end date tends to drift. A fund with a review point gives the council a natural moment to cut, redirect or extend it, without a public fight.
Finally, keep the records from day one. Every application, decision, payment and report should sit in one place the council can read. Those records are what the foundation will need when token holders ask what the fund produced.
What goes wrong: distribution left to chance
The common failure is a fund that pays for building and assumes users will follow. Grants go out, projects deploy, the announcement thread does well, and six months later the funded applications have little activity and thin liquidity.
The cause is usually that distribution was nobody’s job. The fund paid teams to ship. No one planned how those projects would reach their first users, where launch liquidity would come from, or which wallets, exchanges and media would carry them. Each team was left to solve distribution alone, on a new chain with a small audience.
The fix belongs in the fund design. Budget for distribution alongside building: launch support, liquidity planning and co-marketing for each cohort. Make a funded project’s go-to-market plan part of the application, and review it with the same care as the technical plan.
How Alcyone approaches it
Alcyone treats an ecosystem fund as a launch plan with a budget, not a budget with a launch plan attached. The work starts with the projects the chain needs, the order they should arrive in, and how each will reach users and liquidity, and only then sizes the fund and its tranches. Every part of the plan has a named owner. Alcyone’s ecosystem and launch advisory work includes a major Layer-1 where the first token launch on the chain left about $10M locked in vesting. Engagements start with a thirty-minute call with a senior partner and a fixed-scope, fixed-fee assessment credited against further work.