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. University research support, TLDR, UF Research Studio, protocol experiments. |
All applications are assessed against three questions before moving to full review. If the answer to any is no, the application will not advance.
1. Does this belong in the Uniswap grants program?
Your proposal should clearly 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 — not a commercial product seeking a subsidy?
Grants fund work that creates value for the broader Uniswap ecosystem. If the primary beneficiary is your own commercial product, this is a different kind of relationship (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.
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.
Budget breakdown. Provide funding allocated across line items (development, infrastructure, audits, operational costs). A reviewer should be able to determine whether the rates are reasonable for the work described. A flat dollar amount with no breakdown does not meet this requirement.
Verifiable traction claims. If your application references user numbers, TVL, volume, or deployments, they must be verifiable — onchain data, public dashboards, app store listings, GitHub activity, etc.
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.
The following are handled through other programs. If your project falls into one of these categories, we'll point you in the right direction.