✔️ TDP 45: mStableDAO Restructure - Election Process

Simple Summary

It is proposed to put in place the election process for how the mStableDAO will elect the signers for the seats in both the TreasuryDAO and the ProtocolDAO in response to the overall mStableDAO restructuring outlined in TDP 44.

This proposal outlines both the election process, as well as the tasks and responsibilities, terms, and compensation involved.

Abstract

With the overall restructuring of the mStableDAO, it is important to create a process for electing the signers for both the TreasuryDAO and ProtocolDAO in a way that is easily verifiable, decentralized, and ensures that an agile election process can take place without hindering day to day operations and other related tasks the DAO needs to perform regularly.

Previously, both DAOs consisted of a mix of entities from both the mStable core team, industry professionals, as well as community members. This new process proposes to do away with specific titles and reserved seats, and instead create one singular universal core contributor title for each signer across the board.

The “Specification” section lists the exact process that is proposed to be followed for the signer elections, and would be enforced in this way upon successful resolution of TDP 45.

Motivation

The mStableDAO is transitioning towards a more agile and decentralized structure, and the election process is a key component for this process to be successful.

By doing away with reserving specific seats for specific entities, we are widening the decentralization aspect of the DAO, while at the same time getting active contributors outside of these groups an opportunity to join the seats of the DAO.

By introducing a universal core contributor title and signer compensation, we are also hardening our DAO against malicious actors that would target specific sub-sections of the DAO and instead streamline and simplify the way anyone can contribute to the mStableDAO in a meaningful and flexible way.

Lastly, we are increasing transparency and accountability for each of the signers inside of the DAO by creating a mandatory rotation via a regular election process to ensure that Meta Governors continuously have an opportunity to chose the signers they deem most fit for the task at hand, and for allowing everyone to verify the process was carried out correctly in line with Governance.

Specification

The following section highlights the election process, terms, tasks and responsibilities, as well as the compensation of the core contributors in detail and serves as a blueprint for rolling out TDP 45:

Election process

In order to facilitate the election, the following steps will be conducted:

  1. Announcement
    a) A forum post will announce the upcoming election 4 weeks prior to the end of the old term and will remain open for 2 weeks. It details the election process in greater detail, and how to participate as a candidate. Further details that are to be provided by the candidates are outlined in the post (e.g. Ethereum address, signature, URL, short description).
  2. Nomination
    a) A member may be nominated or nominate themselves. A nomination has to be accepted by the person in question by responding to the forum post outlined in 1a with the details requested.
    b) A member may be nominated or nominate themselves for both DAOs.
    c) A member that is already part of one of the two DAOs can be nominated for the other DAO, but can never accept seats on both DAOs at the same time to ensure sufficient decentralization.
    d) To ensure that the ProtocolDAO can function in an agile and efficient manner moving forward, two out of the six available seats will be reserved for Builder subDAO members, which will ensure that smart contract upgrades and changes can be queued without needless delays and overhead. These seats will not be up for voting on Snapshot, but nominations for these seats still proceed as outlined in the process here.
  3. Election
    a) 2 Snapshot votes will be created for each DAO election after the nomination process has concluded. Multi-winner Ranked choice voting will be used preferably but will be explicitly defined in the forum post outlined in 1a.
    b) (Optionally) Candidates are given time during a community call to introduce themselves.
    c) The vote will be open from Monday to Friday.
  4. Acceptance
    a) The candidates with the highest amount of votes may formally accept their election within 7 days after the end of the voting period.
    b) A candidate that accepted the election in one DAO may not accept the election in a second one.
    c) A candidate that does not accept the election will forfeit their position to the next highest in line based on the Snapshot voting result. This also applies if the candidate didn’t accept the result within 7 days as outlined in 4a.
  5. Rotation
    a) The candidates that have accepted the election will be rotated into the multisig and added to internal communications channels specified for each of the DAO they got elected into by the Cat Herder.
    b) The rotation will happen on a first in first out basis, one signer at a time with the dedicated ownership swap functionality in the Gnosis Safe Multisig to swap owners of the safe to mitigate risk and maintain the same multisig-structure as proposed during the entire rotation manoeuvre
    c) An elected signer that does not perform the outlined signer tasks may be revoked via signer vote within the DAO (4/6 majority). If this occurs, the next highest candidate will be proposed instead. A detailed policy and process determining failure to performance of duty is to be provided in a separate document following the successful resolution of TDP 45.

Term length

A core contributor is elected for 6 months, starting from the day of the resolution of the vote. After the first term ends, all seats in the DAOs will be made available again for election. A signer that has served in the past term may run again. There are no maximum amounts of terms hat a signer can run for.

Core Contributor tasks and responsibilities

Being a core contributor for the TreasuryDAO and ProtocolDAO is an active role, and it does require regular activity and knowledge about the mStable ecosystem and the proposals that are up for execution. This new structure does not allow for passivity and simply signing transactions that are queued in the multisig!

The basic tasks and responsibilities of each core contributor are as follows:

1.) Be available to confirm multi-sig transactions within a 24 hour time window except in rare circumstances, which should be communicated to the Cat Herder at least 24 hours in advance

2.) Be available and willing to participate actively in monthly TreasuryDAO & Governance Signer Calls (4PM UTC)

3.) Have a solid understanding of good OpSec practices, including the mandatory usage of a hardware wallet.

4.) Additionally, TreasuryDAO core contributors should have a sound understanding of DeFi, keep themselves updated on developments and emerging technologies, and be able to read and understand queued multi-sig transactions and their expected behaviour. ProtocolDAO core contributors should have a sound understanding of Solidity, smart contract interactions, and other relevant skills to perform their duties well.

Core Contributor Compensation

As previously outlined, the core contributor position will come with responsibilities and duties. Therefore a universal core contributor compensation of 1000 mUSD per month is transferred to each community signer to reward them for their time and efforts given to the DAO to their dedicated wallet.

Additional compensation models that are available for core contributors that wish to engage in additional work for the DAO beyond the core tasks above will be outlined separately in TDP 47 together with the process and tooling used to facilitate these.

Next Steps

Pending no significant changes to its content, this proposal will be taken to a Snapshot vote on Monday, the 4th of July 2022.

Voting will be open for a 5 days window to give adequate time for a concurrent discussion. Governors can change their vote at any time should the discussion sway their decision. We look forward to hearing what MTA token holders have to say and seeing how they cast their votes.

1 Like

What is a WVAP? Zzzz

1 Like

Oopsy-daisy! Will get this fixed on Monday, great catch!

1 Like

Thanks @mZeroNine for putting this together. Generally, I think this sounds like a great process.

One area that could be worth discussing further is how the compensation should be denominated. The more I think about this, the more I wonder whether just paying in stablecoins would be preferable to paying in MTA.

Pros

  • This would ensure a consistent and fair amount of compensation over time, without the need for complicated calculations or 3-monthly reviews to repeg based on MTA price
  • Avoid creating regular sell pressure at times of low MTA value (not implying that all signers would sell MTA, but inevitably some will when base compensation is paid in this way).

Cons

  • This would involve utilizing treasury stablecoin assets to compensate signers. However, in line with the comment above around sell pressure, it may be preferable long term for the treasury to be able to decide when to strategically sell MTA to raise additional stablecoin reserves, rather than being subject to paying out huge amounts of MTA at times when MTA is undervalued.
1 Like

So from my understanding, every single signer seat will be up for election?

I would caution against this, with the following reasoning:

  1. Political elections or any elections that are based on individuals are a time-consuming endeavour for each individual. Usually, to secure votes, a person needs to spend a considerable amount of time being present in the public/community to be known and to compete against others.

  2. Our dev team are not wanting or have the capacity to run for election and play a political game, their time is best used for actual tasks that add the most value. We split up the tasks within our team to be more efficient. Therefore not everyone needs to be a protocol politician.

  3. We work as a team and everyone has their part to play. With the election however we break this pattern and run each as an individual.

  4. To keep the people in the ProtocolDAO that have the most knowledge about smart contracts, we require our smart contract dev to be part of it. As outlined in 1, 2 and 3 this is in contradiction.

The result is that we within the core contributor team, need always to secure enough voting power to elect our smart contract devs to keep the ProtocolDAO running. Which in a sense requires us to have control over the majority of voting power to keep our team within the multisig. So our interests are running against the interest of decentralisation.

I am strictly speaking of the ProtocolDAO and see some issues there. For the TreasuryDAO, it might be different.

I am also not saying that we should not hold any elections, just that electing core contributors that use their time in the most efficient way of doing the task that they are best suited for might not be the best for such an election process.

Suggested Workflow:

Since we have the BuilderDAO and the Builders are represented within that DAO, we should consider a workflow in which the BuilderDAO runs for election to secure funding and be the guardian of the protocol and hence receives signer seats that would allow this to be executed.

Another minor point:

  • MTA compensation calculated in USD terms is somewhat problematic. We had the same issue within the grantsDAO. The bill that we promised to fund got larger and larger as MTA price fell but the grants was accounted for in USD terms. We should think of defining the MTA compensation in MTA denomination. With some clauses that if the VWAP price gets above a certain threshold we should adjust it down.
1 Like

Thanks for the great ideas guys, this is getting me excited :slight_smile:

Personally, I think this is a much better option than paying people in MTA, because it leaves discretion with the TreasuryDAO to pick opportune times on when MTA might be high in demand and be bought easily off the market.

Based on my previous year with the GrantsDAO and overall ecosystem awareness, I think it’s fair to say that some pressure to sell MTA will always be present due to recipients often not being able to hold the token, even if they wanted to, so I think this is a good logical step forward.

Especially with so many fundraising tools becoming available to DAOs now, we really have no more good excuses to not use our own judgement for strategic sells when they make sense!

I think it’s fair, and I can see the issue with the BuilderDAO having limited resources available for this. I would propose that based on this new evidence and suggestion, that the BuilderDAO be allowed to apply in the elections and be granted 2 or 3 seats of the ProtocolDAO upon successful election, with signers that the BuilderDAO can place in the seats of their free choosing upon election resolution and public announcement in the respective thread.

I would also propose that the BuilderDAO is only allowed to switch signers upon successful re-election to minimize the social engineering risk, as we’re talking about a significant amount of seats.

Perhaps this discussion will take longer than a week, and this is fine! Would really love to hear some input from some more future BuilderDAO employees, as well as community to find some basic consensus on these points before moving this forward!

Happy Monday everyone! :slight_smile:

Hey @mZeroNine great post thanks for putting this together. The process sounds great. I would question the following:

  • perhaps 12 months is better to reduce admin
  • suggesting that we do a fixed MTA amount or fixed USD amount instead of an MTA amount fixed in USD, as this creates admin and also may mean we spend more MTA that we want to
  • suggesting we don’t tie people to 10 hrs a month of forum time but rather total commitment. I think its hard to police but on the other hand its easy to see if someone putting in significantly less than that.

Looking forward to these elections!

1 Like

I would prefer payment in this order of preference:

  1. mUSD (some quantity)
  2. MTA (some set quantity)
  3. ‘floating’ MTA quantity

The unfortunate reality for me personally is that I’ve had to liquidate MTA several times, both for personal expenses (my signer role is basically the entirety of my income at the moment) and because the USD-denominated value it represents has dropped. In fact, right now I have 0 voting power because I had to defensively unstake. (I haven’t sold the remaining quantity).

This feels terrible, and I intensely dislike doing it. However, it’s what my situation demands of me and ultimately I have to be self-interested.

mUSD would represent a hard asset that I could sit on and trade into MTA when able. Even if it meant signer stipends would necessarily need to be reduced to make it affordable, that would be worth it to me. (Of course, if the cut is enormous I have to make the time-tradeoff decision about whether to run).

I prefer a set MTA amount simply because, while very generous, sending out 1000USD in MTA is just a huge burden to the protocol. Huge upside for those who can sit on it, but enormous sell pressure for anyone applying like me who has to liquidity regularly.

edit: I suppose a blend could work too. Some amount of mUSD and (likely) a majority in MTA)

1 Like

Thanks a lot for the amazing work @mZeroNine, this whole restructure is shaping-up :rocket:

Re-funding denomination
I think in essence, paying the signers of a DAO with its native token makes a lot of sense. Work paid in volatile assets is highly reflexive; signers are being incentivized to deliver good work, therefore help the project thrive and see numbers going up
If market conditions are harsh (like right now) and it is costing a lot of MTA to the treasury, we could

  • Let the choice to the signer be paid in stables or MTA. I think community should be heard on this point.
  • Pay in stables by justifying the current cost if 1$ in MTA but as a specific measure, not a general rule

I kind of like @james.simpson view on “fixed payments”. Getting a fixed amount in stables in bear markets and the same thing with MTA in better market conditions. Getting the upside in both ways (protection and exposure) without spending MTA at infinitum. We would need a threshold to see when this stables <> MTA shift occurs but It would ease things up which is what want with this

Re-the modalities of elections

I think this sentence A member may be nominated or nominate themselves could help find a solution to @dimsome concerns about Dev time. Someone else from the Builder DAO could do it for them; were they to wish to become a signer. Also, I think the process aforementioned basically just asks for the signer’s name and a 2-liner explaining the application, not a full political roadshow. However, I very much agree that being an active signer is an actual task which involves responsibilities.

I think it goes back to a broader question contributor had: Do I have to be a signer of the SubDAO to be part of it? Keen to hear opinions about this

I agree on the 12-months timeframe as we do everything manually and the coming 6 months will be essential to mStable’s success in becoming a 4626 vault leader

Thanks everyone for bringing up some good discussion points here.

I’m supportive of moving to a 12-month election process to reduce the administrative burden.

On compensation:

To be clear, it was not proposed to continue the current model of paying a fixed dollar amount in MTA every month, but rather to pay a fixed MTA amount which would be adjusted periodically. However, that still leads to the same issues of unpredictable outflows for the DAO and added sell pressure during low times.

To @TClochard’s point on compensation in MTA creating reflexivity during good times: it should be noted that this reflexivity goes both ways and can contribute to a negative spiral. Given the primary responsibilities of a signer, I think the the goal should be to incentivise a continuous level of commitment, rather than one that is reflexive to market conditions.

I’d also advocate avoiding too much complexity in the compensation model. Any MTA component adds complexity in processing payments and, given the current MTA price, likely involves a significant commitment of MTA for unclear gain. Building in requirements to review MTA amounts also adds overhead and creates some tough challenges (incentive misalignment, challenges in fairly setting review thresholds in both directions etc.)

On the election process:

To @dimsome’s points on the inefficiencies of requiring dev’s to be nominated and elected as ProtocolDAO signers: I do understand the concerns, and it’s a trade-off between the goal of decentralization and the efficiency of specialization. However, allowing any centralized decision-making (even at subDAO level) around ProtocolDAO signers seems to compromise the decentralization of the DAO at this upper level.

I would prefer to avoid complications such as allowing the BuilderDAO to run collectively for multiple seats, as it seems unclear how a vote for this can be fairly compared to a vote for another single contributor, or what would happen if the BuilderDAO was not voted in (ie. doesn’t really solve for the risk of a key individual not being voted in).

Given the potential importance of a credibly decentralized process in issuing delegated authority to a signer group, caution should be exercised in deviating from a simple election process.

I support @TClochard’s suggestion of a single individual doing the work to make the case for certain individuals to be selected by MTA Governors (eg. because they possess critical expertise) and simply having the individual provide the bare minimum info to officially nominate themselves. Alternatively, if there are critical skills that could absolutely not be done by someone outside of a certain group, then perhaps a return to having fixed seats reserved for those who meet specific prerequisites is the best way forward.

Before the discussion gets too broadly fanned, I’ll try to summarize a few things now, and send out polls for the easy stuff, so we can focus on the difficult decisions more easily.

First things first, I think we need to re-iterate quickly the difference between the ProtocolDAO and the Builder subDAO:

ProtocolDAO

  • Stewards the Smart Contract side of the mStable Protocol
  • Executes the ratified proposals that require Smart Contract Changes or Deployment
  • Ensures that the mStable Protcocol runs as normal on a day by day basis (meaning funding gas costs into the necessary contracts, deploy guardians and watcher contracts etc…)

Builder subDAO

  • Employs the Core mStable Team, of which the Core Devs are a part of
  • Builds and Codes the parts that make the future of the mStable Protocol (v2 in our case)
  • Is responsible for Leadership related tasks, Business Development, Growth, Community
  • Gets Funded and Hired by the mStableDAO to perform the jobs described above

I think the misunderstanding here is that the Core Dev Team has a basic unrevokable and given right to be a part of the ProtocolDAO, but with decentralization being the core focus here, this would entail that if the Core Dev Team ever got into any adverse condition, the mStableDAO could no longer function, which is of course not the goal of this entire proposal.

Instead, in case of an adverse condition, the Builder subDAO could be in theory replaced by a new Builder subDAO and the protocol remain functional during the transition. This is the core reason why we want to separate the ProtocolDAO and the Builder subDAO, and changing this narrative invalidates the entire work proposed in my opinion.

I’m all for including signers from the Builder subDAO in the ProtocolDAO, but it should not be done in a way that seems like that the Builder subDAO has power and control over the ProtocolDAO. How would you explain that to a regulator? You’re independent from the mStableDAO, but you’re controlling one half of it with a majority?

One could argue that if Core Devs are unable to spend 1 hour every 6 or 12 months to make themselves known to the mStableDAO (after the Builder subDAO Representative has done most of the operational workloads), then maybe their roles and responsibilities are not clearly defined by the DAO?

I am understanding that there is little time, but little time does not mean no time. Are you seriously suggesting no developer in mStable can spend a few minutes per day doing something that’s not related to building or coding?

Also, having a representative doing the work on their behalf seems sensible, but then another misconception would be that they are guaranteed to be elected with a majority. If we chose to have the Builder subDAO representative apply on behalf of the signers in question (as said, having the safety to know that the Builder subDAO will be applying with 2 or 3 seats during every election seems very sensible), they’ll have to apply separately, so the DAO can choose who and how many of them to elect. Any other ratification would invalidate any conception of a fair democratic voting, but @soulsby already highlighted that.

What is the point of an election if you’re forced to elect a predefined majority in the first place? Then we can just have a dictatorship that demands full control over the mStableDAO as a pre-requisite to work for it, which seems hardly decentralized or autonomous!

Now with this big thing moved forward, let’s focus on some smaller fish to have ratified:

How long should the term for elected signers last?
  • 6 months
  • 9 months
  • 12 months

0 voters

How should signers in the DAO be compensated?
  • MTA (re-adjusted VWAP every 3 months)
  • MTA (fixed amount)
  • mUSD (fixed amount)

0 voters

In which way should a DAO signer show commitment in the public channels?
  • Spending 5 hrs/month visibly contributing in Discord & Forum
  • Spending 10 hrs/month visibly contributing in Discord & Forum
  • No measurable/visible commitment should be required

0 voters

I’m also considering extending the TDP discussion time until the 11th of July to give enough time to clear all these roadblocks. What do you guys think?

We can also spend the remaining third of the Governance Call to discuss this hot topic directly?

1 Like

I think I failed to properly explain my concerns. This is most obvious by the fact that certain points from my text got taken and revoked in isolation.

What we are doing with this restructure is a big step and the election process is part of a crucial piece that is important to get right. We should apply critical thinking about the proposed workflow and seek to scrutinize each step so we can identify weak points, rather than trying to defend and confirm each other’s viewpoints.

I am certainly not saying that the proposed workflow would not work if we apply it now with the status quo. But I am thinking about the robustness and scaling (hence future) of this proposed workflow. We should seek an election process that would not be needed to adjust if conditions materially change.

Robustness

Is the ability to withstand or overcome adverse conditions. I want to check whether the workflow produces some inconsistencies and weak points when thinking about scenarios that are unlikely but possible to arise.

One such scenario is the following:

  1. The BuilderDAO gets a mandate from the mStableDAO to maintain/upgrade the current contracts and develop new products that will be deployed.

  2. In order to do this properly, it necessitates control over the smart contracts in order to maintain and upgrade contracts.

  3. An election for the ProtocolDAO could result in not gaining any seats in the multi-sig for the BuilderDAO.

  4. This would lead to the result that the BuilderDAO cannot effectively execute the mandate.

However unlikely this is, it shows us that under certain circumstances it leads to paradoxical outcomes. Hence it is not robust.

Scaling

With scaling, I am wanting to find out if this structure would function effectively when the mStableDAO gets much bigger and if the voting power gets more dispersed to more holders.

  1. Let’s assume that the voting power would be much more dispersed to more participants (because we do want mStable to be successful and more omnipresent in DeFi).

  2. This means, that the voting power within the BuilderDAO gets more diminished relative to the community and wider participants (which is good for decentralisation).

  3. This could mean that competition for the signer seats intensifies, with more MTA holders it’s more likely we attract more candidates.

  4. While the mStableDAO is small and close to the core team we can agree to say that we are more informed about our work than when the voters are much more diverse and mStable is much more popular.

  5. This could lead to a scenario in which the ProtocolDAO gets filled with members that win because they are more popular (e.g. wider twitter following etc…).

  6. This again diminishes the BuilderDAO capability to execute upon the given mandate.

Conclusion

So this is what I meant by everyone being an individual playing a political game, which could happen under this workflow and if we successfully decentralise our MTA voting power further.

I see that the very thing, us wanting to decentralise, would make this process less efficient and would require us in that case to rethink again.

Also, it is quite interesting how the Synthetix election process works:

https://sips.synthetix.io/sips/sip-93/

https://sips.synthetix.io/sips/sip-124/

I think we can learn from how they choose to structure their DAOs, especially the ProtocolDAO section Specification.

Last word:

Let’s also learn from the real world and existing democracies. There is a good reason why we have representative democracies and why elections takes place for parties and not individuals that run for each ministry position.

Thanks for the feedback @dimsome, and I feel there’s more misunderstandings present that need to be cleared up:

I don’t think the process would change much. It seems sound the way it is proposed, but keen to hear where exactly it falls short.

I assume some of the arguments following address this, so will comment in detail there:

That is not the case. The ProtocolDAO gets to do this/gets this mandate (as soon to be ratified via TDP 44 in order to maintain the protocol), not the Builder subDAO.

From TDP 44: “Creation of a new “Builder subDAO” to separate the ProtocolDAO from the full-time contributor’s group that is responsible for the continuous roll-out and operations of the mStable product line. The creation of this subDAO will ensure the long-term success of the protocol while preventing any centralized points of failure or sensitivity to external threats.”

See also again my explanation in the previous post on differences between the ProtocolDAO and the Builder subDAO.

I think it’s important to once again re-iterate that building for mStable does not mean that you custody the right to upgrade the protocol or in other ways influence the protocol functionality. This privilege rests exclusively with the ProtocolDAO to ensure decentralizaton.

The Builder subDAO itself will not have any right to change, pause, or in other ways manipulate the contracts in any way, shape or form. Again, it’s the whole point of restructuring the mStableDAO.

If this would in fact happen (near impossible given the token distribution right now), then there can be fail-safes implemented in the first 2 or 3 elections if you really feel it’s necessary, but I fell very strongly that it is not necessary right now.

In fact, this is actually one of the core strengths of this proposal: The ProtocolDAO should be able to queue and upgrade the contracts that the Builder subDAO proposes, not the other way around (remember actual resilience to protect the Protocol from adverse conditions).

The only reason we recommend the Builder subDAO to having seats in the first place is to streamline the operations for the rest of the ecosystem, but we do not propose discretion or authority over smart contract changes done by the Builder subDAO, especially not as a majority.

As a matter of fact, I think we should make an explicit point/clause in this TDP that subDAOs should not be allowed to gain a majority seat in either the ProtocolDAO or TreasuryDAO, based on these discussions.

If we grow sufficiently as you say, multiple builders/subDAOs could and would in theory submit changes to the ProtocolDAO to change/upgrade smart contract functionality, and it is the responsibility of the ProtocolDAO alone to ensure these are sound in nature in terms of what the subDAO/Builders propose as a change.

Again, there is no mandate in place that gives the Builder subDAO permissions to change or upgrade the contracts of the mStable Protocol with this proposal, so I don’t know where this is coming from, but that seems to be the major misunderstanding here, so we should address this first.

If that scenario came true (again highly unlikely given the distribution of voting power, even with a popularity rise), then it is the decision of Meta Governors that these people are more competent than the Builder subDAO members to execute these smart contract changes and upgrades, and has to be respected as such (again, the whole point of decentralized governance).

I feel very much we’re hinting towards scenario here where only the Builder subDAO is able to understand how to queue, execute, and verify transactions, but this is certainly not the case.

There is a myriad of ways in which this issue can be addressed if it were to happen, but we’re really painting the devil on the wall here, and it is 99.99% expected that core team members from the Builder subDAO will be voted into the ProtocolDAO to take care of this to maintain streamlined and agile operations.

I feel this comparison lacks severly in this particular case, because there exist not multiple Builder parties in our ecosystem Meta Governors could even chose from, so Governors are forced to go with the Builder subDAO as a party to be hired to be working on the mStable Protocol on behalf of the mStableDAO.

In your projected future, there might be two or three core teams that are actively fighting for (partial) funding from the TreasuryDAO, and I think then this scenario will be a lot more realistic, especially since multiple builder parties would have different key competencies in the space the mStableDAO as a whole can benefit from (again, scaling and robustness as you said!)

I think once this takes place, it will rapidly change the way the entire way of politics around core contributor elections happen because competition will be present then.

This in turn could then also result in several builders from different subDAOs getting elected into the ProtocolDAO seats, so a very much net positive for decentralization!

Again, it would be great to get more feedback from future Builder subDAO members to take part in this discussion, to get more vantage points and opinions into this, as otherwise it’s simply an opposition arguing with one another :smiley:

I find this a little perplexing. In the scenario that the BuilderDAO retains no seats and contract upgrades are blocked by the ProtocolDAO, that implies one of several situations.

  1. The contract upgrades were malicious and blocked by another part of governance.
  2. The contract upgrades were under described, sudden, or not developed under mandate.

I feel like these are “working as intended.” The ProtocolDAO is responsible for what goes out onto a chain. If there’s a concern, it must be handled. I also acknowledge that those circumstances would be very rare, if not impossible currently.

However, in the situation that the BuilderDAO had received the mandate (via broad governance vote) to develop a feature and the ProtocolDAO chose not to deploy the mandated contracts, we have a different situation. That would be a ‘coup’ by the ProtocolDAO effectively.

Unfortunately, without cheap on-chain governance on Ethereum there’s not much to be done about that. Nothing that I’ve read about this reorganization makes this dysfunctional situation more or less likely.

Concerns about “popularity” and large token holders/delegates with outsized power are rooted in the problems of token-based voting, which mStable adopted. They aren’t bespoke to this proposal, nor do I think the proposal exacerbates the issue.

In sum, I think I understand the concerns overall. I just don’t think they’re specific to the re-org.

2 Likes

While I think a lot of the disagreement in this post is explained by the potential confusion in entity responsibilities, as outlined by @mZeroNine, I do think there is a valid point here about how we ensure that the ProtocolDAO always retains individuals with the right skills and experience:

I think it makes a lot of sense to ensure capabilities by outlining clear requirements for signers. I’m not sure they should be as strict as for the Synthetix pDAO, as the model of having signers outside the core development team has worked well in the past and increases decentralization.

Interested to understand more from a technical point of view what these requirements are. Ie. given the right specifications from a governance proposal or from Builder subDAO contributors, could anyone handle the required tasks to upgrade contracts, adjust parameters and manage ongoing protocol tasks etc.? If not, what are the specific skills required. “Being on the core team” seems like a common heuristic to capture this, but perhaps we can be more specific on requirements for a signer, and even reserve seats for some ‘technical signers’ who must meet certain criteria.

1 Like

On top of the previous polls, it would also be great to capture your votes in this following poll regarding compensation amount.

I have gotten internal feedback that we should find a soft consensus on this as well before moving this TDP forward.

How much should the signers of the respective DAOs be compensated with?
  • 1000 mUSD/month
  • 850 mUSD/month
  • 750 mUSD/month
  • Other (Please specify below)

0 voters

No, not blocked.

But someone needs to queue them in. You are part of the ProtocolDAO multisig, so I think you could evaluate by the most recent set of transactions that it requires to understand the technicalities to verify the proposed transaction. Now flip that over and imagine how much more technical it gets raising those transactions.

I agree that token-based voting has issues. Let’s acknowledge that it does and see ways to mitigate those issues.

I am afraid the majority that is arguing for decentralising the Multisig completely are not very familiar with our contracts.

Multisig transactions in the ProtocolDAO is very close to our dev team sprint planning. Some transactions are quite easy to queue, such as the disabling of the dials, others require some prior testing and fork testing, like the balancer pool “buyback and make” removal. And even when there are transactions signed, we would want to coordinate when to execute them.

Introducing an entity that completely relies on token-based voting and has to perform this critical task, that needs to be synced with our dev sprint, comms and marketing and potentially needs even to be upskilled to perform the duties of queueing transactions.

I see this as introducing some huge inefficiencies.

Yeah, those requirements are very strict and I also don’t think it should be this harsh. But it does outline quite nicely that the task of the ProtocolDAO signers requires knowledge of the smart contracts, testing the transaction prior, and developing the contract that will be used to propose an upgrade. We are losing efficiency if we separate those tasks from the core contributors.

Alternative

I would like to propose a different approach.

  • Let’s use the current ProtocolDAO multisig and transform it into the BuilderDAO multisig.
  • Setup an new ProtocolDAO multisig that functions as the “Guardians”.

Currently, smart contract upgrades need to be proposed to the DelayedAdminProxy and 7 days later they can be accepted. What if we change that? (currently, the PrototolDAO proposes, waits for 7 days, then accepts it).

We could allow the BuilderDAO to function as we do now, our process would be uninterrupted and the actions are very aligned with sprint and strategy.

A: When raising a transaction to upgrade a contract, the ProtocolDAO could act as the guardian that could veto the upgrade (if there is a good reason for it of course).

B: When raising a transaction to upgrade a contract, the ProtocolDAO could be the entity that would need to accept the upgrade

A:

.
.

B:

This “A” approach works for me and I think is very aligned with the proposal. :slight_smile:

I see two ways to potentially make this happen:

  • Confer specific rights of proposing/queuing transactions to the Protocol DAO multisig which will eventually update the general contracts. This has technical implications I’m not familiar but
  • Without trying to solve this complex variation, members of the BuilderDAO could be on the ProtocolDAO Multisig and bridge communication/execution. As this is critical, we should make sure it happens and involve it in the election process

Also, to my understanding, the original purpose of the BuilderDAO multisig is/was to operate swiftly the BuilderDAO operations (mostly funding activities). Should we add this “contract” bit to it, we could potentially duplicate the ProtocolDAO functions within the BuilderDAO and lose the focus we’re trying to build :slight_smile:

Personally, I also think Approach “A” seems sensible given the discussions that took place.

I think we would need to learn a lot more around how exactly this would work in detail, as not to duplicate work as @TClochard said, and also to ensure that everyone can verify that under this new proposition the ProtocolDAO retains the final say in whether or not a queued transaction for a smart contract change on the mStable Protocol gets executed or not.

Definitely agree that the smart contract interaction themselves, running tests, and all the other things you described should rest with the Builder subDAO, as it in the end gets paid to work in this way, and duplicating or verifying this work was carried out correctly by the ProtocolDAO is not it’s job or purpose (due to lack of expertise, money, and a myriad other things I can think of).

Maybe in the future when we grow big this will need to be re-assessed and then tackled separately, though.

We can’t realistically expect smart contract engineers outside the Builder subDAO to be part of the ProtocolDAO with the current community line-up, resources and compensation model in place, so the only responsibility of the ProtocolDAO is to ensure that what the Builder subDAO proposes in each transaction is what it says it does and nothing malicious, and that the relevant audits all check out for deployment.

Of course there are limits to all of this, and we shouldn’t create worst case scenarios against core team members that have a successful track record, but it’s important to note I think, just for completion sake.

So once this diagram gets detailed with specs, I’m happy to include in the TDP, unless there is strong opinons on insisting on an alternative, and then hopefully we can find consensus next week with all of this.

While I agree in general that the role of the ProtocolDAO should be mostly to approve transactions that have already been crafted and tested, I’m not sure on the changes proposed above. Given that the structure proposal is already live in Snapshot, I think we should focus on the election process and how we can ensure that signers with the appropriate skills are guaranteed to be selected for the ProtocolDAO.

Perhaps reserving 2/6 signer positions for technical roles with more strict requirements (similar to the Synthetix requirements). These positions could still be elected, but only from a qualified pool of candidates.

1 Like