I want to kick off discussion for how the incentive grant allocation process could be improved in the next round by proposing a new process. The Arbitrum DAO learned a lot from this STIP and I think we should start figuring out how to iterate on this program now while the experience is fresh in our minds.
My proposal is meant to address two issues:
Grant amounts per project in the STIP were arbitrary and chosen by the projects themselves. Delegates were then forced to vote yes or no on the grant with little practical ability to influence the grant’s size. For example, a delegate might have thought that project X should have gotten more like 1M ARB instead of 3M ARB, but their choice was between 3M ARB and zero so they weren’t able to express their preference very well.
Grant allocations were dominated by established Arbitrum projects. I think these projects probably deserve the majority of the allocation, but I also believe that it is important to encourage newer and smaller projects with grants in order to promote innovation and growth within the Arbitrum ecosystem. The STIP failed to do this in my view because it put new projects in direct competition with established projects for funding.
I think that this process would address the issues listed above and be a fairer and more effective way of distributing incentives in the future.
The DAO authorizes two separate tranches of incentives, one for larger grants and one for smaller grants. For example, the DAO might authorize 50M for larger grants and 10M for smaller grants. Projects are free to apply to either category, but they have to choose one. Newer projects would be encouraged to apply to the smaller category because they would have a greater chance of getting funding by choosing that category.
DAO authorizes four grant size buckets per tranche. Ex the larger grants tranche might have the following bucket sizes:
a. Small - 100k ARB
b. Medium - 500k ARB
c. Large - 2M ARB
d. Extra large - 5M ARB
Protocols choose a funding tranche to apply for, submit proposals and state how they would use the grant depending on how much they get.
When proposals are put up to vote, token holders get to choose between five options per proposal - small, medium, large, extra large, or no grant at all.
A vote for a grant of any size is considered a vote in favor. All projects that make quorum and get >50% of votes in favor of a grant are eligible to receive a grant.
The amount that an eligible proposal would receive would be calculated as the weighted average of the votes in favor. So if a proposal got 50% of the “yes” votes for a large size (2M ARB) and 50% of the “yes” votes for a medium size (500k ARB), their grant size would be 1.25M ARB.
Proposals are ranked by the grant amounts calculated in step 6 from highest to lowest. We then go down the list and award grants to the recipients until the total incentive spend authorized by the DAO in step 1 is reached.
The projects themselves are best positioned to calculate how big their grant request should be and I don’t think that should change. Delegates did have the opportunity to influence projects’ grant size during the review period, and a lot of projects did alter their requests based on feedback received.
The problem wasn’t so much the process in my opinion (at least not completely), but rather the volume of applications received compared to the time available. I know that we at L2BEAT didn’t have time to review all applications during the review period, provide feedback, keep up with updated proposals and provide follow-up feedback only to review all finalised proposals again before voting. The capacity simply wasn’t there because there were over 100 applications, each of which requires a considerable amount of time to review and do due diligence and cross-checks on.
I 100% agree with that. However, there were several small projects requesting outsized grants simply because of the total budget available. A smaller category with a smaller budget might be a better approach to mitigate such occurrences.
I think there were a lot of lessons to learn through the STIP and how it came down, all of which will hopefully be integrated the next time around. I urge you, and any other person who has feedback regarding the program to join the 7th Governance Call this coming Wednesday (18 October) at 4pm UTC (more info on the call later today) so we can collectively reflect on our learnings.
I think you make fair arguments and I will definitely join the governance call this Wednesday! However I want to respond to one point in particular where I disagree with you:
I think the current process is suboptimal. The way it works now requires an initial phase where the delegates have to give feedback on size, and the projects have to go out and solicit feedback and then come back with a size that they think everyone will support. The problem is that this requires a lot of engagement from delegates. If delegates don’t engage with your proposal during the comment period (like in Notional’s experience for example) then you don’t know if you should increase or decrease your number. It is only reasonable to expect delegates to engage like this on a small number of the largest and most important proposals. So fundamentally, this process doesn’t scale.
If you allow delegates to vote on their preferred size for a particular proposal, you remove the need for this high-touch back-and-forth period which allows delegates to operate more efficiently and for a significantly larger number of proposals to receive effective consideration.
Deciding Grant Amounts:
Projects should be the ones to tell us how much funding they need. It’s their vision, and they understand their needs best. However, it’s crucial they don’t just throw out big numbers without good reasons. If the amount they ask for doesn’t make sense, delegators should have a comment in it. They should be able to suggest a more fitting amount or ask for more clarity.
For smaller projects, especially, they must be clear and honest. They should ask for what they genuinely need, not just a high amount because it’s available. More importantly, they must clearly explain how they will use the grant. A clear plan ensures trust and transparency.
Big Projects vs. Small Projects:
I’ve observed that larger, well-known projects often have an edge. They’re in the limelight and naturally attract more funds. But if we always pour most of the money into these big projects, we’re unintentionally deciding the market leaders and sidelining the smaller projects. This could reduce new ideas and creativity in the long run.
I’m fully behind the idea of having two separate pools of funds: one for big projects and one for smaller ones. Criteria like the total value they handle, their volume, and how involved their users are can be solid metrics to decide who falls into which category.
I’ve been a long-time reader of this forum, though I only recently registered. I concur with your suggestion that there should be two distinct categories, each with its own range of grants.
Category 1: Bigger Size of Grants
WHO: Projects that have been on Arbitrum for an extended period, surpass a certain TVL.
They can submit a customized grant request, but it should be backed by thorough calculations and supported by reports from previous grants.
Category 2: Smaller Size of Grants
WHO: Projects that are newly launched, have not yet launched on Arbitrum, fall below a certain TVL.
These participants are required to choose from a predefined range of grants and must provide clear explanations on how they intend to utilize the grants.
The DAO will then determine the amount of grant they should receive, or decide to reject the application.
In this manner, we can hold established protocols to a higher standard, thereby setting a precedent for newcomers. As the saying from Uncle Ben goes, “With great power comes great responsibility.” This approach ensures that even smaller projects have a clear reference point regarding what’s best for Arbitrum and where the DAO’s priorities lie. Ultimately, this facilitates the onboarding of newer projects that enhance the Arbitrum ecosystem.