MSS for Arbitrum - Communication Thread (Arbitrum Multisig Support Service)

This is the official communication thread for the Arbitrum Multisig Support Service (MSS).

The proposal passed Tally on Sunday, August 18th, 2024. See the Tally proposal.

5 Likes

MSS Update 23/09

Multisigs deployed:

MSS payroll - Funded by the DAO when the MSS proposal passed, so far the only payments made by this multisig are the August and September payments for r3gen

Delegate Incentives Program - Funds will be migrated from the program’s multisig to the MSS multisig to pay the 2 month extension as requested by the program managers as stated here.

Event Horizon - This multisig has already been funded and will proceed as indicated here.

ADPC Payroll - Still waiting for the ADPC Phase II proposal, funds will be deposited to the MSS multisig and these will then be converted to USDC through Aera.

4 Likes

A new MSS multisig was deployed for Stylus Sprint: Safe{Wallet} – Dashboard

The multisig will be funded if the Stylus Sprint passes onchain vote.

2 Likes

An MSS multisig was deployed for the Arbitrum Off-site: 0x0F84fa246941883Ff9ab114382Aa221CF8b6d650

The multisig will be funded if the Arbitrum Off-site proposal passes onchain vote.

The DIP MSS multisig signing threshold has been increased from 6/12 to 8/12 to account for the additional funds that will be deposited for the new delegate incentive program: Tally | Arbitrum | [Non-Constitutional] Arbitrum DAO Delegate Incentive Program

1 Like

is this thread up to date? have all created multisigs been reported here? if not here, where can we see all of the multisigs created and managed by the MSS?

MSS Update 1/31/2025

A full list of deployed Arbitrum MSS Multisigs can be found here: Arbitrum MSS Addresses - Google Sheets

New Multisigs deployed:

ADPC Subsidies - Funded by the DAO when the ADPC II proposal passed

ARDC v2 - Funded by the DAO when the ARDC v2 proposal passed

DAO Events Budget - Funded by the DAO when the DAO Events Budget proposal passed

1 Like

I would like to suggest an V2 for the MSS as the current structure is not promoting an ownership mentality and losing the DAO money.

Background:
The ARDC V2 received its allocated funds after the Tally proposal passed (approx 90 days ago) - see Multi-sig wallet here. Despite as stated in the ARDC V2 proposal that passed on Tally that “Upon receiving the ARB, we will convert 1.73M USDC worth of ARB” no ARB was converted until ~ 20 days ago.

I do not want to point any fingers and am aware it was a holiday period but I want to point out that the current structure doesn’t incentivize proactiveness. The program was set up with a 20% buffer to allow for volatility (calculation here) but now as a result of the delays the ARDC team is currently sweating, praying to market gods that the allocated ARB will cover the full budget (the majority has been converted to USDC see Aera Vault, we have 1.01M ARB remaining of which 180k are set aside for the Supervisory Council and the rest is being converted over the next days to reach a total of 1.73M USDC needed. I am aware that ARB is highly volatile and had we not had enough funds because right after the Tally vote the price dumped, I would have understood. But this is not what happened (see attached screenshot)

So how could we prevent this from happening in the future?

Tying MSS comp to performance

Chairs and “simple signers” to be rewarded with 50% base and 50% bonus (bonus to be paid every 6 months) if programs have been supported successfully.

What is success

  • responsiveness in telegram chat and for signatures (<24h during weekdays, <48 hours on weekends/holidays unless heads up is given ahead of time; head up = out for x days from date to date)
  • proactiveness for chairs: as soon as funds are allocated they need to be converted within X days; in case this is being delayed the chair needs to give valid reasons why this was the case

What needs to be solved to make this work:

  • who gives feedback (program managers of the respective programs? An “independent” party like @immutablelawyer?)
  • does each chair/owner get feedback per program and does one unsuccessful execution cancel out the entire bonus?

This is just a thought starter, not by all means a complete solution. Looking forward to hearing other suggestions I know we can do better than the status quo.

12 Likes

The following reflects the views of L2BEAT’s governance team, composed of @krst and @Sinkas. It’s based on their combined research, fact-checking, and ideation.

Thanks, @tamara, for starting the conversation and for the proposed solution. On occasion of your comment, we looked into MSS’s operations so far and there are several things that can be improved going forward. While we’ve messaged the MSS team directly regarding those things, we also wanted to bring them up and draw attention to them.

Most importantly, in our opinion the MSS Chairs are the ones who should ensure that the procedures set forward by the MSS proposal are followed, and they should claim responsibility for doing so. There should be a solely responsible chair per SAFE deployed that is clearly communicated to the lead of the associated initiative. The chair should be responsible not just for ensuring the transactions are executed promptly, either by coordinating with the initiative’s lead or by chasing signers if needed, but they should also be responsible for communicating any issues to the DAO as they arise.

Lastly, if any of the processes outlined in the original MSS proposal isn’t practical and, therefore, isn’t being followed, then it should be changed. The change should be clearly communicated in the MSS communication thread and chairs should make sure it’s being followed by signers and initiative leads alike.

We are looking forward to adjustments to the operational procedures on the MSS side and we expect more communication in this MSS communication thread going forward. We will also be more diligent in checking the status of the cooperation between MSS and initiatives during the monthly GRC calls.

1 Like

As an MSS Chair, I’d like to propose some changes to the structure of the MSS that I believe will allow the program to operate more effectively going forward. This post was written in collaboration with the other members of the MSS. If the DAO is supportive of these changes, the next step would be to ratify them via Snapshot vote.

Increase Chair Responsibilities
The MSS proposal specifies only two responsibilities for chairs: creating new multi-sigs on a rotating basis and removing signers from the program. My observation has been that the MSS requires more leadership than was envisioned when the proposal was created. To improve the quality of MSS execution, I recommend adding the following responsibilities explicitly to the role of MSS Chair:

  • Communicate all new multi-sig creations AND all new transactions on MSS multi-sigs on this thread.
  • Proactively analyze the payment needs of new proposals that pass and create an operational payment plan in conjunction with the proposal owner. Post the operational payment plan on this thread and communicate any updates on this thread.
  • Assign an MSS chair owner to each multi-sig, who is responsible for all of the above actions. Document the ownership here in this thread and communicate when ownership changes. Chairs who do not execute consistently on all of the above actions should be removed from the program.

Reduce Scope of COI
The MSS proposal includes in the definition of Conflict of Interest “Being directly compensated by the Multi-sig: Receiving payments, reimbursements, or any form of financial benefit directly from the multi-sig for which the signer is responsible (Exclusion for the MSS multi-sig itself which will be paying it’s signers directly for their services)”. This is impractical given the high likelihood of overlap between multi-sigs that rely on the MSS and members of the MSS, many of whom are active contributors to the DAO. For example, the Delegate Incentives Program multi-sig sends payments to many members of the MSS. Due to the high number of signers and the dependency on the multi-sig initiative owner to request payments, I believe it is possible to maintain the integrity of the MSS without removing all members who receive payments from a program. I also see some benefits to having MSS members involved in the multi-sig they are singing for, as they are likely to be deeply familiar with the operations of said initiative. I recommend removing this criteria from the definition of Conflict of Interest section of the MSS proposal.

Increase Coordination with Proposal Authors
The ARDC and ADPC MSS multi-sigs have required the use of multiple DeFi protocols, including Aera and Llamapay, to complete transactions. In cases such as this going forward, the proposal author should explicitly check in with the MSS to see if they are willing to use the proposed payment process, and to make sure the process is fully understood by the MSS.

7 Likes

Hello everyone! Thanks for fostering this discussion.

I would like to point a few things:

  • I believe we already passed half of the tenure for MSS. While this was not in the original proposal, shouldn’t we have a report or post highlighting what happened so far, the performance of the execution x the initial proposed “soft” KPIs?
  • Six months is around 6 years in crypto-life :sweat_smile:. Isn’t the time to promote the rotation/offboarding of signers that are not that active? It is easy to see that several addresses are not signing transactions. Having multisigs with higher threshold (like the DIP, for example) and not having the 12 signers active increases the friction in the process.
3 Likes

With the talk around quorum recently, we were looking through some of the multi-sigs and noticed that not all of them were delegating to the exclude address. We made a small sheet here, a couple match the addresses on the MSS sheet linked above, but there’s a few that aren’t on there. We understand that some of these might just be holding ARB before it’s swapped to stables but we think it could still be delegated in the meantime as it does start adding up. Currently there’s just over 90M ARB that should be delegated to the exclude address but isn’t. As part of the proposed changes, can we add doing regular audits of whether all the multi-sigs that exist are documented, and that they’re not increasing quorum?

1 Like

MSS Update

A full list of deployed Arbitrum MSS Multisigs can be found here: Arbitrum MSS Addresses - Google Sheets

New Multisig deployed:

Domain Allocator Offerings Opex - Funded by the DAO when the Arbitrum D.A.O. (Domain Allocator Offerings) Grant Program - Season 3 proposal passed

MSS Update

A full list of deployed Arbitrum MSS Multisigs can be found here: Arbitrum MSS Addresses - Google Sheets

New Multisig deployed:

Arbitrum Onboarding V2 - It will be funded by the DAO if and when the Arbitrum Onboarding v2 proposal passes on Tally

As part of efforts to improve MSS operations, we will regularly post a list of recent transactions made in each MSS multisig in this thread.

As a reminder, a full list of MSS multisigs can be found here.

Recent MSS Transactions

MSS + R3gen Payroll

Delegate Incentives

Event Horizon

  • No recent transactions

ADPC Payroll

ADPC Subsidies

Hackathon Continuation (Arbitrum Offsite)

  • No recent transactions

Stylus Sprint

ARDC v2

DAO Events Budget

Domain Allocator Offerings Opex

Arbitrum Onboarding v2

3 Likes

GREAT CATCH @Vertex_Protocol

@Frisson is a hero, and has set up the delegation txs.

3 Likes

The MSS created transactions to delegate ARB in the following MSS multisigs to the exclude address. This will apply to any ARB that is ever transferred to these accounts.

  • DAO Events Budget
  • ARDC v2
  • Stylus Sprint
  • Arbitrum Onboarding
  • Domain Allocator Offerings Opex
  • ADPC subsidies
  • ADPC Payroll

When these transactions execute, all MSS mulitisigs should be delegated to the exclude address.

Going forward, this will be part of the standard process of creating a new MSS multisig.

As a note, the STEP 2.0 and Treasury Management multisigs in your sheet are not managed by the MSS.

2 Likes

Thank you for the update! And sorry about the STEP and treasury management programs, should’ve double checked who was managing the multi-sigs for those.

Re-reading the proposals we’re seeing this for the Treasury Management V1.2 proposal

In order to reduce ambiguity around tax, legal, and any other possible liabilities, we suggest that the Arbitrum Foundation serves as the custodian/counterparty of the funds at all times. The TMC and the GMC simply help coordinate the process, the DAO still remains as the ultimate decision maker, and the Foundation serves as the custodian/counterparty of the funds and thus abides by Cayman Islands law. While the MSS is great for serving as the DAO’s solution to multi-sigs, it is clear that the Arbitrum Foundation is the most logical party to custody these funds, until the OpCo’s legal entity is stood up and fully operational, to avoid unforeseen legal liabilities.
If this vote passes onchain via Tally, 7,500 ETH and 26M ARB will be moved to this address, and then transferred to two separate foundation controlled addresses. No funds can be deployed by either the TMC or GMC—they are only tasked with providing options for the DAO to vote on, and the Arbitrum Foundation will be subject to act in accordance with how the DAO votes. The additional 1M ARB being transferred to the Foundation will be liquidated for 300k USDC in the most suitable manner to pay committee members, with the remainder immediately returned to the DAO treasury.

and this for STEP 2.0

We will transfer 35 million ARB to a foundation managed wallet (0x54FE3425f09854E15081fa5B3276afCB4C46FCa2). See confirmation here: Non-Constitutional: Stable Treasury Endowment Program 2.0 - #81 by stonecoldpat

Apologies if we’re not understanding properly or asking the right person but @stonecoldpat could the foundation also make sure to delegate to the exclude address please?

1 Like