ChickenFarm

Smart Contract Audit Report

Audit Summary

{Project Name Here} Audit Report ChickenLand is building a farm-themed defi ecosystem where users receive BNB rewards for staking chickens, feeding them corn, and hatching new eggs.

For this audit, we reviewed ChickenLand's ChickenFarm contract at 0x77834f5e9E6ca66a47da805B24e98ceA422BfA8d on the Binance Smart Chain Testnet.

Audit Findings

Please ensure trust in the team prior to investing as they have substantial control in the ecosystem.
Date: May 6th, 2022.

Finding #1 - ChickenFarm - Informational

Description: decimals, name, referralBonus, and symbol can never be modified but are not declared constant.
Recommendation: These state variables should be declared constant for additional gas savings on each call.

Contract Overview

  • This contract contains the implementation of $BitCORN which supports the ChickenFarm reward system.
  • Upon deployment, the owner receives the initial total supply of 100 Billion [100,000,000,000] $BitCORN.
  • The owner, this contract, Pancakeswap router, and a special receiving "FEEDFEED" address are excluded from fees.
  • Rewards for holders in the ChickenFarm contract are maintained through "chickens" and "eggs".
  • The team may choose to provide bonus rewards for chickens, eggs, and/or BNB to participants by updating the address of the contract responsible for calculating rewards, the "bonus provider"; by default, there are no bonuses rewarded.
  • When users send BNB to the contract to purchase a chicken, 4% of the BNB received is transferred to the team's wallet as a fee.
  • Users can refer another account to receive 5% on top of all their newly acquired chickens; this occurs for as long as the referred user remains unchanged.
  • Users can only have one referred user, and can only change this referred user by adopting new chickens and specifying a new refered user, given that it is not themselves.
  • $BitCORN is purchased directly through this contract.
  • On purchases, users pay a 10% total fee in BNB; 3% is transferred to the team's wallet, and 7% is kept in the contract to maintain BNB liquidity for users selling their eggs.
  • Tokens received from the dex swap are deposited to a fee excluded address and immediately transferred to the recipient.
  • When chickens are fed, $BitCORN is burned based on how much corn a user fed their chickens, reducing both the total supply and the corn held by the user.
  • Everyday, $BitCORN is "harvested" to deposit to the $BitCORN/WBNB token pair; this effectively increases the total supply of $BitCORN.
  • Corn is harvested when a user purchases corn, purchases a chicken, manually hatches eggs, manually sells eggs or approves another user for spending.
  • The initial daily harvest rate is 100 Million $BitCORN per day.
  • Chickens held and fed by users produce eggs that will hatch into new chickens, or be sold for BNB.
  • Whenever new eggs are manually hatched, sold, or a chicken is purchased by a user, new eggs are calculated based on how much time has passed since they last "hatched" eggs as well as how much $BitCORN they hold. All chickens are then immediately fed.
  • Users who hold enough corn to feed all their chickens will receive the maximum amount of new eggs. The maximum amount of new eggs is an 8% increase for every period of 5 minutes that has passed since they last hatched eggs. This reward period cannot be changed.
  • Users cannot yield more than twice a period's rewards, effectively limiting new eggs produced to a 16% increase for every interval of 10 minutes or more since they last hatched eggs, given the user is holding enough corn to feed them.
  • Users who do not hold enough corn to feed their chickens will only receive a portion of the maximum amount of new eggs.
  • "Well fed" eggs are the portion of the maximum eggs they could obtain that could be fed based on the corn they're holding and the corn required. "Hungry eggs" are 25% of the remaining eggs. The new eggs received by this user is the sum of well fed and hungry eggs.
  • New eggs can be manually hatched or sold by users by making a call to the hatchEggs() function or sellEggs() function respectively.
  • When $BitCorn is purchased, chickens are purchased, a user manually hatches or sells eggs, and at the end of any transfer that includes fees, funds are automatically compounded for users.
  • By default, users are included in automatic compounding to be paid out rewards every 3 days.
  • Users can exclude and reinclude themselves in automatic compounding as well as specify their desired payout days. When the auto compounding status is modified for a user, their yielding time is reset.
  • Auto compounding initially is done on 5 chicken holders at a time, although the owner can modify this at any time.
  • If a compound occurs on a payout day for a user, their eggs are sold for BNB.
  • The amount of BNB received per egg cannot exceed the max payout specified by the owner. Initially, this is 10 BNB and it will never be below 5 BNB. The contract maintains the max payout to ensure liquidity for users' eggs.
  • The amount of BNB received per egg is calculated as the maximum amount dependent on the BNB reserves of the contract, based on the constant value of 0.000001 BNB per egg.
  • There is no guarantee that funds will be available for redemption of eggs as BNB funds for eggs come from other users.
  • If the account selling the eggs is in the auto compound list, then the team will take a 5% fee of the BNB the user is receiving, otherwise, it is 4%.
  • When fees are taken during a transfer, $BitCORN held by the contract is swapped for BNB as long as the $BitCORN held is at least 0.5% of the $BitCORN held by the pair.
  • During buys and sells of $BitCORN, the contract receives 10% of the amount of $BitCORN being purchased.
  • In the event BNB is transferred directly to this contract, the funds are used to adopt chickens for the sender.
  • The owner can launch the token once.
  • The owner can set the team's wallet address at any time.
  • The owner can set the daily harvest at any time, as long as it does not reach or exceed 1 Billion $BitCORN.
  • The owner can set the max payout of BNB received by a user selling eggs as long as it exceeds 5 BNB.
  • The owner can set the yield for any period of time since the last hatch as long as it does not exceed 15%.
  • The owner can set toggle auto compounding as well as specify the amount of accounts that are compounded per claim.
  • The owner can exclude anyone from fees at any time.
  • The owner can reassign the bonus provider implementation to another address at any time.
  • The contract utilizes locking modifiers to prevent against reentrancy attacks in applicable functions.
  • This contract implements the BEP-20 standard.
  • As the contracts are implemented with Solidity v0.8.13, they are safe from any possible overflows/underflows.

Audit Results

Vulnerability CategoryNotesResult
Arbitrary Jump/Storage WriteN/APASS
Centralization of ControlN/APASS
Compiler IssuesN/APASS
Delegate Call to Untrusted ContractN/APASS
Dependence on Predictable VariablesN/APASS
Ether/Token TheftN/APASS
Flash LoansN/APASS
Front RunningThe automated _swapContractToken() functionality may be susceptible to front-running; The team must monitor and if suspicious activity is detected, the team must disable this system.PASS
Improper EventsN/APASS
Improper Authorization SchemeN/APASS
Integer Over/UnderflowN/APASS
Logical IssuesN/APASS
Oracle IssuesN/APASS
Outdated Compiler VersionN/APASS
Race ConditionsN/APASS
ReentrancyN/APASS
Signature IssuesN/APASS
Unbounded LoopsN/APASS
Unused CodeN/APASS
Overall Contract Safety PASS

Inheritance Chart

Smart Contract Audit - Inheritance

Function Graph

Smart Contract Audit - Graph

Functions Overview


 ($) = payable function
 # = non-constant function

 Int = Internal
 Ext = External
 Pub = Public

 + [Int] IBEP20 
    - [Ext] totalSupply
    - [Ext] decimals
    - [Ext] symbol
    - [Ext] name
    - [Ext] balanceOf
    - [Ext] transfer #
    - [Ext] allowance
    - [Ext] approve #
    - [Ext] transferFrom #

 + [Int] IPair 
    - [Ext] sync #

 + [Int] IPancakeRouter 
    - [Ext] addLiquidityETH ($)
    - [Ext] swapExactTokensForETHSupportingFeeOnTransferTokens #
    - [Ext] swapExactETHForTokensSupportingFeeOnTransferTokens ($)
    - [Ext] factory
    - [Ext] WETH

 + [Int] IPancakeFactory 
    - [Ext] createPair #

 +  Ownable 
    - [Pub]  #
    - [Pub] owner
    - [Pub] renounceOwnership #
       - modifiers: onlyOwner
    - [Pub] transferOwnership #
       - modifiers: onlyOwner
    - [Int] _transferOwnership #

 + [Lib] EnumerableSet 
    - [Prv] _add #
    - [Prv] _remove #
    - [Prv] _contains
    - [Prv] _length
    - [Prv] _at
    - [Int] add #
    - [Int] remove #
    - [Int] contains
    - [Int] length
    - [Int] at
    - [Int] add #
    - [Int] remove #
    - [Int] contains
    - [Int] length
    - [Int] at
    - [Int] add #
    - [Int] remove #
    - [Int] contains
    - [Int] length
    - [Int] at

 + [Int] IBonusProvider 
    - [Ext] getCornConsumption
    - [Ext] getYield
    - [Ext] getChickensBuy
    - [Ext] getChickensCompound
    - [Ext] getBNBOut

 +  DefaultBonusProvider (IBonusProvider)
    - [Ext] getCornConsumption
    - [Ext] getYield
    - [Ext] getChickensBuy
    - [Ext] getChickensCompound
    - [Ext] getBNBOut

 +  ChickenFarm (Ownable, IBEP20)
    - [Ext] setMarketingWallet #
       - modifiers: onlyOwner
    - [Pub]  #
    - [Prv] _autoCompound #
    - [Ext] _compound #
    - [Ext] setDailyHarvest #
       - modifiers: onlyOwner
    - [Pub] BuyCorn ($)
       - modifiers: lock
    - [Pub] adoptChickens ($)
       - modifiers: lock
    - [Ext] hatchEggs #
       - modifiers: lock
    - [Ext] sellEggs #
       - modifiers: lock
    - [Prv] _hatchEggs #
    - [Prv] _sellEggs #
    - [Prv] _addChickens #
    - [Prv] _feedChickens #
    - [Ext] setMaxPayout #
       - modifiers: onlyOwner
    - [Int] getAmountOut
    - [Pub] getChickensPerETH
    - [Pub] getETHPerEgg
    - [Pub] getEggsOfAccount
    - [Ext] getClaimableEthOfAccount
    - [Prv] _getNewEggs
    - [Ext] ChangeYield #
       - modifiers: onlyOwner
    - [Ext] isAutoCompound
    - [Ext] setMyAutoCompound #
    - [Ext] setAutoCompound #
       - modifiers: onlyOwner
    - [Ext] Launch #
       - modifiers: onlyOwner
    - [Pub] SetLaunchTimestamp #
       - modifiers: onlyOwner
    - [Pub] ExcludeFromFees #
       - modifiers: onlyOwner
    - [Ext] SetBonusProvider #
       - modifiers: onlyOwner
    - [Ext]  ($)
    - [Prv] _transfer #
    - [Prv] _harvestCorn #
    - [Prv] _taxedTransfer #
    - [Prv] _feelessTransfer #
    - [Prv] _buyCorn #
    - [Prv] _swapContractToken #
       - modifiers: lockTheSwap
    - [Prv] _swapTokenForBNB #
    - [Ext] balanceOf
    - [Ext] transfer #
    - [Ext] allowance
    - [Ext] approve #
    - [Prv] _approve #
    - [Ext] transferFrom #
    - [Ext] increaseAllowance #
    - [Ext] decreaseAllowance #


 ($) = payable function
 # = non-constant function
  

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.