RAF1: Governance Concerns in RAF1: A Delegate's Perspective

[stefa2k]

I was hesitating to vote in the Obol Retroactive Funding round 1 for a long time. Time was ultimately running out and therefore I made the implicit decision not to participate in voting. But why did I decide to just slip this chance to get funding for so many great projects?

For me the most important one is having the same project multiple times in a funding round. Eth-docker was not only 2 times in the list, but 3 times. I understand, the project and the modules of the project were done by different parties and open source projects are a common effort with many contributors. But what’s the limit here? Can every contributor put their PR in a funding round and expect compensation? This would lead in some scenarios to a disadvantage, but given the early numbers I’d argue it turned in this case to an advantage for eth-docker contributors. When is it okay or desired to put modules of an effort (regardless of the type, e. g. code, community, documentation, …) in a quadratic funding round? Again, what’s the limit here? I suggest putting a split contract with the contributors on the application and making one application instead of multiple. No doubt, eth-docker is a great project and needs funding.

The second issue I got with RAF1 is having only the first 100 delegates (or selected ones? Maybe I overread the criteria in some blog of Obol, my apologies on this) to vote. What makes them so special? All votes should be counted as such, that’s what the airdrop was for as outlined in Obol’s own blog post Announcing the OBOL Token and Decentralized Operator Ecosystem "Delegate your tokens, or become a delegate yourself, to participate in governance.”

Third one - why I’m not allowed to vote for projects I’m involved with? And how does Obol check all the delegates to vote correctly? It’s simply not enforceable. People in Ethereum (and crypto in general) are often associated with multiple projects, some of the collaborations not yet announced or just in the making - at what stage is it okay to vote?

The fourth reason is that some projects received funding before, while others didn’t. RAF1 creates the illusion of an even playing field for applicants without Obol having set one in the first place. Projects which already received funding naturally will have an advantage simply by being able to extend more on their contribution.

The fifth issue I got with RAF1 is the disclosure of funding. Huge shoutout to splits to disclose USD 10mm of funding! This was for me the main reason not to give them loads of votes from my side - if I’d have voted. I still feel some projects lack transparency knowing that well-funded projects don’t receive as many votes - for obvious reasons. But having this thought I also need to acknowledge there is a large gap between the efforts (hours/money/whatever) in some of the projects listed in RAF1 - I would suggest either not including funding as part of a project’s application for a RAF round or also including how much effort went into this project. Speaking for Stereum, we received substantial amounts of financial help to pay for developers, test servers, code signing certs, and so on. But it’s still operating each year at a massive loss for RockLogic and Stereum Services (both companies I’m the founder of).

All these reasons gave me a hard time finding it a good thing to vote in RAF1.

I value Obol’s effort in making staking more resilient, easier to squad stake, better pooling experience, above-than-average performance and so much more. Some of these issues brought up here affect a small amount of fund seeking projects, others affect a larger number. I tried to take these into consideration but couldn’t make any vote work for me.

My delegate data:
ENS: stefa2k.rocklogic.eth
Address: 0x49Df3CCa2670eB0D591146B16359fe336e476F29

[enti]

Thanks for raising these points, @stefa2k. I overall agree with your overall concerns and sentiment. In all fairness, I do believe the first iterations of a new grants program should be somewhat loose (and more when it’s in a new ecosystem!), but I agree rules could’ve been more clear/tighter on this first one.

I do want to follow up commenting on some of your points.

For the first point, 100%. Contributors to a project should coordinate amongst themselves, or simply be cool with making small contributions without being compensated. Anyways those who did 1-2 PRs would probably make so little I doubt it’s even worth it to put together an application.

For your second point, you do need some proxy for domain expertise, experience or commitment to the collective, and RAF is a lot of work already. Limiting RAF voting to the top 100 delegates is a simple and elegant proxy to do that—it’s not perfect obviously though; I guess we could have a conversation to see if there’s other way to select a “fair committee” to evaluate RAF.

On COIs, I feel like this is pretty much standard practice? You don’t use the power given to you by the Collective to benefit yourself, it’s conflictive a can of worms we shouldn’t open IMO.

Lastly, on funding reporting, I echo @ETHKipu’s application feedback:

@ETHKipu

— Confusing financial reporting section: The section on previous funding was unclear. None of the options fully applied to us since we’ve only received funding from the Ethereum Foundation, not from any governance system or protocol. It would help to have more flexibility or a more precise option for cases like ours.

Rules and categories for funding were a bit confusing. In general we should make our best to use RAF (and any other funding vehicle) to support projects in the ecosystem that do need it to maximize the growth of Obol. The Collective should not double-fund projects that already have a solid business model, or have raised a good amount of money.

This is indeed a very good way to open the conversation to improve RAF! Let’s not get demotivated with things we can iterate on collectively

[cp0x]

Interesting feedback, and I’d also like to share my thoughts on the points you’ve raised:

1. One submission per team: I fully agree with your opinion that teams should submit only one application if it’s truly a single project. Although Obol explicitly allows multiple submissions from one project, they specified that these submissions should not overlap. In the case of eth-docker, we analyzed and voted for just one project for exactly this reason.

2. Voting by the top 100 delegates: We also don’t understand why it’s not possible to allow everyone the opportunity to vote. There are no technical issues with this, and it’s important for individuals to express their own opinion if they have the time to dive into the projects and prefer not to delegate. I can assume that smaller delegates may lack the motivation to analyze all the projects and spend tens of hours on it, but this should not be a reason to limit their voting power.

3. Conflict of interest: Many DAO Delegate Rules of Engagement include a clause on conflicts of interest, specifically prohibiting voting for oneself if it brings direct financial benefits. However, everyone knows that there’s no perfect world where everyone follows the rules, and this rule can be easily bypassed by dishonest delegates: you delegate tokens to an unknown address, and that address votes for you. The scheme is simple, and it’s nearly impossible to prove collusion. I understand Obol’s motives, and we personally did not vote for ourselves. Still, we find these rules strange because the system should regulate itself: if voting abuse occurs, our voting power should decrease as delegates. This kind of system actually encourages people to bypass the rules.

4. Funding clause: Regarding points 4 and 5, we believe the “funding” clause should be optional. Transparency will attract people to the project, as long as the development aligns with the funding amount.