MIP39c2-SP24: Adding Immunefi Security Core Unit - IS-001

MIP39c2-SP24: Adding Immunefi Security Core Unit - IS-001


MIP39c2-SP#: 24
Author(s): @travinimmunefi
Contributors: @psychonaut
Tags: core-unit, cu-is-001, mandate
Status: RFC
Date Applied: 2021-10-06
Date Ratified: <yyyy-mm-dd>

Sentence Summary

MIP39c2-SP24 adds Core Unit IS-001: Immunefi Security


Note: the information presented in this section, and more, will be available as permanent documentation at TBD as part of our transparency reporting. It will be kept up-to-date even after the publication and approval of this MIP.


With the extensive growth of the DeFi ecosystem, as well as crypto as a whole, comes greater threats. Though a significant increase in both community sizes and funds within the ecosystem indicates a maturing environment, the glitter of success also attracts nefarious individuals and groups seeking to damage the ecosystem in exchange for their own personal gains.

While some aspects of cybersecurity within the space are well-known, primarily software audits, the shift in the ecosystem indicates a need for more proactive as well as reactive measures. With MakerDAO not only being one of the largest ecosystems in the space but also a pioneer in the push for decentralization, it is a prime target for these nefarious people. We wish to prevent, or, at the very least, minimize the negative effects of their intended actions.


Systematically improve security for builders, end users, and other stakeholders in the Maker Ecosystem by providing both reactive and proactive security services.


A Maker ecosystem with the right security measures, including regular self-evaluation for constant improvement, in order to allow the ecosystem builders and users to focus on innovation and adoption.

This is achieved through:

  1. Security Operations

    1. Identification of Critical Infrastructure - A comprehensive list of critical people and infrastructure for the Maker ecosystem and metrics that need to be tracked in order to identify the areas needing focus and have proper monitoring implemented.
    2. Bug Bounty Program - An industry-leading bug bounty program to adequately incentivize whitehat hackers to look for vulnerabilities in the Maker codebase as well as blackhat hackers to responsibly disclose vulnerabilities instead of exploiting them.
    3. Incident Response Facilitation - A refined set of “War Room” procedures and resources to minimize damages to the Maker ecosystem in the event of a successful attack.
  2. Community Support

    1. Core Unit Operational Audits - The creation, implementation, and regular evaluation of secure operational procedures for key Core Units to minimize attack opportunities.
    2. Education and Advisory - Create security resources available to all Core Units and the wider Maker community, as well as provide on-call security advisory services to foster a culture where security is taken more seriously

Core Unit ID


Core Unit Name

Immunefi Security

Core Unit Mandate

The overall goal of the Immunefi Security CU is to secure the Maker ecosystem through multiple angles by leveraging its existing and growing security community and expertise. This involves dedicated services to the Maker ecosystem, effectively establishing a security partnership with the DAO.

As a pioneer in the DeFi space with billions in funds in the protocol, the Maker ecosystem is an attractive target for blackhat hackers who look to steal funds or disrupt the protocol. With millions lost regularly in the cryptocurrency space, it is likely that the Maker protocol, its key people, and its key infrastructure, are targeted on a regular basis.

Identification of Critical Infrastructure

To ensure that the right areas are covered by the services of the Immunefi Security CU, the CU will need to regularly identify the critical areas of the Maker ecosystem, including key people, infrastructure, and processes. The CU will create metrics that need to be tracked for each of them. It will then coordinate with other CUs to leverage existing monitoring tools, and coordinate the creation of new tools for uncovered areas that are deemed critical. Where deemed necessary, the CU will create backups as well as provide necessary support for the upkeep of these tools.

Throughout this time, the CU will ensure that the other CUs are aware of all dependencies that we have with them, and the reasons for their importance. The CU will also identify critical security dependencies across CUs throughout its investigation and surface these dependencies to the relevant CUs.

Bug Bounty Program

The Immunefi Security CU will orient its growing community of security researchers on the Immunefi bug bounty platform towards the Maker ecosystem. Leveraging its expertise with bug bounty programs across the cryptocurrency space, especially the DeFi ecosystem, the Immunefi Security CU will create and propose a bug bounty program to economically incentivize further investigation of the code.

The program will attract whitehat hackers who find vulnerabilities and responsibly disclose them, so they are fixed before they can be exploited. Additionally, this provides an incentivized opportunity for disclosure of vulnerabilities instead of exploitation for blackhat hackers.

In order to achieve this, the Immunefi Security CU will:

  • Coordinate with various CUs in order to identify the scope of assets as well as impacts to ensure that bugs reported are those that are valuable to the ecosystem.
  • Maintain the program by incorporating additional content where needed, such as additional requirements for submissions, restrictions, and information, adding and removing scope as needed, and including various improvements from knowledge gained through the operation of the overall Immunefi platform. If necessary, the Immunefi Security CU will create separate bug bounty programs for different areas, for example smart contracts vs. cloud infrastructure.
  • Triage all vulnerability reports and escalate to the appropriate CU as needed.
  • Publicly report all critical vulnerabilities after all fixes have been implemented and verified in the format of a postmortem, and respond to inquiries from the community.

Incident Response Facilitation

Even with an effective Bug Bounty Program and appropriate incentives in place, there are always those who don’t care about these incentives, or believe that they can get away cleanly with more funds than the bug bounty program reward.

This is why the Maker ecosystem should still be prepared to react appropriately in the event of a serious successful attack.

The Immunefi Security CU will collaborate with other CUs to create a War Room of on-call members, both from within and outside the Maker ecosystem. This will provide the necessary support in order to minimize the impact of the attacks.

  • Technical experts to act on and validate successful attacks as well as assist in fixes as necessary.
  • PR specialists to take a proactive role in framing the perception of the exploit in a constructive manner, with the appropriate legal review of public statements.
  • Community coordinators to assist existing community organizers and managers in dealing with the immediate aftermath of the exploit.

Core Unit Operational Audits - Full Spectrum Security Service

In addition to software and public network security, operational security also needs to be considered due to the many other attack vectors that exist. This is why the Immunefi Security CU will provide operational audits to selected CUs in the form of a Full Spectrum Security Service.

The service first identifies the key areas that need focus, and what needs to be done to address them. Within three months, the Immunefi Security CU will then review the changes that were made by the audited CU, and make further recommendations where needed.

After this initial review, regular quarterly reviews will be conducted (1) to ensure that existing security practices are still being followed, and (2) to update the recommendations based on the most recent available information.

Throughout this process, Maker will be given access to the world class security expertise in our network to source the best solutions to its security problems.

In order to achieve this, the Immunefi Security CU will:

  • Connect with CUs that need the service and coordinate with each of them directly with appropriate prioritization, based on information acquired during the “Identification of Critical Infrastructure” section.
  • Assemble the team and support structure required to execute the service at the desired level.
  • Review changes implemented after three months to determine if the right modifications were done and if further modifications or actions are required.
  • Create a handbook that can be referenced by these CUs to incorporate into their emergency response operations as well as day-to-day safety procedures.

The audits include, but are not limited to:

  • Threat assessment
  • Private Key and multisig management
  • Securing the development pipeline and infrastructure
  • Physical security and key personnel security policies
  • Communications, operations, and information security
  • Incident response procedures relevant for the CU
  • Secure software and hardware recommendations

Education and Advisory

As a last pillar of our strategy, the Immunefi Security CU will provide educational resources and on-call advisory, especially those for areas not covered by the Full Spectrum Security Service.

  • Provide content that is accessible to the wider community, including resources for end users, with prioritization determined after getting feedback from other CUs
  • Conduct live seminars and workshops for Maker ecosystem projects and CUs, with a focus on smart contract security, including bringing in experts from the wider ecosystem to provide up-to-date security information.
  • Be accessible to all Maker projects and CUs for advisory on security-related matters in the form of an open questions and answers channel as well as an office hours call twice a month.
  • Collaborate with CUs that need to provision security processes, such as the SES CU when new CUs are being onboarded.


Below is a roadmap of the activities of the Core Unit of the first 5 months after the posting of this RFC

September - October 2021
  • Submit RFC for Core Unit, Budget, and Facilitator MIPs
  • Onboard Deputy Facilitator
  • Begin identification of critical infrastructure for bug bounty program coverage
  • Finalize draft of bug bounty program
  • Begin coordination for Incident Response
November 2021
  • Post Core Unit and Facilitator MIP
  • Post bug bounty program RFC
  • Begin content planning
  • Launch of social media channels
December 2021
  • Anticipated Core Unit Launch
  • Post bug bounty program MIP
  • Post Core Unit Operational Audits RFC
  • Set up weekly calls for office hours and general update calls
  • Launch community channels
January 2022
  • Post Core Unit Operational Audits MIP
  • Finalize initial incident response procedures
  • Complete identification of metrics for nefarious activity
  • First regular content publication
February 2022
  • Organize the creation of backups for critical monitoring infrastructure
  • Commence first fire drill
  • Begin Core Unit Operational Audits for two CUs

Related Documents


This is a super impressive and well thought out MIP39 submission – Thank you for not only the write-up, but also for putting together a nice explanation of what this CU will provide to MakerDAO.

With regards to short-term mitigation of a vulnerability–how many hours do you think it should take this CU to go from a white hacker report submitted, to announcing it to the the DAO members (pretty much a public announcement)? Or, do you think it should be announced to both the DAO members, and the general public via Twitter, Telegram, Discord, etc. simultaneously? And does the time to release such to the public depend on the severity? (I can imagine that it does)

Can the community expect White Hat attacks (fire drills) from this CU?

What is your plan of action for reporting vulnerabilities to other DeFi protocols that might get affected by a certain bug/possible exploit? As an example, imagine there’s a vulnerability in the DAI Arbitrum bridge that a new web 3 protocol is dependent of…


This is a super impressive and well thought out MIP39 submission – Thank you for not only the write-up, but also for putting together a nice explanation of what this CU will provide to MakerDAO.

Thank you!

With regards to short-term mitigation of a vulnerability–how many hours do you think it should take this CU to go from a white hacker report submitted, to announcing it to the the DAO members (pretty much a public announcement)? Or, do you think it should be announced to both the DAO members, and the general public via Twitter, Telegram, Discord, etc. simultaneously? And does the time to release such to the public depend on the severity? (I can imagine that it does)

The details of how the bug bounty program would work will be discussed in a separate MIP with the RFC planned to be posted in the next cycle. Thanks for asking these questions though, it helps me know what to highlight! I’ll also update this one to make this aspect clearer.

Can the community expect White Hat attacks (fire drills) from this CU?

They wouldn’t be white hat attacks per se, though the bug bounty program would encourage whitehats to look at the code. However, a fire drill will definitely be in place here with the first one set for February 2022.

What is your plan of action for reporting vulnerabilities to other DeFi protocols that might get affected by a certain bug/possible exploit? As an example, imagine there’s a vulnerability in the DAI Arbitrum bridge that a new web 3 protocol is dependent of…

This depends on the scope of the bug bounty program, which is still to be finalized. How the bug reports affecting other protocols will be handled will be addressed in the separate bug bounty MIP as well. And again, thanks for pointing this out - definitely will need to address this.

1 Like

Thanks for ping on this @psychonaut

My reaction here is this CU overlaps heavily with PE so I would like to at least have some comment from them regarding this CU addition.

Again when these CUs come on board that have functions heavily overlapping other CUs (almost being duplicated) I want to hear from the CUs where this overlap is strong about how this benefits them or whether they see issues etc.

@Derek feel free to comment here as I see Security as PE domain. I want to know if PE plans to offload security issues to this CU or whether this in fact will be a duplication of effort. When it comes to security I want not just 2 but potentially 3 teams looking at this given the importance. I do not want to get into a situation where we have a security event/issue and 2-3 CUs basically pointing at each other saying “it was their responsibility to catch this”.

When it comes to this kind of responsibility overlap I want a strong statement from CUs what is and what is not their responsibility. Because if all adding CUs is going to do is basically dilute responsibilities without giving Maker Quality Assurance and at least ‘some duplication’ of seriously important core functions I am going to start questioning the addition of these as beneficial to Maker in terms of what we get for what we are paying for.

I am going to abstain until I hear something from @Derek regarding what the addition of this CU means for PE security functions and where security responsibilities will lay with or without the addition of this CU.

Thank you in advance for responses.

1 Like

One other question because I don’t see anything in this is whether this CU intends on addressing the long outstanding issue of:

dark issues and
dark fixes.

And whether there are clear secure communication channels, persons to handle these. In the past with an issue I found I spoke with the foundation and foundation PE. What I want to know is what are the plans for formalizing these communication channels and what the DAO will need to have secure, private and trusted activities to deal with issues in the protocol being reported to the DAO.

Hi @MakerMan , thanks for calling me out on the above. Let me first refer to the vision of this proposal and assess where it does or does not overlap with the Protocol Engineering Core Unit from my perspective.

Regarding Security Operations, PECU:

  • (1) Does not manage an operational list of individuals/infra considered to be critical or any metrics/monitoring around this. (we do run keepers though, more on that below).
  • (2) Does not actively manage a bug bounty program - although we do review reports, perceived threats and write responses where needed.
  • (3) Does participate in war rooms and technical threat responses due to our unique knowledge of the protocol. We are a critical component in any of these meetings.

Regarding Community Support, PECU:

  • (1) Does not audit other Core Units in their operational security behaviour. As an independent CU, we manage and implement our own operational security practices and procedures only.
  • (2) Does and is working towards creating technical security resources and supporting smart contract documentation. I would argue that our role is more of a technical specialist focus as opposed to operational advisory.

Regarding critical infrastructure:

  • PECU, TechOps and others run keepers to ensure auctions get kicked off when required, that oracles are poked on time etc. Some of this is probably tribal knowledge, some of it on R/C, some in docs.makerdao etc - I don’t think I’ve seen a comprehensive list detailing all ancillary components (monitoring, keepers, circuit breakers etc) of the protocol. I consider PECU a critical part of that infrastructure, but I don’t see us as owners of this.

Regarding a bug bounty program:

  • Maker has always run a bug bounty program. I think it makes sense for this to continue as we scale to new non-standard collateral types and potentially new tokenomic designs.

Incident response facilitation:

  • I can see value from an operational perspective, but there is an overlap with PECU where PECU will likely remain the lead as the technical experts. This also intersects (at least in my understanding) with our relationship with industry auditors. I raise this question in the Core Unit Budget Thread

How is PECU different from the Immunefi Security CU:

In the context of security, the PECU focuses on:

  • Formal verification
  • Economic modelling of new financial mechanisms
  • Open source tooling development
  • Providing audit-like capabilities, reviews and assessments of a technical nature
  • …and much more, but consider that as a high level take

What does this proposal mean for PECU:

  • It will be essential to integrate existing and new technical experts into war rooms, pager duty, technical assessment activities. …keeping in mind the next point;

What am I cautious about - the bureaucratic (structural?) overhead that more teams introduce - however this is a natural evolution for all growing start-ups. Also, what is the overlap (or is it complementary) between proposed infrastructure groups like TechOps etc.

In conclusion, I do not see PECU offloading any of its existing security tasks because our focus and skill set is not so much operational as it is focused on research, tooling, modelling work, and technical risk assessments.


Agree with @Derek that there is practically no overlap with PECU. There could be some overlap with Techops. So this needs to be coordinated and these conversations are already going on to avoid double work.


You’re welcome @Derek and thank you for the detailed reply. forums are getting to the point I am missing stuff and only catch things now if I am actually pinged with a reference.

Showing what I don’t know about where the authority/responsibility CU structures going on. Making me think we need a kind of Maker CU authority/responsibility map so we can see the total area Maker is responsible for and then lay out the pieces so we can see where functions overlap and where there might be gaping holes.

Thank you for this comment Derek as it supports my general feeling as we get more CUs that we don’t have a decent functional structural diagram typically called an Org Chart in most companies that laid out departments, positions and organizational structure (who reported to whom and what the chain of command was).

Probably even more important to construct such a chart for Maker.

Thank you both Derek and wouter for responses. So my take away from your comments is that since this CU doesn’t have much overlap with other CU functions we probably need it and where it does overlap we do want some additional eyes.

Last time I looked around (when I found an issue in the system) it was not entirely clear who to contact to report the issue. So I contacted a couple foundation folks via rocketchat to report the issue.

Is there going to be a clear and 24/7365 available contact for Incident reporting, response, and then issue management?

1 Like