November 2024 voting
Snapshot votings
Adopt a Delegate Code of Conduct & Formalize Operations
Vote: For
[Non-Constitutional] Treasury Management v1.2
Vote: For
Restitution For Extensively Delayed ArbitrumDAO Minigrant Winners
Vote: Against
Never chimed in the discussion so far, but let me reiterate what others already posted: in a grant program that is denominated in non stable currencies, the change of value in payment is expected.
Is quite unfortunate that this resulted in delay and a blocker for most projects; but this doesn’t necessarily entile the project to further compensantion because nobody would be here if arb would have gone from 2$ to 4$. And this is something i can say first hand because not only i have been in several grant programs, i also have been in programs with payments denominated in arb, in which grantee never complained when price was going up, but had some reservation when it was going down.
This to be clear is not to flip responsability on you. I simpathize with your situation, and having served a lot of small team with grants I know how important these milestones can be just for the survivability of a team, or to effectively ship the product. There was a problem in the program, a lot of delays, that had bad consequences on the operation of project. This will mean that the dao, next time, either won’t vote for the same people to run the program, or for the program itself.
But it doesn’t necessarily mean that the dao should compensate people who requested the grant and saw the dollar value going down. We could, at scale, apply this to the LTIPP program, in which 60M of arbs got distributed, with proposal coming in when arb was way above 1$, and projects receiving the stream for users up to the point in which it was worth 0.4$. While different (we are talking about opex in your case, incentive to users in this case), should there be an argument for it as well? The answer is obviously no.
Consistently with this, I have voted against this proposal.
I really sympathise with both the proposer and the team affected, I really do, and I can understand the frustration. But the grant program has always been denominated in arb.
To give an example, in LTIPP, proposers created specific kpi on economic value based on arb at the time of their proposal (around 1.7$). They effectively received arb at a value that was below 0.8$ or less, and we are talking about 30, 40M arbs. This extreme example is to show that for non denominated arb grants there will always be this problem; it’s unfortunately more prominent in grants that are for smaller team, because it can really make the difference for the survivability of a project.
But again the dao can’t take the burden of how volatile the asset is; the dao can for sure take in consideration how there was a big problem with the service provider involved, and try to find ways to correct this behaviour in future.
It’s really quite unfortunate, I don’t think it would be fair to set this precedent.
Hackathon Continuation Program
Vote: In favour, yes onchain mechanism
Voting in favor, with the option of onchain.
First, the structure is quite interesting. I have chatted privately with Daniel on this proposal, the mentorship part is something that inheretly comes in grant programs for some teams (young founders, founders with extremely good ideas but no experience, founders that got rejected but that have a bright future) but this happens on a spot basis, and is tied to the skill and will of the comimttee/person who evaluate it. And definitely we would need more, so is interesting to see a program structured to incorporate it.
I added the yes to the onchain vote cause i personally evaluated collaberry for a grant in questbook season 2, and I am looking forward to see them showing off their tool in the “real life”.
Tally votings
(V2) Arbitrum Research & Development Collective
Vote: For
Confirming snapshot vote
Establishing a DAO Events Budget for 2025
Vote: For
Confirming snapshot vote