We fund work that expands, strengthens, and advances the Uniswap ecosystem. Before applying, review the categories below and make sure your project is a good fit.
| Category | What we fund | Strategic focus |
|---|---|---|
| Ecosystem Grants | Infrastructure, tooling, developer adoption | Expand the builder ecosystem. Supply-side: liquidity tools, infra partnerships, protocol integrations. Demand-side: developer onboarding, SDKs, education. |
| Governance Grants | Governance infra and experimentation | Modernize and decentralize Uniswap governance. Autonomous funding mechanisms, multichain governance contracts, security for token voting. |
| Community & Events Grants | Developer events, hackathons, ambassador programming | Build the global community of Uniswap builders and researchers. In-person events, virtual hackathons, ambassador programs, delegate engagement. |
| Security Grants | Audit subsidies and open security infrastructure | Strengthen the safety of the Uniswap ecosystem. Audit subsidies run through UFSF/Areta. Open Security Fund for broader security tooling. |
| Research & Implementation Grants | Academic research, protocol experimentation, applied research programs | Advance the scientific frontier of Uniswap. Structured research support, protocol experiments, and novel ideas are welcome. |
1. Does this belong in the Uniswap Foundation Grants Program?
Your proposal should reference Uniswap's ecosystem, technical architecture, or strategic priorities. Make it clear why this work belongs here, and show that you understand the ecosystem and where your project fits within it.
2. Is this a public good or ecosystem contribution or a commercial product seeking a subsidy?
If the primary beneficiary is your own commercial product, this is a different kind of relationship (e.g., a partnership, integration support, etc.). Ask yourself: would the output be useful to builders, LPs, or users beyond your own product?
3. Is the work forward-looking with defined deliverables?
Your proposal must include specific deliverables, not just a general direction. "Improve developer tooling" is a direction. "Build a v4 hook testing framework with X, Y, Z capabilities, delivered in three milestones over six months" is a proposal.
4. What does the Uniswap ecosystem get, and how will you measure it?
Name the value to Uniswap and how you'll measure it: durable liquidity in a major quote asset (not your own freshly minted token), real volume, retained users, fees, or reusable open tooling. Weigh it against what Uniswap already provides: routing swaps or creating pools only count when they add something new. Raw counts such as registered users, pool numbers, or self-priced TVL are not, by themselves, valuable.
The following are required for your application to be reviewed. Missing any of these will result in the application being returned.
Technical plan. Include your architecture decisions, technology choices, and implementation approach. The level of detail should scale with the ask. A reviewer should be able to read your technical plan and understand what is being built and how it is being built.
Budget breakdown. Provide funding allocated across line items (development, infrastructure, audits, operational costs), and map those costs to your milestones and deliverables so a reviewer can see what each milestone costs and what the funding buys. A reviewer should be able to determine whether the rates are reasonable for the work described. A flat dollar amount or a budget not tied to your milestones and deliverables does not meet this requirement.
Verifiable traction claims. If your application references user numbers, TVL, volume, or deployments, they must be verifiable through onchain data, public dashboards, app store listings, or GitHub activity. Verifiable is not the same as valuable: we look for real economic activity (quote-asset liquidity, swap volume, retained users, fees), not vanity counts. State volume and TVL in a major quote asset; figures that price your own freshly issued token at its own pool price will be discounted.
Milestone structure. Break your deliverables into stages with clear timelines. Milestones should reflect outcomes, not just outputs. Each milestone should be something that can be checked as delivered or not delivered.
Team identification. Include named individuals with verifiable history: GitHub profiles, prior shipped work, ecosystem participation. First-time builders are not disqualified, but the ask should be scoped accordingly — smaller grants, tighter milestones, proof-of-concept scope.