*Paid Advertisement. Not financial advice. RugDoc is not responsible for the projects showcased here. DYOR and ape safu.

How To Use Diffcheck to Check a New Farm’s MasterChef Contract

Putting your precious funds into a new yield farm can be very risky, but we can make it a bit safer by checking the MasterChef contract against that of previous, proven farms to check for malicious or otherwise dangerous code.

Can’t read Solidity? That’s OK: usually there is very little difference between the farms and in many cases a quick diffcheck can clear the new MasterChef as not containing obviously malicious code.

Step 1: Locate the MasterChef and copy it into DiffCheck. #

GarudaSwap lists its MasterChef in the docs under “no Migrator code”

Most farms list the address of their MasterChef in the docs page linked from their site.

We’ll use GarudaSwap as an example in the following steps.

GarudaSwap’s MasterChef on BscScan. “Copy” button second from the right.

Make sure it is verified on bscscan.com (don’t take it from GitHub as it may not match the deployed contract) and copy it from there.

MasterChef pasted into DiffChecker. This one closely resembles the PantherSwap MasterChef

Paste the new ‘chef into one of the columns on Diffchecker. Look at the bottom part of the ‘chef code to identify which parent code the new ‘chef is forked from.

Step 2: Find the MasterChef it has been forked from. #

The commonly forked ‘chefs can be identified by looking at the end of their code. Here are listed the various ‘chefs and how they end.

  • Goose ends with:
    //Pancake has to add hidden dummy pools inorder to alter the emission, here we make it simple and transparent to all. function updateEmissionRate(uint256 _eggPerBlock) public onlyOwner { massUpdatePools(); eggPerBlock = _eggPerBlock;
  • Pancake ends with:
    // Update dev address by the previous dev. function dev(address _devaddr) public { require(msg.sender == devaddr, “dev: wut?”); devaddr = _devaddr;
  • Viking ends with:
    //Pancake has to add hidden dummy pools inorder to alter the emission, here we make it simple and transparent to all. function updateEmissionRate(uint256 _vikingPerBlock) public onlyOwner { massUpdatePools(); vikingPerBlock = _vikingPerBlock;
  • Slime ends with:
    //set what will be the stake pool function setStakePoolId(uint256 _id) public onlyOwner { stakepoolId =_id; } function enableMethod(uint256 _id,bool enabled) public onlyOwner { enablemethod[_id]= enabled; }
  • FullSail ends with:
    // Pay referral commission to the referrer who referred this user. function payReferralCommission(address _user, uint256 _pending) internal { if (address(sailReferral) != address(0) && referralCommissionRate > 0) { address referrer = sailReferral.getReferrer(_user); uint256 commissionAmount = _pending.mul(referralCommissionRate).div(10000); if (referrer != address(0) && commissionAmount > 0) { sail.mint(referrer, commissionAmount); emit ReferralCommissionPaid(_user, referrer, commissionAmount);
  • Jiggly ends with:
    //Pancake has to add hidden dummy pools inorder to alter the emission, here we make it simple and transparent to all. function updateEmissionRate(uint256 _jiggPerBlock) public onlyOwner { massUpdatePools(); jiggPerBlock = _jiggPerBlock; emit UpdateEmissionRate(msg.sender, _jiggPerBlock);
  • Blizzard ends with:
    function setFeeAddressSt(address _feeAddress) public { require(msg.sender == feeAddSt, “setFeeAddress: FORBIDDEN”); feeAddSt = _feeAddress; Deflate ends with: function inCaseTokensGetStuck(address _token, uint256 _amount) external onlyOwner { require(_token != address(balloon), “!safe”); IERC20(_token).safeTransfer(msg.sender, _amount);
  • Panther ends with:
    if (referrer != address(0) && commissionAmount > 0) { panther.mint(referrer, commissionAmount); pantherReferral.recordReferralCommission(referrer, commissionAmount); emit ReferralCommissionPaid(_user, referrer, commissionAmount);

The endings of the commonly forked Masterchef’s can be found here.

If it is none of these you have a custom code – try bringing it to the attention of the admins in RugDoc Telegram.

Step 3: Copy the forked MasterChef into DiffCheck #

You can find the repository of commonly forked MasterChefs here.

Common MasterChefs article on RugDocWiki

Here’s PantherSwap – click to open the contract in BscScan,

PantherSwap MasterChef on BscScan

As before, grab the verified contract from BscScan.

DIffcheck

In the empty DiffCheck column, copy and paste the parent fork MasterChef contract code.

And hit the “Find Difference” button.

Differences will be highlighted in the browser.

Step 4: Compare the two for differences #

Compare your codes. Where you see differences pay attention and figure out what those differences do.

Step 5: Where differences are found, check against our list of known malicious code #

Exploits and Rug Codes list

See the table “Exploits and Rug Codes” here.

Well done for reading to the end! Now you know how to (pretty quickly) evaluate a MasterChef for safety, even with little to no knowledge of the Solidity programming language.

Please stay #SAFU and #DYOR. Follow us on Twitter for regular updates of checked farms and other helpful yield-farming safety content and join us on Telegram to get more involved — if you can check farms we want to hear from you!

Updated on July 5, 2021
How do you feel about this article?
 

Leave a Reply

*Paid Advertisement. Not financial advice. RugDoc is not responsible for the projects showcased here. DYOR and ape safu.

Our mission here at RugDoc is to screen for hard rug code that results in 100% theft of ALL underlying funds for ALL participants.

This is the ONE part of the due diligence process that most people cannot simply do on their own as it costs thousands of dollars to hire a senior solidity developer to look over a farm for safety.

A project coin with terrible code can go up in price, and a project with good code and a good team can also go down in price.

Do NOT use our ratings to refer to your likelihood in making money if you invest in the project. They are ONLY in reference to code safety.

Everything else beyond code safety is YOUR responsibility to go do research on. We just make sure the casino you’re betting in won’t rob you before you even get to place a bet.

Our reviews for projects are organized into a few colors.

🟢 Least Risk
These projects are the least likely to hard or soft rug. Usually reserved for cornerstone projects of an ecosystem where it makes no financial sense for them to rug in any manner as they make more money just being legit.

🔵 Low Risk
These projects are usually established projects in an ecosystem that have a track record of success or have KYC’d to us or other authoritative sources in the real world. As a result, it is extremely unlikely for them to soft rug or hard rug their projects. The projects can still fail and the token price can go down, but usually more as a result of natural market forces.

⚪️ Some Risk
This is the default rating for projects with unknown teams but have code that is unlikely to have hard rug risk. Since the team is unknown and doesn’t have a track record of success, it’s entirely possible that they may try to soft rug by dumping tokens, abandoning the project, etc. Even a last minute contract swap to a malicious contract is possible. The only thing that is unlikely is a complete hard rug as long as you are 100% sure you deposit into the contract we review.

🟠 Medium Risk
Similar to Some Risk, but the underlying code itself is custom enough or complex enough that it warrants an elevated risk rating that needs deeper research. Make sure you read every point presented to make sure you’re comfortable with that before entering. Still unlikely to hard rug, but more chances of custom code behaving incorrectly and causing other issues.

🔴 High Risk
Project contains code or practices that are HIGHLY LIKELY to lead to catastrophic losses as they are right now. Make sure you read the description carefully as we will always warn what these issues are. If you see the words Hard Rug anywhere in the review, STAY FAR AWAY!

⚫️ Not Eligible
We reserve the right to not review exceedingly complex projects that would require tens of thousands of dollars of senior security analyst man hours. Typically these are projects that deal with leverage, lending, options, derivatives, and anything that is overly complex and which requires tons of peer reviews and audits from top audit companies.

Search

🟢 For owners who have made impactful changes and would like an update to their farm review:

1️⃣ Use #update at @RugDocChat with your description and proof of changes and it will be forwarded to our scanners.

2️⃣ This does not guarantee a change in your review.

3️⃣ Owners who have difficulty solving the issues can consider our Consultation Package - please contact @BaymaxCrypto on Telegram to discuss.