As we prepare for Gitcoin Grants 24, this post floats adopting a Fair Fees model for attracting and compensating round operators by covering their costs (including software, servicing the rounds). This fee would be sent directly to the round operators running rounds running in GG24.
The fair fees model, originally published on ethresear.ch, introduces a transparent, scale-sensitive fee formula that rewards early-stage builders and avoids over-taxing large rounds.
Motivation
As Gitcoin no longer has a software team nor runs most rounds itself, I believe it is essential that we can attract world class round operators and software teams. These fair fees would be a part of attracting, aligning, and retaining those teams in the Gitcoin ecosystem.
The Proposal
Adopt the following formula to compute fees on a domains matching pool size (N):
fee ≔ max(√(1000 × N), N × 0.01)
For small domains, this generates proportionally higher fees to help fund software development and operations.
For larger domains, fees cap at 1% of the pool.
This produces a smooth, predictable curve where protocol fees decline with scale.
This would be a default policy for GG24 domains or rounds receiving Gitcoin ecosystem support (e.g. on coordination, matching, and/or legitimacy).
Sustainable: Generates meaningful revenue for round operators, especially for smaller or experimental rounds.
Fair: Reduces fees on larger rounds, ensuring capital flows primarily to builders and grantees.
Simple & transparent: Anyone can compute the fee for a given pool size in advance.
Attracts talented software developers and round operators to Gitcoin
Example Fees Under Fair Fees
Pool Size
Fee (Fair Fees)
% of Pool
$100k
~$10,000
10%
$500k
~$22,360
~4.5%
$1M
~$31,622
~3.1%
$5M
~$70,711
~1.4%
$10M
$100,000
1%
$50M
$500,000
1%
Optional (for later discussion)
We may explore an “accrued fee” implementation, where fees are calculated incrementally as round operators run multiple rounds (eg round operator x24 for domain y24 in GG24 runs a domain y25 in GG25). This is not part of the current vote but could be piloted in future rounds.
We could explore offering the revenue to the operators if they agree to treat the fees as an investment and give Gitcoin upside in their software startup, either in the form of tokens or equity.
We could explore augmenting the fair fees formula to make it more or less aggressive.
Temp Check Options
How should we proceed for Gitcoin Grants 24?
Yes, adopt Fair Fees
Yes, adopt Fair Fees but with changes (eg only if upside is given, or augmenting the formula)
No, do not adopt Fair Fees
Abstain
Please vote by 9/1/2025, and feel free to share feedback or suggested tweaks to the formula in the comments.
It would be nice to have a comparative study between overhead spent before GG23(basically gitcoin tech costs) vs from after GG24 (after domains introduction).
They aren’t exactly comparable since now we are taking overhead from the matching fees but would still give us some idea of the cost savings from this approach
This is a really great segment and think we can set a standard for mechanism builders to adhere towards. I expect some of the core gitcoin rounds like with @MathildaDV leading OSS wll be on the higher end where fair fees would apply, but most might be in the lower range so we’d see 8-10% as overhead - which is actually close to what we see in the traditional world
To take some of this discussion forward - i wonder how much this applies to mechanisms that have been tried out already in other areas.
for eg, the butter team has tested their mechanism for optimism and uniswap for over 2 million. so would fair fees apply to those earlier mechanisms too or would it restart and be specific to their domain?
ideally if each domain owner has their own smart contract thats being reused, we could actually apply the fair fees formula to even rounds held outside of gitcoin.
This fee model is generally reasonable, but the 10% fee rate for small pools may place significant pressure on many early-stage or experimental projects.
It is recommended to introduce a tiered subsidy mechanism to prevent fee-related barriers from impacting ecosystem diversity and innovation vitality.
Optimized Fair Fees Model
Introduce a tiered subsidy to reduce fees for small matching pools, easing the burden on early-stage or experimental projects:
For matching pools smaller or equal to TT, the fee is discounted by factor α\alpha to help fund early-stage and experimental rounds without heavy fee pressure.
For pools larger than TT, the standard fee applies, preserving fairness and scale economy.
This approach balances sustainability with inclusivity, encouraging more diverse and innovative projects.
Glad we’re discussing budgeting and rewards proactively. Hitting the operator and program economics right is key for sustainable growth.
The current proposed “fair fee models” seem to optimize for low-touch rounds. The proposed fees are too low to attract, retain, and grow top-tier operators.
From my experience and research, traditional non-profits, innovation, and development programs have significant operations and fundraising costs. Operations is often 10-15% of the budget, with 5-10% dedicated to fundraising/marketing.
Due to recent tech innovations and better frameworks, we should be able to cut these costs down significantly; however, aiming for 1% may be unreasonable.
Ultimately, our objective is to allocate funds most effectively. To accomplish better and more impactful rounds over time, we should provide enough resources for round operators to:
design and execute the best rounds,
find and fundraise from the best partners,
conduct R&D efforts to improve round effectiveness,
support round participants pre and post round, and
have some profit/leeway to bridge into the next round.
My suggestion
Instead of a fixed fee, align on fee ranges. DDA would have to provide clear plans and argumentation if they want to request above-average fees.
Pool Size
Fee Range
% of Pool
$100k
$10,000 - $15,000
10% - 15%
$500k
$25,000 - $50,000
5% - 10%
$1M
$40,000 - $80,000
4% - 8%
$5M
$150,000 - $350,000
3% - 7%
$10M
$250,000 - $600,000
2,5% - 6%
$50M
$1,000,000 - $2,500,000
2% - 5%
In addition to being 2-3x more cost-effective than current best practice programs, we should also aim to outperform in measurability, transparency, and speed. By doing so, we will be able to provide a strong offering to larger, non Web3-native funders.
Love the potential of this approach and agree with @LuukDAO on the fee range.
I also align with the tiered subsidy suggested by @hello2jie
I think another area to address is frequency, what’s the target amount of rounds over a period of time that makes this sustainable for builders and operators. Also how does the implementation of fair fees look with DDAs?
For example, if a DDA plans to do multiple localism rounds would fair fees need to be applied following the Gitcoin requirements or this will just be on the funds Gitcoin provides DDAs?
We agree with the core direction of this proposal, but we share @LuukDAO’s concern that the current model underprices operator compensation for larger rounds.
Especially in the early Gitcoin 3.0 phase, it feels risky to start with incentives that are this thin.
A better approach could be to begin with a relatively higher fee structure to ensure we can attract and retain top-tier operators who will invest in building strong, sustainable rounds.
Over time, as the ecosystem matures and we can enable more permissionless participation, competitive dynamics could naturally drive fees lower.
Starting high and tapering down seems more aligned with long-term sustainability than locking in low incentives from the outset.
do you or @LuukDAO (or anyone else on the thread) want to fork the model and propose an alternative scheme? the model is configurable so it should be possible to tweak these variables and come up with an alternative that matches your values
I used a min fee of 3% and a max fee of 20% with 2.5 decay, which comes close to the ranges I suggested for programs up until 1M, which is most relevant at the current stage.
For programs above 1M USD in funding, I think the decay could be lower; however, at the same time, program duration would likely increase significantly/ A different model that includes a time dimension could be created for this.
To operationalize a first version of the Fair Fees Model, I suggest the following:
Use a Fair Fee Model, which could be the version I created if we want to increase the attractiveness to operate a DDA and innovate, as a benchmark for fees.
Have DDA operators specify the exact fee to be charged, with a breakdown of A. personnel costs, B. overhead costs (e.g., legal, marketing), and C. software development and usage costs (e.g., smart contracts and AI).
The combined costs of the DDA, including any fees to Gitcoin or other third parties, should be within a reasonable range of the Fair Fee Model benchmark.
To start, I suggest a maximum threshold of 25% above the suggested fee according to the Fair Fee Model in cases where personnel, overhead, and software costs are justifiably contributing to increasing the outcome of the DDA and its ability to fundraise pre- and post-program.
Just a basic question - is this fee coming from the matching pool? 100k round gets paid $10k in a fee… and so then the round itself costs the matching pool $110k ?
The next question is, (and this is likely in the GG24 post?) how are pool sizes determined and eligibility evaluated?
the round funding sources of the round can include the matching pool but needn’t be only the matching pool. ideally in gitcoin 3.0 era we become better at getting matching on matching on matching (thx @syntropicregen for this meme!)
there are two ways we could go.
total is $100k from the funding sources (inc matching pool) and 10% taken from that.
total is $110k from the funding sources (inc matching pool) and 10% is taken from that.
i believe the plan is to do a GTC vote and allocate proportionally to how that unfolds.
we can evolve more complexity/powerful ways to do it from there (there are a lot of more interesting ideas floating around - condorcet voting, web of trusts, etc, but i think were starting simple and evolving ways to allocate funds from a domain to a subdomain from there)
And to be clear, every step needs to be ratified by governance through a GTC vote. Eligibility for domains is already laid out and only eligible domains will go to a vote. Echoing what @owocki has said, the idea is to start simple in GG24, and expand the complexity and scope moving forward.
Example Fees Under Fair Fees
Yes, adopt Fair Fees
No, do not adopt Fair Fees
Abstain
