Add GMC Administrator To The Multisignature Wallet

Governance
1

Since the introduction of the GMC Administrator role, my removal from the multisig occurred due to my non-membership status in the GMC. This alteration disrupted the operational flow. Currently, the burden of creating and executing transactions falls on individual members, leading to inconsistencies and delays, with members like Joe frequently stepping up to execute.

If added, the admin can pay the gas fees to execute the transaction and then the GMC only has one person to reimburse. Members, who already dedicate considerable personal time to volunteer for GMC, must additionally pay around $10 each time they execute a transaction. Numerous requests from GMC members highlight the need to integrate the admin into the multisig.

I prepare the JSON file 2-3 days before payments, aiming for transactions to be executed by the 15th of each month. However, delays occur due to the verification process, wherein another GMC member must cross-verify data before creating the transaction after the admin has already done so.

To streamline our procedures, several enhancements have already been implemented

  • JSON Creation: The admin prepares the JSON, simplifying the uploading process for creators.
  • RPIP-29 Ledger: The admin maintains a comprehensive ledger of all awards, aiding in efficient data verification.
  • How To Upload Guide: A guide has been created detailing the process for members to upload JSON and create transactions.
  • Verification Guide: A document guides members on cross-referencing and verifying data using multiple sources.
  • GMC Server Payment-Addresses Thread: A dedicated thread allows awardees to post their addresses, aiding signers in verification.
  • Appointed TX Creators: Two designated transaction creators are assigned to take actions within specific timeframes.

Despite these enhancements, the absence of the admin in the multisig hampers our ability to meet the 15th deadline consistently, resulting in operational inefficiencies, and more time and labor spent on the payment process than necessary.

Benefits of Adding the Admin to the Multisig

  • Timely Operations: Inclusion of the admin ensures timely creation and execution of transactions, meeting deadlines efficiently.
  • Optimized Accounting: Empowering the admin to pay gas fees optimizes accounting processes, ensuring smoother financial transactions for GMC and only one individual to reimburse for gas fees.

By integrating the GMC Administrator into the multisig, we can enhance operational efficiency, minimize delays, and ensure a seamless experience for all GMC members involved in transaction execution.

Edit: This assumes transactions would go from requiring 6/9 to 7/10 signers.

Should We Add The GMC Administrator To The Multisignature Wallet?

  • Yes
  • No
0 voters
2

This is a very strong YES from me. This will streamline the GMC much more.

1 Like
3

I’m strongly against adding the GMC Administrator to the multisig. As an unelected position, the Administrator should not be able to spend the pDAOs funds.

If added, the admin can pay the gas fees to execute the transaction and then the GMC only has one person to reimburse.

Gas fees are currently not reimbursed. While I’m planning to submit a retro for this after the GMC election, this is not an argument for adding the Admin to the multisig: Anyone can execute safe transactions that reached the signing threshold, you don’t need to be a member of the multisig.

delays occur due to the verification process, wherein another GMC member must cross-verify data before creating the transaction after the admin has already done so.

I don’t consider cross-verification a bug here, but a feature: Every GMC member is supposed to verify the transaction before signing it, so it shouldn’t add any delays if GMC members are properly doing their due diligence.

To streamline our procedures, several enhancements have already been implemented

Before there was an administrator, we had an internal thread to coordinate each transaction before submitting it on-chain. I still feel like discontinuing this practice is the main culprit of delays: The thread enabled us to clear up issues before it was time to sign the transaction. Now, any change causes further delays.
The thread also spread the verification workload over many days, instead of asking GMC members to verify 20+ transaction outputs all at once.

Other changes like “Appointed TX Creators” also seemed to be counter-productive.
One improvement you mention, “GMC Server Payment-Addresses Thread” has been implemented after the last transaction.

TL;DR:
Considering there are many improvements still to be made, I think it’s too early to give up and ask for the Administrator on the multisig. I’m happy to revisit this 3 months after all suggested improvements have been implemented.

4

Let me start off by saying this is not my request, although I do think it will have a tremendous positive impact on efficiency. Back in June, five (5) committee members requested the GMC Administrator be added to the multisig and there were no objections from any committee members.

Gas fees are currently not reimbursed. While I’m planning to submit a retro for this after the GMC election, this is not an argument for adding the Admin to the multisig: Anyone can execute safe transactions that reached the signing threshold, you don’t need to be a member of the multisig.

Yes, gas fees have not been reimbursed. If one person is assigned the responsibility for gas fees moving forward, it will be straightforward to reimburse everyone up to that point and establish a defined system for future transactions. I was not aware anyone could execute, I’ll attempt to execute the transaction myself next period.

Before there was an administrator, we had an internal thread to coordinate each transaction before submitting it on-chain. I still feel like discontinuing this practice is the main culprit of delays: The thread enabled us to clear up issues before it was time to sign the transaction. Now, any change causes further delays.
The thread also spread the verification workload over many days, instead of asking GMC members to verify 20+ transaction outputs all at once.

The initial approach taken by the GMC in handling payments during the first cycle does not provide a clear indication of what will be efficient in future process. The payment list is constantly evolving, with multiple grants and bounties being added throughout the month. I don’t believe it’s efficient to require GMC members to stay continuously updated, rather than having a consolidated and concise list of all transactions.

One of the needs for changes in the transaction process arose when I sought your verification for a transaction twice within a 48-hour period. Due to a lack of response, I proceeded with the transaction without your confirmation, which later prompted your concerns about the transaction.

To address the ‘main culprit of delays’, it’s important to note that you were the original creator of these transactions. After assuming the admin role, my attempts to communicate with you regarding payments often went unanswered, necessitating the implementation of a more efficient and transparent system, as seen in the ‘GMC Execute’ thread.

Considering there are many improvements still to be made, I think it’s too early to give up and ask for the Administrator on the multisig.

I have compiled this request based on feedback by other committee members. None of which have requested to revert to a system of doing it in private threads where items are periodically added over the course of the month.

Considering there are many improvements still to be made, I think it’s too early to give up and ask for the Administrator on the multisig. I’m happy to revisit this 3 months after all suggested improvements have been implemented.

What improvements are you suggesting?

In recent payment cycles, there has been an additional wait time of 1 to 48 hours as we await a GMC member to create the transaction. If the PDAO and the GMC do not recognize the time spent coordinating transaction creation or the resulting payment delays as inefficiencies, then by all means vote ‘No’.

5

Back in June, five (5) committee members requested the GMC Administrator be added to the multisig and there were no objections from any committee members.

Which was then scrapped because we discovered the delegate functionality, deeming it unnecessary. I personally spent many hours figuring out how to add you as delegate, only for you to never use it, or ask me about it again, until today.

If the PDAO and the GMC do not recognize the time spent coordinating transaction creation or the resulting payment delays as inefficiencies, then by all means vote ‘No’.

Again, all the things you’re trying to accomplish by adding you to the multisig can be done without it, today. Everything you’re looking for can be done by you as a delegate, you just need to use the power given to you over 3 months ago.

I also find it very unprofessional of you to personally attack and blame me for… not doing your job ? I considered responding to all the false claims you made, but decided against this pointless exercise.

6

Which was then scrapped because we discovered the delegate functionality, deeming it unnecessary. I personally spent many hours figuring out how to add you as delegate, only for you to never use it, or ask me about it again, until today.

For the record, I did try and use it, and I posted in the GMC channels that it did not work during that time period.

I also find it very unprofessional of you to personally attack and blame me for… not doing your job ?

Is the assumption that I spend hours creating the JSON and then not clicking the ‘Create Transaction’ button because I would rather have to constantly poke other GMC members to click the button for me every month?

Update: It sounds like we don’t need to vote on this, object has stated in Discord he will share with the GMC how to create the transaction using the delegate function.

7

Update: After further research on using the delegate functionality I am reopening discussion on this.

I spent a couple hours reviewing the documentation I found here; However, I’m afraid that introducing such technical intricacies to the overall payment coordination might further diminish efficiency.

This pushes my technical abilities more than I’m comfortable with. The technical requirements would also unnecessarily limit the pool of GMC Administrator applicants in the future.

I believe the GMC Administrator should be added to the multisignature wallet and the signatures required should be increased by one to compensate.

3 Likes
8

Yes, I support shfryn on this.

9

Hard to see much of a downside. We’re expanding the necessary signatures so if anything it makes it harder for someone to misappropriate funds. And if we for some reason think the GMC Administrator is less trustworthy than the average GMC member then we’ve probably made a bigger mistake somewhere earlier on.

10

What does that mean? You said in your previous post that

Did this not happen? Or why is there such a back-and-forth here with “just use delegate”, “delegate can’t be used”, “it can”,…?

11

object’s research 5 days ago was when I first learned the ‘delegate’ feature could in fact be used. My previous attempts at testing it were within the standard GUI, and there is a layer outside of that where it needs to be used. But based on the new technical layer it adds, I would recommend a more streamlined option.

The current requirements for the admin position are: meeting coordinator / scheduler, awards facilitator, spokesperson, grants and bounties liaison, treasurer, and governance author. I would not recommend adding an advanced technical requirement for the future of the position’s applicant pool.

12

This is a tough one. I agree with objectObject. and also with ShfRyn. But maybe the most compelling part is the governance one - unelected position should not be spending funds. I would be interested in making the technical hurdles of delegation easier somehow.

13

After reviewing the docs to propose a Safe tx as a non-owner, I understand ShfRyn’s frustration. It looks like an overly complicated process for such a minor task. However, this feels more like a tech gap, not a reason to give more priveleges than necessary.

IMO either open a grant to put together an interface for proposing a non-owner tx, or open a proposal to make the GMC Admin an elected position.

2 Likes
14

Alternative: use a second Safe for dispensing, call it the “outbox”. Add the admin to it and make it 2 of N signatures. Each cycle the full GMC only needs to execute a single transfer of the total for that cycle to the “outbox”. And then the Admin can prepare and propose the more granular sends without exposure to the larger treasury Safe.

15

This looks like a really good compromise. The Admin could even (I think?) propose the transaction in the outbox before the transfer from the main is done, effectively locking in that nonce. It does add one extra transaction to the mix though.

16

Hmmm… I think that’s much worse than adding them to the wallet and increasing threshold by one. Periods are routinely >> $100k. I see no reason to protect that with only 2 signatures. (the transaction using a specific Nonce can be replaced until execution)

The only downside to adding the admin alongside a threshold increase is that it’s more possible (by one) to get a stuck transaction if the admin is inactive.

17

The threshold on the outbox does not need to be only 2. I agree that is probably too low. It could be somewhat higher (3-4) or even require the same number of GMC members as the main safe.

18

I agree with Val, that we’re overcomplicating matters here. Going back to what Cal said, if the Admin can’t be trusted to be on the safe, something went wrong earlier.

19

I briefly followed up on a github issue to integrate delegates into the UI and got a positive response (https://github.com/safe-global/safe-wallet-web/issues/1825).
I believe this would allow for all the functionality the GMC admin is looking for witout any extra requirements and without needing a pDAO vote.

7 Likes