Hi all, chiming in here as an AGD reviewer.
First off, I have a tremendous amount of respect for @eboado and @MarcZeller. From my perspective, they form the DAO’s strong backbone, and I agree with quite a few of their points (e.g. grant sizing should be smaller and focus on grants vs. events).
However, I did notice one inconsistency that I’d like to discuss as I think it is an important example.
- Funding research of Safety Module slashing, while actually, an engaged team like Llama was doing (publishing multiple blog posts here about it!).
Context
I played a part in approving @XenophonLabs’s grant to research the Safety Module, which as a first stage resulted in this discussion.
Before funding the grant, since I was aware of @Llamaxyz 's work stream on the Safety Module, I reached out to the various DAO contributors that might have an opinion and tried to get their understanding of the workflow as I wanted to prevent funding work that was already being done. As part of that, I specifically reached out to @eboado and @MarcZeller as I know they are active contributors who might have more context than myself. @eboado had reasonable reservations given the potential overlap, and I didn’t hear from @MarcZeller on first outreach.
After some work to clarify how this work stream would differ from Llama where the @XenophonLabs team met with @HelloShreyas (lead’s @Llamaxyz), the team landed on these specific differences with Llama’s work stream and they came out of the conversation planning to collaborate with the Llama team on pushing towards an outcome:
So there are (at least) two parts: slashing percentage and pool composition. The simpler, less controversial of those is the slashing percentage. We want to do research to quantify, in dollar-terms, the sensitivity of the module to changes in slashing percentage, as well as demonstrate the optimal slashing percentage. Our preliminary work showed that this alone can lead to millions in savings, and our understanding is that this is not being performed from within Llama’s current research scope
With the additional clarification, I discussed further with @eboado and confirmed that he felt comfortable with AGD funding the additional research on a topic. After @XenophonLabs finished their initial research, I then followed up with @MarcZeller to see if he’d like to learn more and chat with the team. He then decided this was not his area to have a unique input on and asked that I direct Xenophon Lab’s questions to @MatthewGraham, who was working on this for @Llamaxyz at the time. Per the feedback, I connected the Xenophon team with Matthew so they could collaborate moving forward.
Fast forward a few weeks, and it becomes clear that @TokenLogic contributors @MatthewGraham and @Dydymoon, who were working on the Staking Module upgrade for @Llamaxyz, are moving forward under a different flag. This complicates things because based on initial discussions that the @XenophonLabs team had with @HelloShreyas, they agreed on a collaborative path forward, whereas discussions with Matthew and Dydy were a bit more argumentative. This is likely worsened by the fact that getting funding from the Aave DAO has become competitive, and @TokenLogic is now pursuing funding from the Aave DAO and listing their work on “Safety Module Improvements” under their current and future work streams. So I’m assuming they feel somewhat territorial regarding the Safety Module.
Conclusion
I attempted to communicate clearly with all engaged members of the DAO and get their thoughts before ever approving a grant for any research on the Safety Module. I hope the outline of events above makes it evident how difficult navigating DAO contributors and politics can be, expecting no overlap or perfect efficiency in contributions is too idealistic. Furthermore, in my opinion, no one entity should have an unchallenged monopoly on a work stream.
TL;DR
While I agree that duplicate efforts (e.g. building the same tool twice) should not be funded, I think that funding competing ideas is important and should be encouraged such that the Aave protocol doesn’t settle for suboptimal or noncompetitive services.