Program Update

We are temporarily pausing all submissions and will have more information in the coming weeks.

Introduction

The bug bounty program from the Maker Protocol currently contains two separate scopes, which share the same rules with a few exceptions as noted below. The scopes are:

1. Smart contracts for Multi-Collateral Dai
2. Infrastructure for select public facing domains (please see the "Ineligible Bugs" section below, especially regarding third party software, before submitting a report)

The program may be expanded in the future to include more asset types such as frontends and apps.

Risk rating methodology

We generally base our rewards on an OWASP Risk Rating Methodology score, factoring in both impact and likelihood. One exception to this is described in the Smart Contracts section.

Report policy

A bug report may qualify for a reward only when:

• It makes the Maker team aware of the bug for the first time.
• The reporter allows the Maker team a reasonable amount of time to fix the vulnerability before disclosing it to other parties or to the public.
• The reporter has not used the bug to receive any reward or monetary gain outside of the bug bounty rewards described in this document, or allowed anyone else to profit outside the bug bounty program.
• A bug is reported without any conditions, demands, or threats.
• The investigation method and vulnerability report must adhere to the guidelines in this document. It is ultimately our sole discretion whether a report meets the reward requirements.
• The reporter makes a good faith effort to avoid privacy violations, destruction of data, and interruption or degradation of our service. Only interact with accounts you own or with the explicit permission of the account holder.
• A detailed report increases the likelihood of a reward payout and may also increase the reward amount. Please include as much information about the vulnerability as possible, including:
  • The conditions on which reproducing the bug is contingent.
  • The steps needed to reproduce the bug or, better yet, a proof-of-concept. If the amount of detail is not sufficient to reproduce the bug, no reward will be paid.
  • The potential implications of the vulnerability being abused.
• Multiples or duplicates
  • Submit one vulnerability per report, unless you need to chain vulnerabilities to provide impact.
  • When duplicates occur, we only award the first report that was received (provided that it can be fully reproduced).
  • Multiple vulnerabilities caused by one underlying issue will be awarded one bounty.
• Rewards amounts mentioned in this document are the minimum bounties we will pay per bug based on severity. We aim to be fair; all reward amounts are at our discretion.

Let us know as soon as possible upon discovery of a potential security issue, and we'll make every effort to quickly resolve the issue.

Ineligible methods

Vulnerabilities contingent on any of the following activities do not qualify for a reward in the bug bounty program:

• Social engineering
• DDOS attack
• Spamming
• Any physical attacks against Maker infrastructure
• Automated tools
• Compromising or misusing third party systems or services

Ineligible bugs

• Vulnerabilities already known to the public or to the Maker team including previous findings from another participant in the bug bounty program.
• Vulnerabilities in outdated software from Maker or which affects only outdated third party software.
• Bugs that are not reproducible.
• Bugs disclosed to other parties without consent from the Maker team.
• Issues which we cannot reasonably be expected to be able to do anything about.
• Cookies missing security flags (for non-sensitive cookies).
• Additional missing security controls often considered “Best practice”, such as:
  • Content Security Policy (CSP) HTTP header
  • HTTP Public Key Pinning (HPKP)
  • Subresource integrity
  • Referrer Policy
• The following vulnerabilities in a vendor we integrate with:
  • Cross-site Scripting (XSS)
  • Cross-Site Request Forgery (CSRF)
  • Cross Frame Scripting
  • Content Spoofing
• Vulnerabilities only affecting users of outdated or un-patched browsers and platforms.
• Weak TLS and SSL cyphers (we are already aware of)

Time to response

Please allow 5 business days for our reply. We may follow up with additional questions regarding how to reproduce the bug, and to qualify for a reward the investigator must respond to these in a timely manner.

Fine Print

This bug bounty program may be canceled or revised at any time. We pledge not to initiate legal action against investigators for security research conducted within the policies described in this document. If in doubt about the scope or conditions of the bug bounty program, please send your question to [email protected]

Maker team, their close family members, any other affiliated persons, as well as anyone who belonged to the aforementioned categories at any time during the past 6 months, are ineligible to participate in this program.

Thank you for helping keep Maker safe!

SMART CONTRACTS PROGRAM

Introduction

The smart contracts bug bounty program will develop in iterations:

• The scope of contracts will increase. Contracts already in scope may be updated on a bi-weekly basis as shown on changelog.makerdao.com
• Bug bounty amounts will increase.

The program is planned to be a long-running program that will continue indefinitely.

The scope is a selection of the core smart contracts of MCD as deployed on the Ethereum Kovan testnet, while more contracts will be added as needed.

The minimum amounts will also increase in future iterations of the bug bounty program.

Special Requirements for Critical Smart Contract bugs

Like the rest of the program, the smart contracts program generally uses the OWASP risk rating methodology for classifying bugs. One exception pertains to Critical bugs which must meet the following requirements:

• The bug must allow a user to steal Collateral tokens, Dai or MKR representing at least 10% of the value of all collateral tokens from the system.
• The attack must be triggered through an attack vector that is more than just theoretical.
• The system must be in normal operational mode or emergency shutdown mode. This excludes for example any states during deployment or shortly after when the system is not fully initialized.

Note: All Smart Contract bugs must include a PoC implementation with reproducible steps. This can be the form of a Solidity or JavaScript test or a list of actions that clearly shows how the bug occurs. We recommend using Dapp tools for testing.

Smart Contracts Scope

At this time, rewards will be paid out for vulnerabilities discovered in our core smart contracts for Multi-Collateral Dai as listed below.

Exploits may be grouped as following:

1. Function-level (exploitable through a single entry-point)
2. Contract-level (combining multiple entry-points)
3. System-level (combining multiple contracts)
4. Game-level (attacking the incentive mechanisms) (currently not eligible for reward)

Only exploits within groups 1-3 are currently eligible for rewards in this bug bounty program.

The following smart contracts are included in the bug bounty program. There may be redeployments of the contracts during the duration of the bug bounty program. Please see the section below for more information on the current release eligible for bug bounties.

Contracts

Core System Contracts

• Vat (MCD_VAT) - Core CDP Engine
• Spotter (MCD_SPOT) - Price feed updater
• Jug (MCD_JUG) - Stability fee accumulator
• Pot (MCD_POT) - Dai Savings
• Cat (MCD_CAT) - English Auction Liquidator
• Dog (MCD_DOG) - Dutch Auction Liquidator
• End (MCD_END) - Global Settlement Module
• Flapper (MCD_FLAP) - Surplus Auction
• Flipper (MCD_FLIP) - English Collateral Auction
• Clipper (MCD_CLIP) - Dutch Collateral Auction
• Flopper (MCD_FLOP) - Debt Auction
• Vow (MCD_VOW)- Dai Settlement

Dai

• Dai (MCD_DAI) - Dai Token (note in a previous version of the bug bounty program this was DSToken. Currently it is dss/Dai.sol)
• DaiJoin (MCD_JOIN_DAI) - Dai Token Adapter

Collateral

• All gem join adapters are in scope.
• WETH9_ (MCD_ETH) - ETH Token Wrapper
• Note: For all adapters, we are aware that the balance (ETH or token) of the contract may be different than the total amount that is joined through the contract if users send tokens or ETH directly to the contract. We do not believe this has a negative impact on the system and so unless a report can show how having a higher balance does have negative consequences we will consider reports on the actual balance being higher than the sum of tokens 'join'ed out of scope.

Instant Access Modules

• OsmMom (OSM_MOM) - allows oracle price updates to be halted without a governance delay
• FlipperMom (FLIPPER_MOM) - allows liquidations to be enabled and disabled without a governance delay for collaterals using the English auction system
• ClipperMom (CLIPPER_MOM) - allows liquidations to be enabled and disabled without a governance delay for collaterals using the Dutch auction system; also allows permissionless disabling of liquidations for such collaterals if the Oracle module indicates that the price will fall by more than a specified per-collateral percentage
• Debt Ceiling Instant Access Module (MCD_IAM_AUTO_LINE) - allows the debt ceilings of configured collaterals to be raised and lowered permissionlessly in a constrained fashion

Oracles

• Median (to get address call for a specific OSM, for example seth call $PIP_ETH 'src()(address)') Medianizer for Oracles
• OSM (PIP_ETH, PIP_BAT, PIP_WBTC, PIP_ZRX, PIP_KNC, PIP_MANA, PIP_USDT, PIP_COMP, PIP_LRC, PIP_LINK, PIP_BAL, PIP_UNI, PIP_RENBTC, PIP_AAVE) Oracle Security Module
• LP Token OSM (PIP_UNIV2DAIETH, PIP_UNIV2WBTCETH, PIP_UNIV2USDCETH, PIP_UNIV2DAIUSDC, PIP_UNIV2ETHUSDT, PIP_UNIV2LINKETH, PIP_UNIV2UNIETH, PIP_UNIV2WBTCDAI, PIP_UNIV2AAVEETH, PIP_UNIV2DAIUSDT) Uniswap V2 LP Token Oracle Security Module

Governance

The smart contracts included for "governance" have special limitations on the types of bugs that are currently considered in scope. For instance, it is a known design aspect of governance that governance has "root" access to the MCD system and with this permission is able to manipulate system parameters in such a way that it could take actions that would qualify under this program scope. We have recently added the Governance Security Module (see pause scope below) to provide a delay in governance actions and additional protection against malicious governance proposals. Generic "Governance could be malicious" reports are not in scope.

However, bugs in the DS-Chief contract that result in the voting with, locking, or theft of MKR tokens that are not owned by the attacker are considered in scope. A bug that shows an attacker locking, voting with, or stealing another user's MKR through a bug in the Chief would be considered critical.

Additionally, bugs in the Pause or Pause Proxy contracts or MCD system permissions that allow a Governance proposal to be enacted without waiting for the pause would be considered in scope. Specifically excluded from this scope would be an attack that relies on clogging the Ethereum network, colluding with miners, or Governance not noticing or being overwhelmed by malicious proposals long enough for the delay to pass. A bug that allows governance to act instantaneously through the pause contract or to directly affect some permissionned part of the MCD system is in scope unless done via an Instant Access Module (IAM). IAMs are smart contracts with permissions that permit bypassing of the governance delay for specific actions, which are either deemed to be safe, or to be necessary as emergency defenses. Any behavior of an instant access module that violates the intent of that module is still a bug.

Attacks Leveraging Other DeFi Protocols

Attacks in the DeFi space sometimes combine multiple protocols (e.g. utilizing flash loans from a margin protocol or manipulating the spot prices on a DEX). PoCs or descriptions of bug exploits may utilize such mechanisms, either to make an attack more severe than it would be in isolation, or to achieve an attack that would otherwise be impossible or infeasible. However, they will only be considered in-scope so long as:

1. Losses or other negative effects of the attack are inflicted upon Maker ecosystem participants—MKR holders, DAI holders, Vault holders, or Keepers. If the losses or negative effects are inflicted solely upon other (external) protocols, the attack is not in scope for this bounty program (though we would encourage you to responsibly disclose to those protocols).
2. The losses or other negative effects could be prevented via changes to the MCD smart contracts already included in the bounty scope.
3. The additional DeFi protocols used exist as smart contracts on the Ethereum mainnet and can reasonably be expected to have enough liquidity in various assets to allow the attack to succeed (when there is insufficient liquidity to achieve the claimed severity level but the attack is still possible, it will still be considered in-scope but with a downgraded severity level).

Smart Contracts Releases

As-needed deployments of the latest versions of the smart contracts to the Kovan testnet and mainnet will continue. New deployments of contracts in scope for the program will only contain bug fixes or minor enhancements, unless otherwise noted.

The bug bounty program will be applicable only to the releases specified in this policy. Submissions should indicate to which release they relate.

The only current release eligible for vulnerability reports is the active mainnet release. Only vulnerabilities found in this deployment can currently be submitted for a reward.

Contract details for all releases are available from changelog.makerdao.com

Smart Contracts Investigation Tools

MCD 101 Guide A comprehensive overview of the smart contracts within MCD.

• https://docs.makerdao.com/maker-protocol-101

Official Documentation The full documentation of the Maker protocol, including smart contracts.

• https://docs.makerdao.com/

Source Code The MCD core contracts and some additional documentation can be found here:

• https://github.com/makerdao/clipper-mom
• https://github.com/makerdao/esm
• https://github.com/makerdao/dss
• https://github.com/makerdao/dss-cdp-manager
• https://github.com/makerdao/dss-chief
• https://github.com/makerdao/dss-gem-joins
• https://github.com/makerdao/osm-mom
• https://github.com/makerdao/dss-proxy-actions
• https://github.com/makerdao/dss/wiki

If reading the codebase for the first time, we recommend overlaying our annotations for easier comprehension:

• https://docs.makerdao.com/other-documentation/smart-contract-annotations

Deployment Scripts:

• https://github.com/makerdao/dss-deploy
• https://github.com/makerdao/dss-deploy-scripts

Seth Ethereum command-line tool used by our deploy scripts:

• https://dapp.tools/seth/
• Guide

MCD CLI Command line-tool for interacting with MCD.

• https://github.com/makerdao/mcd-cli
• Guide

Faucet A faucet is available to facilitate obtaining MKR and Collateral tokens on testnet. See the changelog to get the faucet address for the relevant deployment (FAUCET).

To claim tokens use the following seth command:

seth send $FAUCET ‘gimme()’

This will only work once per address.

INFRASTRUCTURE PROGRAM

Like the rest of the bug bounty program, the infrastructure program will evaluate bug reports based on the OWASP Risk Rating methodology. However, only Critical bugs are currently in scope.

Infrastructure Scope

The scope of our program focuses on exploiting specific externally facing Maker team infrastructure. This program covers security vulnerabilities discovered within the Maker public infrastructure including select websites and DNS configurations.

Systems in scope with this program are listed below. We expect to include more domains in the future.

• forum.makerdao.com
• chat.makerdao.com