JoJo
May 25, 2024, 4:27pm
2
May 2024 voting
Snapshot votings
Vote: For
Voting “for” on this on snapshot.
I wasn’t in Denver, I plan to be in Brussel, and I have only heard good thing about govHack.
Team here has the challenge of putting up the org of a big event in less than 2 and a half month: realistically, they will need funds asap to start paying vendors and suppliers.
Voting for, and hope that a couple of days after snapshot is over goes directly to tally, for the sake of proper execution.
Several people were also able to testify about budget being rightly sized for this type of event, which was my main concern (and the main concern of others).
Vote: For
Voting a strong “for” on this proposal.
curve = really important part of DeFi
proposal = fair for the DAO thanks to the personal commitment of the founder, regardless of the outcome
incentives on top of a service, crvusd, that is highly appreciated and has demonstrated PMF.
Also, if this passes, it would be basically one of a kind: an incentive proposal outside of any framework program. Which is something that we need to collectively do as a dao.
Vote: Abstain
Since I was one of the advisor involved in the LTIPP program, I decided to abstain to maintain neutrality on all protocols who resubmitted after the council’s feedback.*
Vote: For
Voting “for” on onboarding DeDaub as security consultant
price is reasonable
there is the need of a technical consultant that knows both the topic and is engaged in the market, so understand rates and other relevant issues
appreciate that ADPC has money in their pocket but is still asking the DAO to use it.
On people asking “can we get other SME / alternative”. I totally understand where this comes from, and I undertand is the first thought one could have. But I think we should detach a bit from this type of thinking that, at this point, is a bit encapsulated.
If we elect a committee, and we assigne a budget, we should trust that committee. Micromanaging the committee instead is only detrimental, drags the discussion toward how to do stuff instead of effective doing stuff, kills the purpose of having a committee in the first place cause if they have to ask to the dao for everything at that point why were they even elected?
Vote: For
As we said and spoke about for almost 2 months now the whole program is complex in term of solving specific legal questions and unlocking new possibilities, unexplored for this dao, that will require a certain capital.
At this point, the pilot program can likely be what the DAO needs to understand how it would work in practice, without having too much of an hard commitment in the short term for funds and also workload. Excited to see where this initiative will be going
Vote: Abstain
As for the LTIPP, since I was one of the advisor involved in the STIP Brdige program, I decided to abstain to maintain neutrality on all protocols who went to vote either because they were challenged or because they posted a late application.*
Vote: For
After some thoughts, decided to vote “for”, including the reporting implementation.
I want to clarify a few things here.
inclusion of monthly report: it is a bit costly to be honest. But it makes a lot of sense to have data reporting on the txs executed, is the only way to really keep track of what the dao is doing
performances of signers: this should likely be included in the above report. With no judgment, just as data. Knowing how many tx were created and signed by each signer. It will be clear, over time, if there are outliers that never take part to the program or not, and at least the dao will be able in a future election to know who should not be re elected
i agree with users above stating that 12 months is not the standard time for these roles in the dao. To me tho, is not a detail significant enough to vote it down or even to change the proposal: a multisig should be something quite mechanic, quite reliable, quite boring. It can make sense to effectively have a 1y mandate on this (and potentially also on other boring, mechanic, reliable roles that we will need in future).
But, this is not necessarily an endorsement on a tally vote.
Initially i thought it would be hell cause signers would need to be able to create txs for all programs. And while this seems trivial for people outside of multisig world, is definitely not (ie: txs for a group of people, but excluding one that didn’t kyc yet; tx that is partially paid in fixed amount of arb, and variable amount of arb cause payment is in usd equivalent at the time of the tx itself; same as before, but with the usd value that has to be on a 30day moving average; etc).
Then, luckily, @dk3 educated me on the delegation feature that will allow external people to post a transactions in the safe for signers to sign. But I also understand there could effectively be issues, especially because not all programs are equal (ie: the delegate incentive program is one if the highest lift in term of number of transactions, variability of payout, problems with kyc and timing).
Regardless of the chosen solution, we need to address the above cases with a plan that will have to be integrated in every program using the MSS, in a way that scales and either allows one of the program main stakeholder to post transactions, or provide a way for a chair/signer to more actively participate to the single program. Which means, necessarily, a bigger overhead in time and costs. The latter solution also means finding a consensus mechanism between participants (=signers for that program) to choose the designated one . Either randomly, by internal election, they all fight in a room, but there is going to be one member who will effectively be paid more and also have more responsibility and will need to invest more time talking with someone from the program. If it’s the chair I am not sure. But in general, my suggestion for programs in which there is the need of scalability without effectively knowing the final size of labour needed (ltipp anyone?), should be to think about both a fixed comp, and the one proposed above is to me good enough, but also a potentially variable one tied to the number of programs one should interface with. Would dare to say, potentially even further specialise this component between programs with low amount and variance of transactions and high amount of txs or heterogeneous ones.
Hope the suggestion helps.
Vote: For
Vote: For
I am voting For on this proposal.
I am intrigued by the shared mechanism of two protocols, and I personally love incentive mechanism aimed to acquire/retain users in other chains. The quest for kwenta users in other chains is good (and i suggest the team to put a cutoff to wallets right before this mechanism was published). For the fee rebate, would suggest, if it was not done yet, to align to other perp protocol to have a 75% rebate and not an 80%. Seems like there is a general consensus on this number for this asset class; the leftover 5% of the 36% (so, 1.8% of the total or 34200 arb) can likely be allocated to quests or LP, or potentially be used as wildcard for other initiatives still allocated to users.
There is overall a net benefit for Kwenta to be here, and the fact that the proposal is outside the framework of stip, ltipp and others should not stop us from moving forward good initiatives, in the same way it happened with curve a couple of weeks ago.
Tally votings
Vote: For
Confirming snapshot vote, which I report here for completeness
I am voting yes for this proposal.
I wrote the reasoning publicly on twitter 10 days ago. This is what I firmly believe right now.
(from here)
I also understand the questions of some who are saying: why we should double down on stip if we can’t measure it yet. Why don’t we wait for the ltip to iterate on that. Etcetera. I get it. These are all valid concerns.
But, to me, the above is valid: we can’t stop right now. And also, if we REALLY want to know what success looks like, we would need to all sit down at a table, for a few days, and just discuss what we want to achieve in arbitrum in the next 6 months, 2 years, 5 years. Which is something realistically not doable in a DAO and that is usually what a board + a ceo do in the corporate world. What I mean is that while there is a merit in knowing what metric grew and what didn’t, metrics are just that: metrics. They don’t define necessarily on a 1:1 relationship success.
Lastly, i think that crypto AND the ethereum world AND the L2 world are in a specific phase (at least for another few years): growth. Which means, it could make sense to target generic metrics (users, tvl, volume) as proxy of a pathway to greatness, which is what we should generically pursue regardless of specifics.
NOTE: i obviously have also a biased interest here in voting yes, since i work for Jones DAO. For what it matters I would have voted yes even if i was working in a mc donald tho.
Vote: For
Confirming snapshot vote
Vote: For
Confirming snapshot vote
*note: in future I might reserve the right to vote in a non neutral way, opposite of what I did in STIP Bridge and LTIPP, in programs in which I am directly involved. This because, after what has so far been happening with situations like the one of Synapse , we just can’t be sure that others will speak when there is, indeed, the necessity to.