Banner object (1)

Hack and Take the Cash !

836 bounties in database
  Back Link to program      
Maker Ecosystem Growth Holdings, Inc logo
Hall of Fame


100 $ 

Maker Ecosystem Growth Holdings, Inc


The bug bounty program from the Maker Foundation 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 Foundation property, data centers or employees
  • Automated tools
  • Compromising or misusing third party systems or services

Ineligible bugs

  • Vulnerabilities already known to the public or to the Maker Foundation 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
  • Cookie's 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 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 at the discretion of the Maker team. 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

Our employees, contractors, 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!



The smart contracts bug bounty program will develop in iterations towards the launch of Multi-Collateral Dai (MCD) where:

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

The program is planned to be a long-running program that will continue indefinitely after launch of MCD.

The scope is initially a selection of the core smart contracts of MCD as deployed on Ethereum Kovan/Görli testnets, while more contracts will be added towards MCD launch.

The minimum amounts will also increase in iterations of the bug bounty program towards the launch of Multi-Collateral Dai.

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 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.
  • Qualification for Critical will require a POC implementation and reproducible steps.

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.


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) - Liquidation Module
  • End __(MCD_END) - Global Settlement Module
  • Flapper __(MCD_FLAP) - Surplus Auction
  • Flipper __(MCD_FLIP) - Collateral Auction
  • Flopper __(MCD_FLOP) - Debt Auction
  • Vow __(MCD_VOW)- Dai Settlement


  • 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


  • WETH9_ __(MCD_ETH) - ETH Token Wrapper
    • Note: We are aware that the balance of the contract may be different than the total amount that is deposited if users send 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 balanceOf values out of scope.
  • Adapters
    • GemJoin2 __(MCD_JOIN_OMG_A) - OMG Adapter
    • GemJoin3 __(MCD_JOIN_DGD_A) - DGD Adapter
    • GemJoin4 __(MCD_JOIN_GNT_A) - GNT Adapter
    • 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.


  • Median __(to get address call for a specific OSM, for exampleseth call $PIP_ETH 'src()(address)') Medianizer for Oracles
  • OSM __(PIP_ETH, PIP_REP, PIP_ZRX, PIP_OMG, PIP_BAT, PIP_DGD, PIP_GNT) Oracle Security Module

Smart Contracts Bi-weekly Releases

Until MCD launch, the Maker Foundation will continue with bi-weekly deployments of the latest versions of the smart contracts to either the Kovan or Görli testnets. New deployments of contracts in scope for the program will only contain bug fixes or minor enhancements.

The bug bounty program will be applicable to only one release at a time, and this release is also expected to update approximately bi-weekly though with a delay relative to deployment.

The current release eligible for vulnerability reports is 0.2.17 __. Only vulnerabilities found in this deployment can currently be submitted for a reward.

Contract details for all the latest releases are available from __

Smart Contracts Investigation Tools

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

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

Deployment Scripts:

Ethereum command-line tool used by our deploy scripts:

Command line-tool for interacting with MCD.

A faucet is available to faciliate 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.


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 infrastructure owned by Maker Foundation. This program covers security vulnerabilities discovered within the Maker Foundation 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.


Firebounty have crawled on 2019-08-06 the programe Maker Ecosystem Growth Holdings, Inc on the platform Hackerone.

FireBounty © 2015-2019

Legal notices