After consideration, the @SEEDgov delegation has decided to “ABSTAIN” on this proposal at the Snapshot Vote.
Rationale
After analyzing the proposal, we believe it is well-articulated and addresses a real issue: winners of hackathons or top projects often lack the resources or time to continue development. We also appreciate that part of the budget will be co-funded with RnDAO.
That said, there are some aspects we disagree with or that require further clarification:
The on-chain functionality seems unnecessary for tracking a maximum of four grantees. Spending USD 30,000 on something that could be resolved with numerous free tools seems excessive.
We would like to see a more detailed breakdown of the budget allocated to Program Ops & Comms. Upon reviewing previous versions of this proposal, we noticed that there were more budgetary details in general. The proposer explained to us that this was removed because he received feedback indicating that it generated confusion rather than helped. From our point of view, it should be well-detailed what the money is going to be spent on, especially when there are people involved who will be compensated for their work.
We agree with other delegates that the administrative and marketing costs seem high relative to the total budget.
It would make more sense for the capital invested in the projects by both parties to be equitable, potentially adjusting the distribution across other items. This would give both entities shared ownership.
Despite the above points, we want to highlight that SEEDGov has decided to abstain because we were involved in the process of granting the Hackathon in question through the Questbook domain for Education, Community Growth, and Events.
The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas, and it’s based on the combined research, fact-checking, and ideation of the two.
We’re voting FOR the proposal while opting OUT of the on-chain mechanism.
The idea of doubling down on projects that were successful during the hackathon and helping them develop their project further, not just with funding but also with venture support from RnDAO, is intriguing. We believe it can serve as a good experiment of what a follow-up approach could look like for projects created in hackathons or through grants.
Furthermore, the fact that the amount we’ll distribute to those projects won’t be in the form of grants but will instead be in the form of investments is something that we find interesting as it might, in the long run, bring returns back to the DAO and is a good precedent for the future.
The one thing we’re skeptical about and want to raise as a point of discussion and consideration is the operational cost relative to the capital investments we’ll be making in the projects. As things stand, we’ll be allocating $124,000 to projects while spending $87,030 on the operational cost — a 1/0.7 ratio seems pretty high. However, at this point we don’t necessarily request RnDAO to lower it but we plan on discussing it with them before the onchain vote to have a better understanding of what is the cost breakdown and what can expect delivered in it.
For the on-chain component, we’re not sure there’s enough justification to support it, especially since the project has already received a grant from Arbitrum through the DDA programme. If the project and RnDAO are confident of the value it will bring to Arbitrum and the hackathon continuation programme, we would encourage them to find a way to demonstrate that value first (covering the costs internally if needed), and then come back for a follow-up grant.
I agree with the sentiment that it’s far from an ideal ratio (as @SEEDGov and others have noted). However, it’s an issue of economices of scale and at this stage we’re unable to lower the operational costs without affecting the viability of the program.
The alternative is to increase the size of the program i.e. fund more temas which would only marginally increase the Operational costs.
We’re thus proposing this as a pilot and hoping we can demonstrate its merit to then be scaled up as a recurring (and more cost effective) program.
Importantly, the ration should also include Venture Support as based on the venture studio model the thesis is that it’s more cost effective to have some experts work with the projects than letting each project try to hire everything in house. The Venture Support costs are thus part of what’s deployed into the projects. Making the ratio 3.5 / 1 Ops
As a nounance (we’ll clarify this before going onchain), the Comms costs are added within Ops but technically we can break these down with more sophisticated accounting into:
program reporting
amplifying projects through RnDAO channels and coordinating with Arbitrum Foundaton and others to amplify
coaching projects on comms/growth
So perhaps anoher 10-15k can be attributed to Venture Support.
Blockworks Advisory will be voting FOR this proposal and opting out of the onchain mechanism on Snapshot.
Investing in hackathon finalists and providing aid aligns with the DAO’s needs and responsibilities for its ecosystem. Candidly, Arbitrum DAO should explore more investment opportunities in its ecosystem, and so we are happy to see initiatives like this come about.
After consideration and internal discussion, Entropy decided to vote AGAINST. Please find our full rationale and the additional details we’d like to see included in this proposal before it moves to Tally on our delegate communication thread: Entropy Advisors Delegate Communication Thread - #10 by Entropy
We’ll provide the suggested details when scheduling the Tally proposal on Monday.
Unfortunately, the whole initiative would likely become unviable if we move slower as the end-of-year break would push the start of the support program to mid-February (January for tally vote and then 1-2 weeks to get started), making it 3 months after the end of the Hackathon and thus we wouldn’t be able to offer a pipeline for the Hackathon projects.
DAOplomats voted In favor, no onchain mechanism on Snapshot.
Establishing a framework for ongoing hackathons is great as it helps foster long-term support for successful projects. However, we supported no onchain mechanism because implementing one might overcomplicate program execution, introducing inefficiencies and delays in distributing funds or assessing outcomes.