Whales Candy

Smart Contract Audit Report

Audit Summary

Whales Candy is a new platform in which users can stake WC tokens in order to earn rewards in the form of the same token.

For this audit, we reviewed the WhalesCandy contract at commit f2aa27bc8256c3938cc34493e3b0465ea26b5597 on the team's GitHub repository.

Audit Findings

Low findings were identified that the team should review. In addition, centralized aspects are present.
Date: May 2nd, 2023.
Updated: May 24th, 2023 to reflect changes from address 0x4f65c13e6bf5aedc285ddb6fcfaf9ae40d92b52e on the Binance Smart Chain Mainnet to commit f2aa27bc8256c3938cc34493e3b0465ea26b5597 on the team's GitHub repository.

Finding #1 - WhalesCandy - Low

Description: The transfer() function is used to transfer BNB instead of call() in both the buyAndStake() and buyShareFromAuction() functions. As the transfer() function does not forward enough gas for any substantial logic to be executed by the receiving contract, transactions may fail.
Risk/Impact: If the Dev address is updated to a contract which contains logic that is executed upon the receival of BNB, buyAndStake() and buyShareFromAuction() calls may fail due to insufficient gas forwarding.
Recommendation: transfer() calls should be replaced with call() in both the buyAndStake() and buyShareFromAuction() functions. As the contract is already deployed, the team should ensure that the Dev address remains as a wallet address or a contract without custom logic in its receive() function in order to avoid failures.
Resolution: The team has not yet addressed this issue.

---

Finding #2 - WhalesCandy - Low

Description: As the WC token purchases in the buyAndStake() and burnAndBuyback() functions do not specify a minimum token amount to receive, they can potentially be frontrun by a malicious user for a profit if the buy tax is set to a low enough percentage.
Risk/Impact: If a buyAndStake() or burnAndBuyback() call results in a greater price increase percentage than the buy tax, a malicious user can execute a sandwich attack by purchasing tokens before the function is called and selling them afterwards. This would result in a profit for the malicious user and a loss of funds for the user executing the buyAndStake(), or a loss for the contract if burnAndBuyback() is frontrun.
Recommendation: The team should ensure that the buy tax remains large enough to prevent frontrunning opportunities. Alternatively, the team can use a price oracle in order to calculate desired minimum token amounts to receive when performing swaps.
Resolution: The team has not yet addressed this issue.

---

Finding #3 - WhalesCandy - Informational

Description: The following variables are not declared constant, but cannot be updated.

_setterDev, dayliAvailableToken, feePerWeek, maxTotlFee, oneDay, oneWeek, weiPerSfor1perDay

Recommendation: These variables can be declared constant for additional gas savings on each reference.
Resolution: The team has not yet addressed this issue.

---

Finding #4 - WhalesCandy - Informational

Description: The settingDone variable is declared, but never used.
Recommendation: This variable can be removed for gas savings upon deployment and during function calls.
Resolution: The team has not yet addressed this issue.

Contract Overview

• Tokens cannot be withdrawn from the contract once staked.
• As the contracts are implemented with Solidity v0.8.x, they are safe from any possible overflows/underflows.

• Users can stake their WC tokens into the contract at any time. A separate Stake is created each time a user deposits.
• A buy tax is taken on any token purchase by a non-exempt address.
• Instead of buying from the liquidity pool to stake, A user can supply BNB and execute a "buy and stake" to pay a "discounted buy fee" and a platform tax instead of the standard buy tax.
• When a buy and stake is executed, the supplied BNB minus the discounted buy fee is swapped for WC tokens which are then burned. An artificial stake is then created with the WC value multiplied by the platform tax factor.
• The discounted buy fee is transferred to the Dev address.
• Once the contract's "off days" have passed from the launch time, users can participate in daily token auctions by supplying BNB.
• A user is entitled to a share of the daily 2 million tokens auctioned based on their share of the total BNB donated for that day.
• A Dev auction fee is taken from supplied BNB; the remainder is used for "daily updates".
• A user can claim their share once the day has passed, which creates a new artificial stake on their behalf.
• When claiming earned auction tokens, the user's referral address is granted an additional 5% of the earned tokens which can be claimed one day after the first possible claim day of the auction.
• When claiming, the user can specify any referral address that has generated a referral code, including their own address.
• When a referrer claims their earned referral rewards for a day, a stake is created on their behalf. Referral stakes are not charged any claiming fees.
• A user can create a referral code for themselves at any time if they have not already created one.
• Stakes earn 1% of their stake amount each day, up to a maximum of 200% at 200 days.
• When claiming standard stake rewards, a user must first pay a claim fee in the form of the contract's fee token which is transferred to the Fee Token Recipient address.
• Stakes created from referral rewards and stakes created with a start time of 0 are exempt from claiming fees.
• Claim fees begin at one week's worth of fees, and increase for each week that the stake has existed, for a maximum of 52 weeks worth of claiming fees.
• Paid fees are subtracted from future claim fees for a given stake.
• If directly claiming, the reward amount is minted to the user in the form of WC tokens.
• A user can alternatively choose to reinvest their rewards, where an artificial stake is created of the reward amount.
• Reinvesting additionally mints an extra 5% of the reward amount to the Dev address and creates a referral claim of 5% of the reward amount on behalf of the user's referrer, if one exists.
• Referral rewards can be claimed one day after the current day, where a new referral stake is created with no claiming fees.
• Any address can perform a daily update if it has not been executed that day and at least 1000 wei of BNB exists in the contract.
• Upon updating, 15,000 tokens are first minted to the Dev address.
• Any ETH in the contract is then paired with minted tokens and added as liquidity.
• If the contract has over 1000 wei of LP tokens after a daily update occurs, a buy back occurs.
• This redeems a buy back percentage of the contract's LP balance and uses the resulting ETH to purchase WC tokens.
• The contract's resulting WC balance is subsequently burned.
• A daily update is automatically triggered any time a user enters a daily auction, claims auction rewards, claims referral rewards, or reinvests staking rewards.
• The Dev address can update the fee token address at any time.
• The Dev address can update the Dev and Fee Token Recipient addresses at any time.
• The Dev address can update the Auction fee and discounted buy fee to up to 30% each.
• The Dev address can update the buy back percentage to up to 100% at any time.
• The Dev address can update the platform tax factor to any amount between 20% and 500% at any time.
• The Dev address can update the buy tax to up to 80% at any time.
• The Dev address can exclude any address from buy taxes at any time.
• The Dev address can update the Launch Time to any value in the future at any time.
• The Dev address can update the number of off days to any period at any time.

Audit Results

Inheritance Chart

Function Graph

Functions Overview

 ($) = payable function
 # = non-constant function
 
 Int = Internal
 Ext = External
 Pub = Public

 + [Int] IERC20 
    - [Ext] transfer #
    - [Ext] approve #
    - [Ext] transferFrom #
    - [Ext] totalSupply
    - [Ext] balanceOf
    - [Ext] allowance
    - [Ext] burn #

 + [Lib] SafeMath 
    - [Int] add
    - [Int] sub
    - [Int] sub
    - [Int] mul
    - [Int] div
    - [Int] div
    - [Int] mod
    - [Int] mod

 + [Int] IPancakeRouter01 
    - [Ext] factory
    - [Ext] WETH
    - [Ext] addLiquidity #
    - [Ext] addLiquidityETH ($)
    - [Ext] removeLiquidity #
    - [Ext] removeLiquidityETH #
    - [Ext] removeLiquidityWithPermit #
    - [Ext] removeLiquidityETHWithPermit #
    - [Ext] swapExactTokensForTokens #
    - [Ext] swapTokensForExactTokens #
    - [Ext] swapExactETHForTokens ($)
    - [Ext] swapTokensForExactETH #
    - [Ext] swapExactTokensForETH #
    - [Ext] swapETHForExactTokens ($)
    - [Ext] quote
    - [Ext] getAmountOut
    - [Ext] getAmountIn
    - [Ext] getAmountsOut
    - [Ext] getAmountsIn

 + [Int] IPancakeRouter02 (IPancakeRouter01)
    - [Ext] removeLiquidityETHSupportingFeeOnTransferTokens #
    - [Ext] removeLiquidityETHWithPermitSupportingFeeOnTransferTokens #
    - [Ext] swapExactTokensForTokensSupportingFeeOnTransferTokens #
    - [Ext] swapExactETHForTokensSupportingFeeOnTransferTokens ($)
    - [Ext] swapExactTokensForETHSupportingFeeOnTransferTokens #

 + [Int] IPancakeFactory 
    - [Ext] getPair

 +  WhalesCandy 
    - [Pub]  #
    - [Ext] totalSupply
    - [Ext] balanceOf
    - [Ext] allowance
    - [Pub] approve #
    - [Ext] increaseAllowance #
    - [Ext] decreaseAllowance #
    - [Ext] setDevs #
       - modifiers: onlyDev
    - [Ext] setSettingDone #
       - modifiers: onlyDev
    - [Ext] setDevAuctionFee #
       - modifiers: onlyDev
    - [Ext] setDevDiscountedBuyFee #
       - modifiers: onlyDev
    - [Ext] setBuyBackPerecent #
       - modifiers: onlyDev
    - [Ext] setTaxFactor #
       - modifiers: onlyDev
    - [Ext] setPercentToReceive #
       - modifiers: onlyDev
    - [Ext] setExcludedFromTaxReceiver #
       - modifiers: onlyDev
    - [Pub] isExcludedFromTaxReceiver
    - [Int] transferToZero #
    - [Pub] transfer #
    - [Pub] transferFrom #
    - [Int] _transfer #
    - [Int] _mint #
    - [Ext] _devMint #
       - modifiers: onlyDev
    - [Int] _burn #
    - [Ext] createRefCode #
    - [Pub] stake #
    - [Int] stakeInt #
    - [Int] refStake #
    - [Ext] setUsersStakeNumber #
    - [Ext] setOverallStakedToken #
    - [Ext] setAuctionEntry_allDays #
    - [Ext] setStakesUser #
    - [Ext] setStakesRefs #
    - [Ext] setLaunchTime #
       - modifiers: onlyDev
    - [Pub] thisDay
    - [Pub] getAmountFromLiq
    - [Ext] buyAndStake ($)
    - [Pub] updateDaily #
    - [Ext]  ($)
    - [Int] burnAndBuyback #
    - [Ext] setOffDays #
       - modifiers: onlyDev
    - [Ext] buyShareFromAuction ($)
    - [Pub] calculateTokenPerShareOnDay
    - [Ext] claimTokenFromSharesAndStake #
    - [Ext] claimRefTokensAndStake #
    - [Pub] calcReward
    - [Ext] calcClaim
    - [Pub] calcClaimFee
    - [Int] _collect #
    - [Ext] claimRewards #
    - [Ext] reinvest #

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