[RFC] Arbitrum Multi-sig Support Service (MSS)

Non-Constitutional

Authors: Entropy Advisors, r3gen Finance

Acknowledgement:

We would like to express our gratitude to r3gen finance for authoring the Token Flow Report and querying the data that led to the ideation and creation of this proposal. Additional thanks to @krst and @coinflip for their help along the way.

Abstract

We propose creating a structured multi-sig framework to facilitate funded programs within Arbitrum DAO to reduce operational spend and increase proposal efficiency.

As of April 2024, the DAO administers six programs with a designated budget for multi-sig signing. The aggregate budgeted cost across these programs for signers stands at 158,000 ARB, with an annualized total expenditure, based on estimations, of 470,000 ARB or $627,840 at an ARB price of $1.34. This is a high cost for the DAO to pay on a purely operational function, especially considering that these operational costs will likely rise as more programs are funded.

We propose creating a “Multi-sig Support Service” (MSS) to unlock significant cost-saving opportunities, lessen committee fragmentation, ensure signers are competent with multi-sigs, and reduce friction for contributors creating proposals. The MSS will comprise 12 elected individuals to all DAO-funded multi-sigs. They will be compensated a base USD amount, paid in ARB, for performing these services across the DAO.

This proposal also includes the optional steps to fund the implementation of r3gen monthly Token Flow reporting on inflows (revenue) and outflows (spend) across the DAO as well as providing detailed information and analysis on spending from MSS multisigs. Together, this proposal will help create a “backroom finance” function within the DAO that can be used across different initiatives.

The proposed changes offer the potential to generate substantial cost savings, estimated to be ~$315,000 per annum, while increasing efficiency, transparency, and security of DAO spending.

Motivation

The Arbitrum DAO oversees six programs which pay multi-sig signers. Each multi-sig typically has five signers, except for the STIP and STIP backfund programs, which share the same multi-sig and have nine signers budgeted for. The table below outlines these programs, including the amount funded, duration (in months), and annualized figures to project a forecasted amount if future programs were to continue in the same manner.

Here’s a breakdown of the programs:

Screen Shot 2024-05-09 at 9.46.01 AM1206×460 43.7 KB

The analysis underscores the operational unsustainability of the current expenditure level, with an annualised cost totalling $627,840 USD based on the average ARB price of $1.34 between August 7, 2023 and April 30, 2024, the period starting when Arbitrum DAO’s first multisig was funded.

The cost per transaction appears excessive when comparing these figures against the volume of unique transactions sent from each multi-sig. While analysis for all multi-sig wallets is included for completeness, the STIP/Backfund multi-sig provides the clearest picture of the “cost per transaction” due to its proximity to completion.

This analysis highlights the urgent need for restructuring and cost optimization within the Arbitrum DAO to ensure financial sustainability and operational efficiency in the long term.

UTS1206×396 30.7 KB

AS CpT1248×458 55.4 KB

736×419 47.9 KB

Currently, the DAO experiences a significant dispersion in its structure, where each funded program operates its own multi-sig. This fragmentation not only leads to redundancy but also elevates the overall cost of operations. Through the “Multi-sig Support Service” (MSS), we can eliminate these inefficiencies and significantly reduce unnecessary expenditure.

Additionally, individuals on multi-sigs are generally not elected, posing a challenge in consistently ensuring that only the most trusted and competent members manage these critical roles. By shifting to an elected model within the MSS, we can enhance transparency, accountability, and professionalism, ensuring that every signer meets a high standard of trust and competency.

Finally, contributors currently face friction in advancing proposals due to the need to wrangle signers, which can delay or deter the proposal process. The MSS aims to streamline this process by providing a reliable and consistent team of signers to be included in proposals, thereby reducing the time and effort of contributors, and accelerating the pace at which the DAO can execute its initiatives.

By creating a structured multisig committee, process, and reporting cadence around spending, the DAO will be better equipped to service its plethora of proposals that require payments and maintain transparency around the programs.

Proposed solution

The proposed framework for the Arbitrum DAO aims to address these issues by:

1. Arbitrum DAO elects 12 signers via Snapshot weighted voting, shielded with Shutter
   • Signers, when submitting their application to join the MSS, may opt in to be an MSS Chair, who will be responsible for communicating to the DAO on the MSS’s behalf. The three opted-in signers with the highest weight according to Snapshot will be allocated MSS Chairs.
2. For each new DAO initiative requiring a multisig, a new 12 signer multisig is set up.
   • The signing threshold will be dependent on the total dollar denominated value of the wallet
     i. 6/12: <$1M
     ii. 7/12: $1M-$5M
     iii. 8/12: $5M-$10m
     iiii. 9/12 $10M-$50M
3. Signers are paid a fixed monthly fee of $1500 in ARB using spot price at the time of payment. The MSS Chairs will be paid $2500 per month in ARB using the spot price.
   • We feel denominating the payment in a $ value is important to ensure the DAO pays a fair price for service rendered without the risk of ARB price movement leading to a series of overpayment or underpayment to signers for their duty.
4. This will be paid out monthly from the MSS multi-sig, which will be a 6/12 including the entirety of the MSS.
   • Payment for multisig signers will only start once the first new multisig is onboarded under the Multisig Support Service MSS structure.
   • Existing multi-sigs have the option to “opt in” to the MSS structure. If they do so any existing ring-fenced budget for multisig signing should be sent directly to a new MSS multisig. An MSS Chair will coordinate with the Program to manage the transition process. We expect a gradual turnover given the incentives at play and that most multi-sigs will not opt into the transition process.
5. The same process is repeated to onboard new MSS members 12 months after the first is complete (starting the process 4 months before the term is up to allow for ample time)

We suggest the program is capped at initiatives seeking funding of $50M or less. This will help ensure that the program is not bottlenecked by one single initiative. For programs seeking more than $50M in funding, we suggest inspiration in design be taken from this model while creating a dedicated multisig committee and process.

MSS Mechanics

Who would be a suitable multi-sig signer?

• Actively involved in the Arbitrum ecosystem
• Prior experience being on multi-sigs. Understanding of batched transactions and transaction builder.
  • All multi-sig signers will also undergo training on security best practices and multisig efficacy at the commencement of their role. This training will be completed by Entropy Advisors.
• Able to complete KYC
  • The Arbitrum Foundation will conduct KYC on all multisig signers to ensure they are compliant and can serve this role for the DAO.
• Organisation or professional signers can submit a nomination to be a multi-sig signer. Only one member per organisation.
  • If nominating an organisation, one member of the company should be listed as the primary point of contact.

Creating new MSS multisigs

The process flow for creating new multisigs is as follows

• Snapshot vote passes
• Multisig is created by MSS Chair (with upgradeexecutor) and signers onboard. The 3 chairs will rotate multisig creation responsibility
• Proposal passes Tally
• Vaults must be named well to help with organisation

Processing payments through MSS multisigs

To improve security and clarity of payments running through MSS multi-sigs, the following financial controls processes will be maintained:

Payment request: approval flow

At the outset programs using the MSS will define their payment approval flow, including

1. Which individuals can request a payment be made “payment requestor”
2. Which channel do they need to request it on “payment request channel”
3. Who else is required to approve it, triggering the payment to be queued via the multisig “payment approver”
4. A list of approved wallet addresses (maintained in On-chain Den)

This is an important security step to mitigate the risk that a Program member’s personal accounts will be compromised and used to trigger a payment by the multisig to an unintended party. (i.e. hack someone’s Telegram and tell the grants program to queue a payment up to the hacker’s wallet).

An example of this structure

1. Disruption Joe, Shawn and Ben can request a msig payment.
2. Request made in “PL Payment” Telegram group”
3. Supporting evidence of the payment will need to be produced to be reviewed by the signers (a forum post, an invoice, a milestone sign off etc)
4. One written approval as indicated by “” on the payment message required from Joe, Shawn or Ben. “payment approver” cannot also be by “payment requestor”

Given the abstraction of responsibility from multisig signers and program operators, this step is important to ensure the security and integrity of fund transfers.

Payment request: format

Payment requests should be structured as follows by the “payment requestor”

Name of supplier | Category | nature of the payment | supporting evidence

This will allow for multisig approvers to better understand the details of the payment they are being asked to process. Moreover, by ensuring clear supplier name and categorization a more efficient reporting flow can be maintained. The category of payment is to be defined by the program itself (i.e. “Tooling”, “Contributor payment”, “legal fees”). If the DAO wishes to move ahead with Token Flow reporting, r3gen finance will also conduct discovery with each program team to help them define and confirm program reporting categorization at the outset of their program.

Payment signing: Den implementation

• To aid in the efficiency and security of multisig programs at Arbitrum, we propose the implementation of Den across all MSS multisigs.
  • Efficiency: Den will automatically notify Arbitrum multisig signers when there is a transaction to sign. It will allow them to see exactly what you’re signing at a glance and cut through the noise by auto-tagging and DMing signers
  • Security: Den helps you know what you’re executing and identify malicious transactions. It allows Arbitrum multisig signers to: Simulate and decode transactions before they execute them and see the outcomes of transactions before they are signed. It also helps signers easily understand complex transaction inputs and automatically see what’s behind any address.

Conflict of Interest Policy

In order to maintain the integrity and impartiality of the MSS, signers must adhere to a strict Conflict of Interest Policy. This policy ensures that all decisions made by MSS signers are in the best interest of the DAO and free from personal gain or undue influence.

A conflict of interest occurs when an individual’s personal interests interfere, or appear to interfere, with their responsibilities to the DAO. Conflicts of interest include, but are not limited to:

1. 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 multisig itself which will be paying it’s signers directly for their services)
2. Authoring a Proposal that Funded the Multi-sig: Proposals a signer has authored or co-authored, which directly results in funding or operational changes to the multi-sig.
3. Personal or Financial Relationships: Having financial relationships with any parties that stand to benefit directly from the signer’s decisions in relation to the multi-sig operations.
4. Other Conflicts: Any other circumstances where the signer’s ability to act in the best interest of the DAO may be compromised.

Procedure in the Event of a Conflict: If a conflict of interest arises, or if a situation arises that could be perceived as a conflict, the signer must:

• Provide Disclosure: Promptly disclose the conflict to the other members of the multi-sig committee.
• Recusal: Abstain from participating in discussions and decision-making processes related to the conflict.
• Reduced Signer Multisig: In the scenario that there is a situation deemed a COI, a multisig should be created without this signer(s) included. A new threshold >50% of the total remaining signers should be included. For example, if there are 3 signers with a COI for an initiative, the new multisig for this initiative would maintain 5/9 threshold and total signers.

All COI executions must be documented by an MSS Chair and communicated to the DAO in a forum thread dedicated to MSS operations.

Removal of MSS members

There are 2 paths to the removal of an MSS member:

1. DAO Snapshot: Any DAO member can propose a Snapshot vote to remove an MSS signer. The proposal should clearly state the reasons for removal and provide evidence supporting the claims. A simple majority of votes cast by the DAO members is required for the removal to be approved with an 80M ARB Quorum (defined as total ARB votes).
2. MSS Member Agreement: If at least 8 MSS members (8 out of 12 members) agree that a signer should be removed due to breach of duties or conflict of interest, they can initiate the removal process internally. The agreement must be documented and publicly disclosed to maintain transparency. Analytics on signer activity from Den may be used as supporting evidence.

If a member is removed via the DAO Snapshot or MSS Member Agreement the member will immediately lose further compensation. Once a member is removed, the following steps will be taken to ensure continuity and maintain the governance structure:

• Interim Measures: The MSS may appoint an interim member to serve temporarily until a new member is officially elected. The 3 chairs will collaborate and decide how to select the new member.
• Subsequent Snapshot: A subsequent Snapshot vote will be held to elect a new MSS member. This ensures that the DAO participates in selecting a new signer, maintaining democratic and transparent governance.

All removal proceedings, details around the new signer, and the reasons for the removal must be documented by an MSS Chair and communicated to the DAO in a forum thread dedicated to MSS operations.

Expectations of MSS members

Transactions are expected to be promptly (within 24 hours) reviewed by all signers, and if approved through the process outlined above, signed. While we realise that there will be times when a signer may not have internet access or some other deterrent to signing, these are expected to be few and far between. If there are more than 3 lapses in expectations over the course of a 2 month period, chairs are expected to communicate that to the DAO and potentially remove the signer.

Clawback Capability

We believe each multisig should be set up with the DAO maintaining the ability to clawback funds. In order to execute this, multisigs should be set up using the same model as the security council, by making upgradeexecutor as a module so that DAO maintains full authoritative power.

This same mechanism will be used to transfer ownership of the multisigs to new members when new elections take place in 12 months. This might require a slight technical change, awaiting confirmation from the Foundation.

Optional Extra - Token Flow Reporting

r3gen Reporting on Token Flow

• To aid in the transparency and clarity of reporting within the DAO we are also proposing the publication of a monthly “Token Flow Report” which will illustrate expenditure amounts and breakdowns for all Arbitrum MSS managed multisigs.
• To generate a holistic picture of token flows across the DAO, r3gen finance will also provide insights on inflows from Sequencer Flows and a high-level summary of other direct outflows from the Arbitrum Treasury to programs not coordinated under the MSS framework.
• Within this role, r3gen finance will also be available upon request to conduct deeper on-chain analysis on spend. A form will be made available for community members to submit requests for specific on-chain spend analysis. The outputs of these requests will be shared publicly with the DAO. This will allow the DAO to self-regulate to ensure spending within the organization is consistent with the structure outlined within their proposal.
• Consolidating financial information into a monthly report will enhance the DAO’s transparency, accountability, and clarity regarding expenditures and inflows/outflows. This streamlined approach will synergise with the operational execution created by the MSS by providing holistic insights into expenditures and the movement of Token in/out of the Treasury. Moreover, it will alleviate the burden on individual programs, relieving them of needing to directly track, draft, and publish exhaustive financial reports.
• Token Flow represents the next layer of accounting and financial reporting on top of the MSS and together creates a holistic backroom finance function for the DAO with much needed data around spending included.

To get a flavour for what a Token Flow report would look like, we encourage you to review this sample report.

Pricing for Token Flow Report: $6650 USD per month paid in ARB on the 1st of the month using USD/ARB spot price. This includes the fee for the web3 accounting sub-ledgers and other tooling costs. Token Flow Reporting will commence in the first calendar month after the proposal passes Tally.

Estimated Savings

Current Structure

Project forward estimated multisig cost for the DAO is a challenge, but assuming multisig costs project in line with historical, some future scenarios of yearly cost are displayed below:

Screen Shot 2024-05-09 at 10.33.48 AM1204×334 35.9 KB

*assuming ARB allocation cost per multi-sig breakdown as aligned with historic

Current spend on multisig with Arbitrum DAO is high, and spending could increase significantly if the number of new multisigs or ARB price increases significantly. This indicates that implementing this proposal would be of significant financial benefit to the Arbitrum DAO.

Proposed Structure
For implementation of all aspects of this proposal, we estimate the structure will incur a cost of $313,800 per year.

Multisig Support Service

Budget

We propose an allocation of 400,000 ARB to fund an approximately 1+ year multi-sig budget for the DAO. As compensation is denominated in $, but paid in ARB, the specific duration that this budget will fund signers cannot be accurately determined. Assuming the program succeeds, a renewal proposal will be drafted to top up this budget to fund continued signer payments. This will be done in parallel to a reelection process of signers performing this function.

Timeline

1. ~10 days: MSS forum period requesting comments and time to edit proposal with delegate feedback.
2. 1 week: Snapshot to signal approval/disapproval of the MSS program.
3. 2 weeks: Application period for MSS Members. Entropy Advisors is happy to handle application template creation for free and will be ready to post directly after the above Snapshot is complete.
4. 1 week: Snapshot to elect 9 signers and 3 Chairs.
5. 2 weeks: Foundation KYC/Compliance process
6. 3 weeks: Tally proposal to fund MSS

Close

We believe this proposal represents an important restructuring that will be a net benefit for the DAO. While the total cost of spiralling multi-sig committees has yet to be realised, this preemptive action will set the DAO up for long-term financial success. Together with Token Flow reporting, this proposal creates a structure within the DAO that can be utilized across many different initiatives while allowing the DAO transparency into those spends.

Voting (rank order)

FOR - Implementing MSS

FOR - Implementing MSS and Token Flow Reporting

ABSTAIN

AGAINST

Than you for this proposal.

I think is sensitive to try and cut costs when is possible, plus have a framework (i know i know cursed work) for operations that are both critical and widely used.
I have a few questions on the above.

On the flow above, to me, is not clear if the multisig is responsible to only create and execute the tx or to effectively give the green light about the tx.
I assume is the former, but want to clarify.
If it’s the latter, is likely a problem. Just taking the example above: who takes the responsebility to vet the invoce? the milestone? and so on?

The second question is about performances. While the group should not turn into a “who sign first” for the sake of metric, because is also where security issues due to rush could arise, there is a merit in measuring the effectiveness of signers. In a natural and fair way, everyone should sign as soon as possible, compatible with their IRL and online commitment and others. But also, we want to avoid people just going for “someone else is gonna sign it”. Wanted to ask if you had a check and balance for it.

Same applies for tx creations. Is usually different lift to create a new batched tx versus verify it. This should be done in a fair way, same as of the above.

Thanks for this proposal, and looking forward to see it implemented!

I think this is a great offer. Thanks for it.
There is one thing that seems wrong to me:

You cannot remove a MSS members by internal vote of the members themselves - this is contrary to democracy and the fact that they were elected by others, therefore it is possible to decide to exclude them only by a full vote of the community.

This would be if members of the Republican Party removed members of the Democratic Party from the US Congress, since they have a majority.

And the second problem is in this:

Probably worth raising by 1 vote in each category: 6/12, 7/12, 8/12, 9/12 respectively

We think this proposal as a whole should set the standard as to how multisig signers operate within most DAOs, especially ones with many different multisigs. In this case, this should decrease overall expenses significantly going forward and we urge the current programs to onboard if this were to pass.

Want to echo @cp0x’s points regarding the removal of MSS and also think upping the requirements in each of the categories by one is appropriate.

One point we think most elections do that is helpful here is switching steps 4 and 5. It doesn’t make sense to KYC everyone if a good chunk won’t be elected. It seems more reasonable to elect and then KYC. If they fail to do so, the spot goes to the next one in line that can.

1. ~10 days: MSS forum period requesting comments and time to edit proposal with delegate feedback.
2. 1 week: Snapshot to signal approval/disapproval of the MSS program.
3. 2 weeks: Application period for MSS Members. Entropy Advisors is happy to handle application > template creation for free and will be ready to post directly after the above Snapshot is complete.
4. 2 weeks: Foundation KYC/Compliance process
5. 1 week: Snapshot to elect 9 signers and 3 Chairs.
6. 3 weeks: Tally proposal to fund MSS

Thanks for your proposal! It is refreshing to see people trying to improve the DAO as a whole.

However, I have a few issues with the problme analysis and with the proposed solution.

The first one is about the cost. While the values are true, the reasoning seems not, IMO. First the overall value extrapollated to a yearly one. ONE program is responsible for HALF of the costs presented. The DAO evolved a lot on handling multisigs since the deployment of the STIP program, and the other ones following it proposed to pay a value way lower to the signers. And we take a program that ran for 3 months and multiply it by 4 to justify a high number.

In the current setup, we have 19 signers on multiple multisigs. While some are on more than one multisig, this is a way to promote more participation, and their “mandate” is short (only through the duration of the program). The proposed structure calls for 12 signers with an yearly mandate. This is concentration/centralization in a hand of a few, for a long period of time.

Now, if we see this as a problem (the cost of paying peolpe to sign transaction in a multisig), and we want an “execution layer” for the payments and other stuff related with it, IMO, it makes more sense to have this in a structure like the proposed OpCo, rather a standalone committee which responsability is to manage multisig transactions (and, ofc, all the reporting atttached to it),

My 2 cents on the matter.

One thought immediately jumps to mind - if we provide a fixed cost to each member that doesn’t allow much flexibility with workload. Signers would be paid the same amount whether there is one active multisig or 20. The current model is expensive, but comes at the benefit of greater flexibility thru variable costs depending on workload.

I do believe as a broader idea it is a good one however.

Thank you kindly for your helpful feedback (as always :). You’re right, the example is not clear. The format for approvals allows proposals to name who are fulfilling the roles of “payment requestor” and “payment approver.” The ARDC is likely a better example where there are clearly defined positions involved. In this proposal, a member of Chaos Labs would be listed as one “payment requestor” and the DAO Advocate would be the “payment approver.” This model fits into our next proposal, which will aim to create oversight mechanisms in the DAO, where this oversight party can be named as “payment approver” in proposals.

Regarding performance metrics and efficiency, we acknowledge the importance of balancing promptness with thoroughness. One of the reasons we want to give the MSS the ability to internally remove a remember is for exactly this purpose. We struggle to ideate a good mechanism for adding checks around the effectiveness portion of this problem, besides clearly stating and stressing to the DAO that who signs first is not a valuable metric.

Thanks for your insightful and true thoughts. We would like to give the MSS the ability to efficiently remove incompetent signer since their fellow members will have the most insight into their efficiency and effectiveness, do you think increasing the threshold for internal removal here to 8/12 would suffice?

To be candid, we aren’t sure what the correct balance between efficient action and security is. We are more than open to increasing the threshold by 1 for each initiative. We would love to make a call to action for more delegates to weigh in here.

Thank you for this call out, the proposal will be edited with this suggestion now.

Thank you for your thoughtful feedback. Regarding the cost extrapolation: Our intention was to provide a clear example of how costs can escalate under the current system. However, we agree that this could give the impression of overstating the problem.

Regarding the concern of centralization: the proposal’s intent is to enhance consistency and professionalism within the DAO’s operations. We are open to explore mechanisms such as staggered terms or more frequent rotations of signers to prevent excessive centralization and keep the system dynamic and inclusive if other delegates echo this thought.

Lastly, on integrating the OpCo versus a standalone committee. Our 2 primary thoughts here surround checks and balances being good for the DAO and the fact that the OpCo is not currently in a form where it is executable and may face friction in getting there.

Thank you for sharing your thoughts, and we appreciate your support for the broader idea. We understand your concern about the fixed compensation structure. Our approach to standardize the payments to $1500/$2500 per month aims to attract and retain highly qualified and trustworthy signers as we anticipate an increase in initiatives requiring their expertise and competency. This fixed rate is primarily set to ensure reliability and commitment from the signers, rather than being a direct reflection of workload (it is likely still a high payment in that context.) If the number of multi-sigs significantly fluctuates to the downside, it certainly merits a discussion to align the compensation with the workload. That said we believe the evolving dynamics in the DAO show an increased number and velocity of proposals requiring multisigs.

I think that no one from MSS members can remove another member.
I know from the implementation of such decisions in real politics and they always lead to bad results for community.

A member can only be removed in advance according to the rules, such as failure to fulfill his obligations and only after a general vote.

I see a lot of merit on this initiative but also significant downsides.

Having multiple multisgi committees does help with decentralisation, which is quite critical to ensure resilience in the DAO. Wouldn’t the current proposal make the DAO quite fragile to 12 individuals being bribed/blackmailed? (or even only 5-7 out of 12 who could approve/block virtually everything)

Also, when designing the RnDAO proposal, a key concern for us was, above signing payments, was oversight i.e. reviewing the delivery of milestones to approve payments. I don’t see how the proposed solution nor problem definition takes that into account and I’m concerned it can clash.

I had made this thread a couple of days before this proposal was posted to discuss oversight specifically and there’s a pol.is exercise to find consensus and key points for discussion. Maybe something that can be valuable for the discussion here

Thank you for your feedback. Currently, as shown in image 4, a small number of signers are reused across multiple proposals. Our proposal aims to assign these responsibilities to 12 carefully selected, highly trustworthy, and competent signers. We believe that having the highest quality signers, rather than increasing the number simply for diversity’s sake, will better serve the DAO. Realistically, the pool of individuals interested and qualified to sit on the DAO’s multisigs isn’t vast. Each selected signer will undergo a rigorous KYC process conducted by the foundation to ensure their integrity and reduce the risk of coercion. We remain open to exploring additional mechanisms to enhance both trust and decentralization within the MSS’s structure.

Please see the section titled “Processing payments through MSS multisigs” and let us know if this addresses your concern.

We agree whole heartedly that the DAO needs an oversight committee. We think it would pair well with the MSS given the payment processing mechanism alluded to above, and are currently working on a proposal in this regard.

thanks for the quick reply!

I would disagree with this. The current group that has high context is small, but people with enough visible reputation that can be trusted and could be attracted into Arbitrum is higher.

I re-read the “Processing payments through MSS multisigs”, but can’t understand how it would intersect with oversight specifically. I roughly understand approvers would signal through telegram emoji-reactions. Is that correct?

What if new multisigs were created with the oversight members for each project, and thus the MSS can “bulk up” the number to ensure safety while still the whole thing benefits from Web3 security (as opposed to social media’s)? This is not a strong opposition to the proposed design btw, more of a suggestion for improvement.

I’d suggest it shouldn’t be a committee, but rather a pool from which members can be drawn via sortition, thus enabling multiple committees to be created. Centralising oversight too much will have the same issues of capture risk I mentioned for the MSS and I see no reason for it other than concerns about talent shortage.

I’m in favor of this initiative. In addition to generating cost savings, I believe it will make the DAO more efficient and safer by creating one clear set of multisig operations that can be audited and integrated with from a tooling perspective.

Very impressive analysis and a well thought out proposal!

gmgm.

First of all, congrats @MattOnChain for the successful onboarding of @Entropy. You quickly put together a very well-thought-out and needed proposal. I like it, I think it addresses an issue that needs resolution.

My only concern is that I’m unconvinced about needing a third party to report on the msig expenses. Wouldn’t it be simpler to pay one of the signatories a little extra (like the chair one) to handle the reports? As the data above shows, the transactions are few.

Additionally, regarding the tasks assigned to this third party, it seems that several are quite out of scope to justify the budget. The tasks listed have value and could provide a valuable service to the DAO, but shouldn’t they be included in a separate proposal? I believe this would also be on the scope of the proposed OpCo.

Besides this great proposal, something that comes to my mind is that a future iteration of this could include an optimistic framework for executing approved proposals. Have you considered it when drafting it?

Instead of paying for multisig signers, a cheaper and more efficient system would be to create a Guardian Council role that would act as a gateway for malicious proposals. That Guardian Council could be the hereby proposed msig.

Tagging @Bobbay from UMA and @0xAlex from Kleros in case this is an option that might be of interest and consideration by the DAO, so they can have visibility and, if interested, put together a plan to try it out.

@pedrob, thanks for sharing your perspective

Whilst the MSS Chair could complete very basic reporting, for detailed reporting and analysis (which ultimately led to this proposal), Arbitrum requires experienced Web3 finance professionals.

The consensus seems to be that Arbitrum should be tracking inflows and expenditures. No DAO will operate effectively at scale if it is blind to its core financial metrics.

By allowing Arbitrum to integrate its financial operations and reporting functions, we can create a seamless finance back office function for all DAO programs below 50 million in value. Larger programs above 50 million (such as the GCP, AVI, and OpCo) may, in turn, set up their own financial structures and define their reporting cadence within their proposal, similarly to how we have done here.

Ultimately, reporting is about improving transparency, clarity, and decision-making. Giving the DAO the option to start doing that sooner rather than later seems a good thing. Integrating “the processing of spend” with “the reporting on spend” feels logical, as this will create an effective back-office function fully equipped to service Arbitrum DAO’s immediate financial needs.

I am in favor of this proposal and would like to see it move to snapshot sooner rather than later.

One question i had was whether we would wait for the existing multi-sigs to phase out normally, or if the option to use this multisig would be immediately applicable

I am also in favor of getting a Token Flow Report, any large company of Arbitrum’s size would require accounting to understand what is happening. I was impressed with r3gen earlier report documenting this and think we should see more of it. i would have liked for greater dissemination of the findings though - not sure how many people actually engaged with the numbers once they were crunched

Thank you for your support and for raising this question. We are also excited about the potential for r3gen to make the MSS a more comprehensive ‘accounting’ arm for the DAO and thought the Token Flow report was excellent.

Regarding transitioning from current multisigs to the proposed model, we we were considering a gradual phase-out rather than an immediate switch to be the most likely scenario given the incentives at play. To encourage current programs to transition, we’re discussing potential incentives, such as allowing signers to receive 50% of their expected compensation following a turnover.

We are revising the proposal to incorporate feedback from the community with some small changes. This includes increasing the thresholds by 1 and quorum requirement for internal removals to 8. During this edit we’ll also clarify the process for transitioning from current multisigs. Each change will be clearly outlined in a proceeding comment. This will take place Monday, followed by expecting to proceed to Snapshot Wednesday, assuming no more critical feedback.

I think it would be right to wait for the expiration of the existing multisigs

Everyone voted for the past decisions, so it is incorrect to violate them

The practical side of me looks at the cost savings, which every Arb holder wants. 9-10k per transaction is ridiculous cost which no delegate wants and the sooner we cut the flab the better

I do agree with entropys approach of letting multisig signers decide for themselves. Weve elected them so they are empowered to make decisions in the best interest of the DAO