MilkyWayExchange

Smart Contract Audit Report

Audit Summary

MilkyWayExchange is developing two token contracts, a Treasury contract, a decentralized exchange, and a yield farming platform.

For this audit, we reviewed the project team's MilkyERC20, Milky, MasterChef, Treasury, MilkyPair, MilkyFactory, and MilkyRouter contracts at commit 06516dd0464737196223ee6f61e865bfe7095909 on the team's private GitHub repository.

Audit Findings

Please ensure trust in the team prior to investing as they have some control in the ecosystem.
Date: May 11th, 2022.
Updated: May 20th, 2022 to resolve Finding #1.

Finding #1 - Milky - High (Resolved)

Description: The _transfer() function is missing a call to the _moveDelegates() function.
Risk/Impact: Any user could delegate votes to a delegatee, then transfer their tokens to another address which is then able to delegate additional votes to the same delegatee by using those newly acquired tokens.
Recommendation: The project team should add a call to the _moveDelegates() function within the _transfer() function so delegated votes from those tokens are also transferred to the new user.
Resolution: The appropriate _moveDelegates() calls are now included in both the transfer() and transferFrom() functions.

Contracts Overview

• The owners of the Milky, MasterChef, and Treasury contracts can transfer ownership at any time.
• The contracts utilize the SafeMath library to prevent overflow/underflow attacks.

Milky Contract:

• At the time of writing this report, there is no information available regarding the $Milky token distribution as it has not yet been deployed.
• A mint function is present in the contract and can only be utilized only by the owner to mint any amount of tokens to specified addresses, increasing the total supply at any time.
• There is no burn function but users may transfer their tokens to the 0x..dead address to reduce the circulating supply at any time.
• Each $Milky token represents votes intended to be used in a DAO where one token represents one vote.
• Users may delegate their votes to another address allowing them to vote on behalf of the user.
• Once votes are delegated, the user must explicitly delegate them back to themselves to regain their votes.
• Users also have the option to delegate through the use of a signed message generated off-chain, allowing for a gasless delegation for the user.
• The contract complies with the BEP20 token standard.

MasterChef Contract:

• This contract allows anyone to deposit team-designated staking tokens in order to earn rewards in the form of a reward token; the $Milky token is intended to be used as the reward token.
• On deposits and withdrawals, pending rewards are calculated and transferred to the user; however, 75% of users' rewards tokens are locked until 90 days after the deposit time.
• Users' rewards are dependent on their amount staked, time staked, and the pool's reward per share amount.
• There is a bonus multiplier applied to all users' time staked; in the contract's current state the bonus multiplier is set to 1.
• The reward per share amount is calculated using the contract's reward per block rate and the pool's allocation point percentage.
• Each time rewards are calculated, the required amount of reward tokens are minted to the contract; additionally, the developer address is minted 10% on top of the calculated reward amount.
• The owner can change the reward multiplier at any time.
• The owner can add new staking pools at any time.
• The owner can change all pools' allocation points at any time.
• The developer address can set a new developer address at any time.
• The team should be careful not to add the same token twice.
• The team must exercise caution when setting the staking token and must avoid using any fee-on-transfer tokens; if a fee-on-transfer token is used as the staking token then this contract should be excluded from the token's fee mechanism.

Treasury Contract:

• This contract enables the owner to remove liquidity from MilkyFactory LP pairs and swap the asset tokens to specified swap tokens; the swap tokens are intended to be $Milky, $WSG, and $WBNB tokens.
• The owner can liquify and swap a calculated amount of each LP token held in the contract; the calculated amount is based on the total input of each LP token, the token swap percentage, and the total swap amount.
• The total input amount is determined based on the total amount of LP tokens within the contract and the previous total liquified amount of the specific LP token.
• The token swap percentages of each swap token are as follows:
• 62.5% of the total input amount to $Milky tokens.
• 25% of the total input amount to $WSG tokens.
• 12.5% of the total input amount to $WBNB tokens.
• The total swap amount is the previous total amount of the LP token that has been swapped for the specified swap token.
• The total input and total swap amount are updated after each time tokens are liquified and swapped.


• The owner can set the milkyRouter address at any time.
• The owner can change the token swap routes at any time.
• The owner can liquify and swap LP assets to $Milky tokens at any time.
• The owner can liquify and swap LP assets to $WSG tokens at any time.
• The owner can liquify and swap LP assets to $WBNB tokens at any time.
• The owner can withdraw any token from the contract at any time.

MilkyERC20 Contract:

• This contract contains the core functionality of the Milky LP token ($Milky-LP) maintained by the MilkyPair contract.
• The contract supports ERC-712 signed messages which users can use to grant an allowances via a signed messaged, allowing for gasless approvals.

MilkyPair Contract:

• This contract supports the core functionality of the Liquidity Pool token, which contains the logic behind LP minting, burning, and swapping between the assets in the liquidity pool.
• Anyone can use the mint function to mint an amount of LP tokens proportional to the number of tokens in the contract that are not accounted for in the reserves.
• Users can add liquidity by providing an equivalent value of each token and are minted an LP token in return. The LP tokens may be burned to receive the underlying assets at any time.
• Anyone can use the swap function to transfer out an amount of the assets from the pool such that the new K value is at least as much as the current K value.
• The swap function supports flash swaps which allows anyone to use a contract to borrow any amount of any asset, as long as the borrowed amount of each asset is returned within the call.
• There is a 0.25% fee taken on all swaps; the fee remains in the liquidity pool and is proportionally allocated among all LP token holders.
• In the event that the team's platform fee is enabled, 32% of the fee is minted as LP tokens to an address controlled by the team.
• Anyone can use the skim function to transfer out any excess tokens that are not accounted for in the reserve amounts.
• Alternatively, anyone can use the sync function to include any excess tokens in the reserve amounts so that they cannot be removed.

MilkyFactory Contract:

• This contract is used to deploy new MilkyPair contracts specifying two underlying token assets.
• A "FeeTo Setter" address is set upon deployment.
• Anyone can create a pair at any time, as long as the pair has not been created yet.
• Only one MilkyPair contract can exist for any combination of two token assets.
• The "FeeTo Setter" address can set the "FeeTo" and "FeeTo Setter" addresses to any address at any time.

MilkyRouter Contract:

• This contract is used to interact with any MilkyPair liquidity pool contract created by the MilkyFactory contract.
• Upon adding liquidity, the user specifies the desired minimum amount of each token in the pair to add to the liquidity pool; the user is minted MilkyPair LP tokens representing their share of ownership of the liquidity pool.
• Upon removing liquidity, the user specifies the desired minimum amount of each token asset to receive from the liquidity pool; the user's LP tokens are burnt in the process.
• Liquidity removals support ERC-712 permits which allow the user to approve the Router to spend the user's LP tokens in a gasless manner.
• Anyone can use this contract to swap one token asset for any other supported asset along a user-specified path of token assets.
• When dealing with tokens that have a fee-on-transfer, the estimated output does not properly subtract the fee. As a result, users of fee-on-transfer tokens must set a slippage percentage prior to executing trades.

Audit Results

Contract Source Summary and Visualizations

About SourceHat

SourceHat has quickly grown to have one of the most experienced and well-equipped smart contract auditing teams in the industry. Our team has conducted 1800+ solidity smart contract audits covering all major project types and protocols, securing a total of over $50 billion U.S. dollars in on-chain value!
Our firm is well-reputed in the community and is trusted as a top smart contract auditing company for the review of solidity code, no matter how complex. Our team of experienced solidity smart contract auditors performs audits for tokens, NFTs, crowdsales, marketplaces, gambling games, financial protocols, and more!

Contact us today to get a free quote for a smart contract audit of your project!

What is a SourceHat Audit?

Typically, a smart contract audit is a comprehensive review process designed to discover logical errors, security vulnerabilities, and optimization opportunities within code. A SourceHat Audit takes this a step further by verifying economic logic to ensure the stability of smart contracts and highlighting privileged functionality to create a report that is easy to understand for developers and community members alike.

How Do I Interpret the Findings?

Each of our Findings will be labeled with a Severity level. We always recommend the team resolve High, Medium, and Low severity findings prior to deploying the code to the mainnet. Here is a breakdown on what each Severity level means for the project:

• High severity indicates that the issue puts a large number of users' funds at risk and has a high probability of exploitation, or the smart contract contains serious logical issues which can prevent the code from operating as intended.
• Medium severity issues are those which place at least some users' funds at risk and has a medium to high probability of exploitation.
• Low severity issues have a relatively minor risk association; these issues have a low probability of occurring or may have a minimal impact.
• Informational issues pose no immediate risk, but inform the project team of opportunities for gas optimizations and following smart contract security best practices.

• Go Home