Protocol Engineering, Governance, and Evolution

Protocol Engineering, Governance, and Evolution

This post represents a rough consensus of the entire Protocol Engineering Core Unit (PECU) on two subjects that we felt would benefit from greater clarification:

  • Our role, influence, and relationship with MakerDAO governance, and
  • The reasons behind the formation and current structure of the core unit, as well as our vision for its future evolution.

We place great emphasis on being transparent in our technical work. We do this by open sourcing our code, justifying our technical decisions, making ourselves available for consultation to the entire community, and releasing public postmortems when things don’t go as intended.

We believe that transparency for the two subjects mentioned above should be given a similar emphasis, and that to date this has been somewhat lacking. We hope this post helps the DAO as a whole better understand and work with the PECU.

Governance

There are a number of sources of influence upon MakerDAO governance that are worth discussing in the context of the PECU. Fundamentally, our team has a reactive stance toward protocol governance–we consider ourselves bound by the outcomes of the now-standard signal request to on-chain poll to executive vote decision-making process (or whichever process may come to supplant it). Any deviation from this on our part should qualify as grounds for our removal by MKR holders. Our core mandate is to handle the technical aspects of the stability, security, and evolution of the protocol, and our engagement with the governance process should be limited to providing unbiased information related to that mandate, and subsequently enacting the will of MKR holders.

In some contexts however, ambiguity may arise. While we are all PECU members, we often wear other hats within the ecosystem. Most obviously, we are all MKR holders. We can also be Vault users, DAI holders, or Keepers. Some of us are Mandated Actors. It’s against our ethos to limit the speech of our team members, but we will continue to take care to clarify in what capacity we are acting when engaging in the governance process. For example, an opinion on business strategy expressed by a single individual thinking as an MKR holder should not be portrayed as a judgment by the entire team. We will continue to consistently specify the perspective we are taking in DAO conversations so that it is clear when we speak in a personal capacity versus our core unit role. If conflicts of interest arise, it may be necessary for some of us to recuse ourselves from certain conversations in which we cannot be credibly neutral, or at least give notice of potential conflicts. Finally, there likely needs to be a separate conversation about the role of the Mandated Actors in a post-Foundation context; however, we feel that is out-of-scope for this post.

A particular point to address is the MIPs process–the PECU is free to propose technical MIPs, and a valid concern is that we could in theory prioritize our own MIPs over others. This would be a serious violation of our mandate, and we are strongly committed to respecting the wishes of MKR holders when it comes to MIP execution by observing the forums, polls and executive votes to provide prioritization guidance. The best way for the DAO to reduce our application of discretion in these areas is to settle on clear priorities. Defining and implementing that prioritization process is decidedly not a part of our mandate, although we will enthusiastically provide any input needed from us to such a process.

Another important thing to address is our participation in the actual voting mechanisms, especially on-chain. We have previously committed to not serve as delegates (not even anonymously), and this remains the case. Further, we’d also like to clarify that while yes, we are MKR holders, we do not as a group, much less individually, have enough stake to influence voting outcomes. The truth is that any OG project member or VC can single-handedly outvote all of us combined. Further, some of us abstain from voting on principle or for liability reasons, and many who do vote are planning to use the newly launched delegation feature to put distance between themselves and direct decision-making. Taken together, this all means we have very little influence when it comes to passing proposals via MKR voting.

We recognize that our unique technical expertise, as well as the size of our team and the scope of our responsibilities, do present various risks and challenges in a decentralized governance context. While we believe that the DAO has more than adequate power to check us in this regard, improvement is always possible, and our team does not intend to be an exception to the rapid evolution that is integral to the cryptoverse’s DNA.

Evolution

To discuss the future, it is first necessary to recount the past and how it led to the present. Earlier this year, many of us were working within the Maker Foundation, which was rapidly hurtling towards dissolution. We made the decision to be the first team to strike out on our own. That process was largely public and is recorded on the forum, so we won’t give a blow-by-blow here. However, we do want to explain the reasons we chose to initially spin out as a single monolithic team, rather than multiple smaller teams.

The broad themes behind this choice were safety and efficiency. Specific reasons include:

  • Work on the core system needs to be tightly coordinated to avoid mistakes, and at the time of CU formation (already a period of significant chaos), we felt it was much safer for the protocol to keep everyone together.
  • Knowledge and experience were unevenly distributed among team members. Training newer members is more efficient when many mentors and projects are available, and allows broader acquisition of skills and knowledge.
  • The crypto space is highly competitive and not falling behind technologically was a significant challenge that a unified team was better suited to. For example, the effort led by our L2 experts to bridge DAI to Optimism was able to move more quickly and safely with the support of the rest of the PE team. They received code review and formal verification assistance, were spared from going through a separate and lengthy CU setup process, and did not need to establish independent relationships with auditors.
  • The crypto space moves fast and there’s a lot of opportunity–this can lead to high turnover. In the Foundation, we were perpetually understaffed due to the difficulty of replacing those who moved on to things that excited them more. This created excessive stress for the remaining team members, who were often on the edge of burnout or beyond. We felt the team needed enough people to be able to buffer a few departures without destroying the work-life balance of the rest–otherwise a vicious cycle can result where departures beget more departures. This also helps prevent burnout in other ways, such as allowing more individual freedom in project choice, and reducing the frequency with which individuals must engage in less interesting/more stressful tasks (e.g. executive spells).
  • Most successful engineering cultures grow organically. Getting engineering culture right from the start is easier in a unified team.

Now let’s jump to today. Very soon, we’ll have filled the headcount target we set (which we are committed not to exceed), and team members who were novices a few months ago have grown into experts in their own right. The PECU isn’t yet at the zenith of its capabilities, but that point is within sight, and that means now is a good time to start imagining what comes next. In some ways the monolithic PECU mirrors the monolithic Maker Foundation–a centralized bootstrapping mechanism that can spawn new entities as it continually remakes itself (unlike the Foundation, the PECU does not have an embedded death obligation, only an evolution obligation). By deeply training so many people on all aspects of the protocol, the PECU creates the raw materials necessary for a web of independent teams that can collaborate and support each other even though they might be smaller individually than the current PECU. It also creates an environment into which external teams can be safely introduced, because there’s a robust engineering culture for them to assimilate to, and protocol experts to assist them.

An example of the latter is the possibility to add an independent engineering core unit focused on expanding the Maker protocol to StarkNet–the PECU has the expertise and bandwidth to provide assistance and support to this group, helping to reduce the trust MKR holders would otherwise need to initially place in a separate team. Possibilities for the former abound as well–teams that could grow out of the PECU include: an optimistic rollup or alternative L1-focused unit, an auditing and formal verification unit, and a maintenance unit. Another possibility is for team members to move horizontally within the DAO teams–for example, someone trained in the PECU could move into a future integrations core unit, the oracles core unit, or a future collateral onboarding core unit. In fact, a structure that allows engineers to move on to new challenges without leaving the DAO can be a key talent retention mechanism. And it all starts from building a talent pool and engineering culture in the PECU first.

As for the PECU itself? As teams spin out or members migrate, it is inevitable that our core unit’s responsibilities and mandates will eventually change. Given that the exact roadmap is uncertain, so is the timeline. No doubt it will receive healthy attention and debate in the near future.

23 Likes

Appreciate the transparency @Derek.

Personally I’m quite happy that the team is scaling quickly and will reach our headcount target very soon - acquiring the right talent should be the DAOs #1 priority at this stage IMO.

I hope that you will let the community know if we need to increase the headcount and corresponding budget further to address any of the retention issues you described, or tackle projects for which the team does not have enough bandwidth. The DAO has no shortage of ideas to keep the team busy :slight_smile:

6 Likes

@Derek I truly appreciate the leadership you’re embodying with this post. Given the mandate for ensuring protocol security, explicitly speaking of the CU as a training ground for embedding best practices while encouraging new team formation feels like a sound way to move forward. Maker is in dire need of such openness and making implicit guiding principles more explicit. I had the feeling you would be first one to do this. Thank you.

7 Likes

Really appreciate this post.

A few questions.

I think PECU is clear about it’s role within the DAO.

One thing I have seen in Intentional communities that have elected roles with not so clear authority/responsibility is the wrangling over what is elected authority, against responsibility. A lot of CUs are looking at opportunities to expand the Maker system (growth ofc, RWA, etc.) I wonder if you have a view of what role PECU should play here. Simply sit back and be reactive to wishes of the DAO or other CUs, or being a bit more proactive and playing a role in higher level coordination efforts and discussions?

I think members of your team would have some valuable input but I don’t want CU roles to overlap. So I wonder whether you have a view on what the future looks like in this regard.

I am glad you are open and in front of declaring ‘conflicts of interest’.

I am interested to see what happens around the “Mandated Actors” discussion. :slight_smile:

One last question.

Do you feel Responsibilities as defined in the MIP are sufficient currently and do you think there should be an ‘Authority’ section that defines what if/any powers PECU has to carry out its mandated responsibilities.?

Thank you in advance!

3 Likes

@Derek you will be remembered in MakerDAO history as one of the most sincere and honest community members. Thank you for being you.

As a recognized delegate, I appreciate PECU for taking this stance and it will be interesting to see what GovAlpha + the community think about how/if outside business Partnerships like Centrifuge, 6s, RWA inc. and other future partners—if such should also be open minded about how they play a role in delegating + MKR voting in order to keep a distance in the outcome of voting results.

3 Likes

Hi @MakerMan , great comments - this gave me something to think about over the weekend.

PECU should remain reactive to protocol governance in the sense that the vote decision-making process solidifies our commitment to specific ongoing work. This shouldn’t prevent us from being proactive when it comes to engaging in discussions about new initiatives or the strategy of the protocol as it would be a shame if the combined experience of the PECU were not drawn upon. I expect us to remain engaged and vocal when it comes to sharing ideas and thoughts, while abiding to our notes above.

We currently maintain a great working relationship with all other core units, as our technical domain complements that of e.g. Risk, Growth, Oracles and RWAs. This requires cross-team coordination, which is a key facilitator responsibility. As additional teams come into the picture, it is understandable that there may be a need for increased cross-team management and communications if the distance between coordination efforts and granular work is to increase. Currently, the single level of abstraction between the team itself and the facilitator coordination, is ideal for allowing team members to know what is happening in other parts of the protocol, while allowing them to focus where needed without being distracted from the overhead minutiae. This of course implies that there is sufficient intra-team communication. It also implies that the facilitator (and/or mandated actors) are suitably informed.

Regarding authority and responsibility. I believe our MIP responsibilities are sufficient - they cover the work we are doing on L2s, the weekly executive duties and the overall technical safety of the protocol. I can see value in including an authority section in order to better clarify ownership of specific tasks and to prevent the deflection of responsibility once more stakeholders become involved in our (or any other) domain. In due time such a framework could resemble a RACI (responsible, accountable, consulted, and informed) to clarify involvement across an end-to-end process.


Thank you for your kind words @ElProgreso , it’s the whole team behind this one :slight_smile:

5 Likes