MasterChef Smart Contracts: The Workarounds for the Fatal Flaws

MasterChef has certain flaws that can be fixed during use, but only if the users are aware of them and what they can do. Here’s the workaround, according to Gleb Zykov and ​​Vlad Korovnikov of HashEx.

Decentralized exchanges (DEXes) used to be quite rare only two short years ago, and yet today, it seems that they are everywhere. Numerous projects having their own personal DEXes. This happened because, when a blockchain project decides to launch a DEX, they don’t make it entirely from scratch. Instead, the basis for the DEX’s code is often a fork of one of two major DEXes — SushiSwap or PancakeSwap.

Masterchef Smart Contract

These two exchanges pretty much revolutionized the DEX space thanks to a special smart contract called MasterChef. MasterChef appears in both of them, and so it also appears in any DEX that was made as a fork of one of these two. Each new DEX gets to share the same features. But it also means that it shares MasterChef’s shortcomings and vulnerabilities. 

So let’s take a look at what problems users and developers may encounter when dealing with MasterChef. What should they pay attention to? And how should they be approached?

How do DEXes work?

The first thing to note is that a MasterChef contract is a smart contract written in Solidity that controls what a farm can do, and how it can do it. In most projects, there are multiple smart contracts sharing the responsibility and work. But when it comes to MasterChef-based protocols, it’s this single contract that takes care of everything regarding the farming.

Decentralized exchanges allow you to exchange cryptocurrencies without having to deposit money in the exchange’s wallet. Instead, you deposit funds to smart contracts from your own wallet. You are the only person who controls it and can access your own funds if the contracts don’t have backdoors or vulnerabilities.

Another difference lies in the fact that CEXes use order books for buying and selling. This means that they match buyers with sellers, while DEXes use AMM (Automated Market Maker) protocols for trading, which calculates the price of the assets depending on how much liquidity is invested.

Liquidity comes from liquidity pools, which are pools to which users can deposit funds for specific pairs and make funds available for the protocol. Then, when someone tries to buy assets using that pair, their order is immediately fulfilled using the funds from the pool. Meanwhile, people who deposited funds to the liquidity pool get LP tokens for that specific pool. This provides them with the right to share rewards.

And, if they ever wish to get their funds back, all they need to do is give back the LP tokens that they received.

As you may know, there are multiple ways to generate yields from crypto holdings. Farms give additional rewards for providing liquidity. Users add liquidity to DEXes, get LP tokens, and stake them in farms.

MasterChef: Vulnerabilities and flaws

We’ve covered how DEXes work and how liquidity pools work. So, let’s take a closer look at where the MasterChef vulnerabilities come in, how they affect the process, as well as what approach you need to take to ensure that things keep going smoothly.

Compromised accounts

One of the biggest problems to watch out for revolves around the owner accounts being compromised. Basically, SushiSwap invented a method that allowed it to gain an edge against Uniswap. That method revolves around migrating assets from one exchange to another. This is handled by the contract using a separate function that is only accessible by the contract’s owner.

However, this migration can end up being tuned to basically any contract, without any limits, which ended up being a major oversight. So, if the owner account is compromised, this can result in a new migration contract that would send all the base LP tokens in all the farming pools to an arbitrary address. This would lead to a massive loss of invested assets.

It should be noted that this function is now familiar to developers, and so it ends up being removed right away in forks. However, if it remains present, that should instantly be taken as a red flag.

Another thing to note is that, in some MasterChef forks, the owner of the contract may change emission rate without any limits. If the account is compromised, however, an attacker may set a very big emission rate, which would lead to the devaluation of the token.

There is a fairly easy way to solve this simply by ensuring that all features available to the owner of the contract require multi-signature authorization. That way, if a single address is compromised, bad actors wouldn’t be able to do much with it. Another thing to do is to add a temporary block (Timelock contract) on calling the migration function. This way, the user has more time to make a decision, and the exchange would have to notify you of the migration or any other suspicious transaction.

Adding identical farming pools

Another fairly obvious but overlooked issue emerges when the original contract doesn’t account for processing identical farming pools, meaning that the contract threatens to wrongly calculate the farming rewards.

This is not a huge issue if the MasterChef is used correctly, as the owner would not add identical pools on purpose. In fact, in properly-operating exchanges, these things are verified and creating a duplicate pool is strongly prohibited. So, if you start the pool creation and you are headed down the path of creating a duplicate of the existing pool, the system should be able to report an error. Or, suggest that you add your funds to the existing pool instead of making a new one.

Not calculating the quantity of deposited tokens

For some reason, people tend to forget to consider what might happen if tokens with commissions on transfers or rebase tokens are added as pools to the MasterChef contract. What does happen is a breakdown in the way the rewards are calculated, since the contract code adds assets to pools only by calling certain functions. This means that adding tokens to the address will combine them with the assets already in the pool. But the calculations for rewards for such tokens may be broken which leads to vulnerabilities.

Properly operating platforms should calculate the quantity of funds transferred for farming separately by checking actual transferred amount which considers commissions. This way, the reward calculations are done correctly.

MasterChef: Conclusion

MasterChef is a single smart contract used for farming yield by providing liquidity in DEXes. Unfortunately, it has certain flaws that can be fixed during use, but only if the users are aware of them and what they can do. 

Above we have covered several things that can happen and how these issues can be avoided. But it should be noted that there are more of them, such as dilution of rewards if tokens sent directly to the contract address, issues with start block changes, gas optimizations, and more. 

In other words, there are vulnerabilities and issues to keep in mind and keep an eye on. But overall, MasterChef is a revolutionary contract that has pretty much enabled decentralized exchanges. So, as long as you keep using it carefully and remain aware of its flaws and how to fix them, you should be fine.

About the authors

Gleb Zykov is the Co-Founder and CTO at a DeFi security and analytics company HashEx.

​​Vlad Korovnikov is the Junior Smart Contract auditor and developer.

Got something to say about Masterchef workarounds or anything else? Write to us or join the discussion in our Telegram channel. You can also catch us on Tik Tok, Facebook, or Twitter.