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.