# RFC - Abracadabra DAO votes for week 17/02 - 21/02:

[RFC] Requests For Comment
1

RFC - Abracadabra DAO votes for week 17/02 - 21/02:

Summary:
This proposal asks AbracadabraDAO to engage in the ArbitrumDAO votes for this week. ArbitrumDAO has a weekly voting cycle, ending every Thurday. The votes for this week are:

In the following section, I will present a short summary, why should AbracadabraDAO vote in the topic, and a voting direction suggestion.

Motivation

I am a delegate on ArbitrumDAO and I understand how time-consuming governance processes can be, as they are not limited to forum posts, but also several calls where the proposals are discussed. Sometimes, this is overwhelming for protocols contributors/community, so the engagement is not that high. However, every week are discussed/voted topics that has a direct impact in the protocols that are part of Arbitrum Ecosystem. For this reason, I present this week’s votes for the community appreciation, as I believe it is important that AbracadabraDAO to be part of those decisions.

This is the onchain vote for Season 3 of this Grant Program. As a reminder, the AbracadabraDAO voted for Saurabh for one of the DA positions.

Voting direction suggestion:

FOR: The introduction of new protocols, supported by this grant program, can be beneficial to the whole ecosystem and for Abracadabra protocol as well, as they could use Abra, their tokens being part of cauldrons or the DAO could invest in them.

This proposal request $67.2k USD for a series of 7 bi-weekly events over three months, aimed at fostering a self-sustaining support system within the Arbitrum community. The events are designed to empower early-stage and high-growth protocols by providing a platform for knowledge sharing, networking, and peer-led support. The initiative seeks to enhance the Arbitrum ecosystem by promoting community-driven problem-solving and leadership.

Voting direction suggestion:

AGAINST: Despite the idea being relevant, there are 3 things that make difficult to vote FOR in this proposal in the current form:

  • ETH Denver starts only 3 days after the end of the snapshot vote and the proposal would likely need to go through an on-chain vote too (so the timing is not good).
  • The budget itself could be lowered, and the DAO could leverage the Arbitrum D.A.O. (Domain Allocator Offerings) Grant Program and have a proper overview of the milestones, ensuring the execution of the items proposed.
  • There is no clarity on whom the experts leading the panel will be, and if their support is secured at this point. As the event relies on them heavily, it makes little sense to approve the event without knowing who they will be.

Arbitrum Voting

Arbitrum Votes for those 2 topics will end February 20th.

If the proposal were to pass, Abracadabra would be voting following the voting direction suggestions proposed here.

2

As it looks like there are typically multiple votes per week, we may need to figure out some way for the DAO to have a blanket authorization to vote so we do not have multiple snapshot votes per week. This would be an unsustainable level of governance. It is however important to us to maintain some degree of autonomy that a pure delegation model may not provide.

Perhaps something like we follow guidance of x delegate unless there’s some kind of veto. Do you have any thoughts about a model like this?

3

Hey @BrabDdy, I agree with your assessment, as I believe we have 2 bottlenecks in the current governance cycle:

  • Snapshot voting for each proposal: with some Arbitrum proposals having only a 1-week cycle, it is hard to make it fit in our current model.
  • Vote execution on our multisig: We will have a short window to cast the actual vote, making the execution of AbracadabraDAO snapshot vote something difficult.

I have a suggestion for both items, to reduce the workload on the DAO governance infrastructure.

  • Optimistic approval - The RFC would remain the same, sharing the Voting direction and why it makes sense for AbracabadraDAO to vote that way - The change here is that there is no need to have a snapshot vote to confirm this choice, and it would be the vote cast unless there is a “veto” or no agreement is achieved in the thread conversation until Wednesday 11:59PM UTC. In that case, an “ABSTAIN” vote will be cast.

  • Execution delegation - Instead of having the multisig to cast the vote, the VP would be delegated to my address, so the execution is way simpler, and we ensure we don’t miss the deadline. This is different from a pure delegation model, as the voting direction will be ratified/changed by the holders using the forum, and only the execution of the vote is delegated.

Let me know your thoughts on this. :+1:

4

Tagging @Romy and @p4lm3r4 for visibility :pray: