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.
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.
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.