MELON PROTOCOL BUG BOUNTY PROGRAM 2018
Welcome to the Melon Protocol Bug Bounty Program. The purpose of this program is for developers around the world to test the security of both our smart contracts as well as front-end. In exchange, you can earn rewards in the form of MLN tokens. Please have a look at the content below before starting your hunt. By submitting a bounty, you agree to the terms and conditions set forth herein.
The complete Bounty Reward Pool equals MLN 10 000 (around CHF 300 000 at the time of writing). The individual Bounty Reward will depend on the amount and quality of bounties submitted and accepted into the Bounty Program (more details below). If the total amount of MLN rewards in the Bounty Reward Pool have been distributed, this will signal the end of the current Bug Bounty Program unless another one is announced.Scope: Melon Protocol
This Bug Bounty Program is intended to incentivize the testing of the security of the Melon protocol exclusively, ie. all the smart contracts part of the Melon system.
The smart contracts included in the scope of this Bug Bounty Program are as follows, in the src folder of the smart contracts repository ( https://github.com/melonproject/smart-contracts/tree/develop/src) :
Important principles of the Melon Bug Bounty Program 2018
- Issues reported are only valid if they relate to code that is used (or is intended to be used) in production, ie code deployed on the Ethereum main network or deployed on the test net with the intent to be deployed on the main network in the near future.
- Issues that have already been submitted by another user or are already known to the Melonport team are not eligible for bounty rewards.
- Public disclosure of a vulnerability makes it ineligible for a bounty. Instead they should be reported via encrypted email to email@example.com (PGP key fingerprint: 55DE CA3F D841 E26B 9230 18B8 9477 CD0F 85C7 9DD6) with the subject “PROTOCOL BUG BOUNTY REPORT”. Our public PGP key is available for download on our website.
- Melonport’s development team, employees, contractors and all other people paid by Melonport, directly or indirectly, are not eligible for rewards.
- The Melon Protocol Bug Bounty Program considers a number of variables in determining rewards, and is based on the exceptionally successful Ethereum bug bounty program. Determinations of eligibility, score and all terms related to an award are at the sole and final discretion of the Melonport AG bug bounty team.
- Melonport AG holds no liability towards any user funds, tokens, virtual currencies, assets,time or other value lost which results in a loss with respect to this challenge.
Qualification for Rewards
The value of rewards paid out will vary depending on severity and other factors. The severity is calculated according to the OWASP ( https://www.owasp.org/index.php/OWASP_Risk_Rating_Methodology) risk rating model based on Impact and Likelihood:
Reward sizes are guided by the rules above, but are, in the end, determined at the sole discretion of the Melonport AG bug bounty team.
- Critical: up to 5 000 MLNs
- High: up to 1 000 MLNs
- Medium: up to 200 MLNs
- Low: up to 20 MLNs
In addition to Severity, other variables are also considered when the Melonport bug bounty team decides the score, including (but not limited to):
- Quality of description: Higher rewards are paid for clear, well-written submissions. This makes it easier for us to quickly understand the scope and severity of the submitted issue.
- Quality of reproducibility: Please include test code, scripts and detailed instructions. The easier it is for us to reproduce and verify the vulnerability, the higher the reward. Please see the wiki and repos to learn more about our test suite: https://github.com/melonproject/protocol
- Quality of fix: (if included): Higher rewards are paid for submissions with clear descriptions of how to fix the issue.
Vague, unclear or incomplete reports will be deemed invalid and will not result in a payout of any bug bounty amounts. In case the report is deemed valid by Melonport AG and the vulnerability has not been executed, then Melonport AG may decide to reward the first person reporting this vulnerability with an amount of up to 5 000 MLN, subject to providing a valid invoice.
Important Legal Information
The bug bounty program is an experimental and discretionary rewards program for our active Melon community to encourage and
reward those who are helping to improve the platform. It is not a competition. You
should be aware that we can cancel the program at any time, and awards are at the
sole discretion of the Melonport AG bug bounty team. In addition, Melonport is not
able to issue bounties to individuals who are on the US, Swiss, European (or other)
sanctions lists or who are citizens of sanctioned/embargoed countries (eg. North
Korea, Iran, etc). All recipients of any bounty tokens are responsible for all taxes
under their respective jurisdictions and situations. All rewards are subject to applicable
law. Finally, your testing must not violate any law or compromise any data that is
Any live bounty program that is announced before completion of this Bug Bounty Program is treated separately from the ongoing Melon bug bounty.
Any disputes arising out of or in connection with the Bounty Program shall be exclusively decided by the ordinary courts of the city of Zug, Switzerland and in accordance to Swiss law.
What does a good vulnerability submission look like?
A good submission should typically include
- a good description of the bug
- a description of the attack scenario
- the impact of this scenario
- any other necessary components
- any other details that might be helpful
- a potential resolution or fix. Giving examples is always helpful!
Here is an example of a real issue which was has been reported during a live bug bounty:
Malicious shareholder can steal all assets held by fund.
Malicious shareholder can call function `emergencyRedeem` where parameter `requestedAssets` is an array of fund held asset addresses each repeated n times, and n for each address is selected such that `quantityHeldInFund >= (n * assetHoldings * shareQuantity) / totalSupply`
For example, assume a given fund holds 10 units of asset A in the fund contract. User Charlie holds 2 shares of 10 total fund shares. Charlie calls `emergencyRedeem(2, [address(A), address(A), address(A), address(A), address(A)])`, and is transferred all 10 units of asset A.
Malicious shareholder does not need to redeem the entirety of their shares in this attack, so it can occur until shareholder has "annihilated" all their shares.
Investigate how the underlying model should be modified to ensure that the total supply (credit) is equal to the sum of holdings (debit).
So, the bug bounty program is time limited?
Yes. The official end date of the bug bounty is 25 February 2019.
How are bounties paid out?
Rewards are paid out in MLN after the submission has been validated, usually a few days later. Local laws require us to request and safely store a proof of identity and beneficial ownership of your payout Ethereum address (a standard form A) and in some cases an additional authentication and verification of KYC/AML step. The extent of this procedure depend on a function of your nationality and the size of your bounty prize.
I reported an issue / vulnerability but have not received a response!
We aim to respond to submissions as fast as possible. However, if you have not heard from us within 48 hours please feel free to email us at firstname.lastname@example.org with subject “BUG BOUNTY REPORT - SECURITY VULNERABILITY!”.
I have further questions.
Email us at email@example.com, a member of the team will get back to you as soon as possible.