Master Wizard

Smart Contract Audit Report

Executive Summary

This report presents the outcomes of our collaborative engagement with the Hocus Pocus team, focusing on the comprehensive evaluation of the MagicToken, MasterWizard, and RehypothecationMasterChef contracts.

Our team conducted an initial security assessment from July 8th to July 12th, 2024. On August 5th, our team amended this report to reflect updates made to the MasterWizard contract that resolves all Findings. On November 20th, our team amended this report to reflect updates made to the MasterWizard and RehypothecationMasterChef contracts. On December 2nd, our team amended this report to reflect the mainnet addresses of the MagicToken and MasterWizard contracts.

Hocus Pocus is developing a new ERC-20 token and a new platform where users can stake various tokens into staking pools and earn rewards in the form of the team's Magic Token.

Audit Scope

Name	Source Code	Visualized
MagicToken	`0xFC38..d9a6`	Inheritance Chart. Function Graph.
MasterWizard	`0x4d58..CAcF`	Inheritance Chart. Function Graph.
RehypothecationMasterChef	`e72838c`	Inheritance Chart. Function Graph.

Name	Address/Source Code	Visualized
MagicToken `0xFC38..d9a6`	Inheritance Chart. Function Graph.
MasterWizard `0x4d58..CAcF`	Inheritance Chart. Function Graph.
RehypothecationMasterChef	`e72838c`	Inheritance Chart. Function Graph.

Audit Findings

All findings have been resolved. In addition, minimal centralized aspects are present.

Finding #1	MasterWizard	High Resolved
Finding #1 - MasterWizard High Resolved
Description: The autoCompoundPool0() function adds any current pending rewards to the caller's staked amount for the first pool. For this to function correctly, the first pool's staking token and reward token must be set to the same address. However, using the same address causes inaccuracies in reward calculations in the _updatePool() function, as the getSupply() function relies on `balanceOf(address(this))` to track staked tokens thereby mixing staked tokens and reward tokens. Risk/Impact: If a pool's staking token and reward token are set to the same address, reward calculations in the _updatePool() function will be inaccurate leading to incorrect reward distributions. Recommendation: A state variable should be added to the contract that records the number of staked tokens in each pool in the MasterWizard contract. This variable should be referenced in the getSupply() function rather than `balanceOf(address(this))`. Resolution: The team has removed the autoCompoundPool0() function from the contract.
Finding #2	MasterWizard	Medium Resolved
Finding #2 - MasterWizard Medium Resolved
Description: If users transfer tokens directly to the contract, the rewards for stakers will be deflated as the getSupply() function uses `balanceOf(address(this))` to track staked tokens if `farmContract` was not set during any deposits on the platform. Risk/Impact: Direct transfers of tokens to the contract will deflate rewards for stakers, leading to inaccurate reward distributions. Recommendation: A state variable should be added to the contract that records the number of staked tokens in each pool in the MasterWizard contract. This variable should be referenced in the getSupply() function rather than `balanceOf(address(this))`. Resolution: The team has implemented the above recommendation by introducing the `poolBalance` array to keep track of each pool's balance.
Finding #3	MasterWizard	Low Resolved
Finding #3 - MasterWizard Low Resolved
Description: The add() function allows the team to assign the same staking token to multiple pools by specifying the `_checkDuplicate` parameter as false. However, assigning the same staking token to multiple will result in inaccurate reward calculations because the getSupply() function uses `balanceOf(address(this))` to track staked tokens if the `farmContract` was not set during any deposits on the platform. Risk/Impact: If the same staking token is assigned to more than one pool, reward calculations will be inaccurate, leading to potential discrepancies in reward distribution. Recommendation: The `_checkDuplicate` parameter should be removed and the add() function should enforce that each pool has a unique staking token. Resolution: The team has has resolved this issue by implementing the `poolBalance` array.
Finding #4	MasterWizard	Informational Resolved
Finding #4 - MasterWizard Informational Resolved
Description: In the autoCompoundPool0() function, updatePool() is called to update the contract's first pool. Subsequently, the pendingReward() function is used to calculate `pending`, but this is redundant since the first pool has already been updated by the updatePool() call. Recommendation: The following logic could be used to calculate `pending` in the autoCompoundPool0() function for additional gas savings on each call: `pending = user.amount * pool.accRewardTokensPerShare / 1e12 - user.rewardDebt;` Resolution: The team has removed the autoCompoundPool0() function from the contract.

System Overview

Magic Token

TOKENOMICS

The initial supply of the token is set to zero upon deployment. The owner can mint any number of tokens to any address at any time. Any user can burn their own tokens to reduce the total supply at any time. Any user can burn tokens on behalf of another user up to their granted allowance at any time.

TOKEN ATTRIBUTES

The contract implements the EIP-2612 standard to support permits which allows for approvals to be made via signatures. As the contract is implemented with Solidity v0.8.x, it is protected from overflows/underflows. There are no fees associated with transferring tokens. The contract complies with the ERC-20 standard.

Master Wizard & Rehypothecation MasterChef

MASTER WIZARD INITIALIZATION

Any user can initialize the contract one time by specifying the Reward token address, Rewards per block, Dev address, Fee address, and Start block. The caller is automatically granted the Default Admin role.

REHYPOTHECATION MASTERCHEF DEPLOYMENT

The deployer will specify the Masterwizard address, Masterchef address, Pool ID, and Reward token address referenced in the contract upon deployment.

ADDING/UPDATING STAKING POOLS

The Default Admin can add a new staking pool to the platform by specifying the deposit token address, deposit and withdraw fee percentages, and allocation points of the pool. The team must ensure not to assign the same deposit token to multiple pools. Additionally, the staking token should not be an ERC-777-compliant token as this could introduce reentrancy to the platform. The Default Admin can update an existing pool's allocation points and deposit and withdraw fee percentages at any time. The updated withdraw fee must not exceed its previous value.

DEPOSITS

Any user can initiate a deposit by specifying a Pool ID and an amount of the pool's staking token to deposit into the contract. The caller must grant the contract a sufficient allowance in order for the deposit to successfully occur. The Deposit fee assigned to the pool is charged and the deducted tokens are transferred to the Fee address set by the team.

The deposited tokens are transferred to the RehypothecationMasterChef contract. They are then subsequently deposited into the MasterChef contract specified within the RehypothecationMasterChef contract.

If the caller has previously deposited tokens, any pending rewards are automatically calculated on their behalf. If the Farm contract associated with the pool is set, the pending rewards from the MasterChef contract are transferred to the Farm contract. The contract's Reward token balance is then transferred to the Fee address set in the MasterWizard contract.

CLAIMING

Any user that has deposited tokens can initiate a claim for any pending rewards for any specified pool at any time. Users may also elect to claim rewards from all pools in a single transaction.

WITHDRAWALS

Any user that has initiated a deposit can specify a Pool ID and an amount to withdraw at any time. Any pending rewards are automatically calculated and transferred from the contract to their address. The Withdraw fee assigned to the pool is charged and the deducted tokens are transferred to the Fee address set by the team.

If the Farm contract associated with the pool is set, the pending rewards from the MasterChef contract are transferred to the Farm contract. The contract's Reward token balance is then transferred to the Fee address set in the MasterWizard contract.

EMERGENCY WITHDRAWALS

The Default Admin can specify a pool ID to enable emergency withdrawals for at any time. An emergency withdrawal is subsequently triggered in the MasterChef contract. The allocation points assigned to the specified pool are set to zero and future deposits are prohibited from occurring.

Any user that has initiated a deposit can specify a pool ID to emergency withdraw from at any time. The allocation points assigned to the specified pool must currently be set to zero in order for the transaction to successfully occur. The caller's full deposit amount for the corresponding pool is transferred from the contract to their address.

POOL REWARDS UPDATES

The relevant pool is automatically updated during deposits and withdrawals to ensure accurate reward distribution. The update process calculates rewards accrued since the last update, based on the number of new blocks and the pool's allocation points. New reward tokens are minted, adding them to the pool's balance and minting an additional percentage to the Dev address based on the mint ratio set by the team. The pool's accumulated reward per share and last reward block are then updated to the current block number.

OWNERSHIP CONTROLS

The Default Admin can withdraw any tokens not assigned as staking tokens from the contracts at any time. The Default Admin can update the Rehypothecation address associated with a pool ID as long as the number of staked tokens for the specified pool is zero. The Default Admin can update the rewards per block rate to any value at any time.

The Default Admin can initiate a Rehypothecation deposit and withdraw for any specified pool and amount at any time. The Default Admin can initiate a Rehypothecation emergency withdraw and claim for any specified pool at any time.

The owner can set the Dev address and Fee address referenced in the contract to any addresses at any time.

Vulnerability Analysis

Vulnerability Category	Notes	Result
Arbitrary Jump/Storage Write	N/A	PASS
Centralization of Control	The Default Admin can set the Deposit and Withdraw fee assigned to any pool to any percentages up to 100% each. The Withdraw fee cannot be increased above its original value once set. The MagicToken contract owner can mint any number of tokens to any address at any time. The team has permanently set the owner as the MasterWizard contract to enable the minting of rewards.	PASS
Compiler Issues	N/A	PASS
Delegate Call to Untrusted Contract	N/A	PASS
Dependence on Predictable Variables	N/A	PASS
Ether/Token Theft	N/A	PASS
Flash Loans	N/A	PASS
Front Running	N/A	PASS
Improper Events	N/A	PASS
Improper Authorization Scheme	N/A	PASS
Integer Over/Underflow	N/A	PASS
Logical Issues	N/A	PASS
Oracle Issues	N/A	PASS
Outdated Compiler Version	N/A	PASS
Race Conditions	N/A	PASS
Reentrancy	N/A	PASS
Signature Issues	N/A	PASS
Sybil Attack	N/A	PASS
Unbounded Loops	N/A	PASS
Unused Code	N/A	PASS
Overall Contract Safety		PASS

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!

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