Chef.fun

Smart Contract Audit Report

Executive Summary

Chef.fun is developing a new platform that allows authorized users to generate custom ERC-20 tokens through a set of smart contracts.

This report presents the outcomes of our collaborative engagement with the Chef.fun team, focusing on the comprehensive evaluation of the Chefdotfun, ChefFun, ReferralRegistry, ChefTokenFactory, ChefToken, and ChefFunSplitter contracts.

Our team conducted an initial security assessment from August 12th to August 16th, 2024. On August 19th, our team amended this report to reflect updates made to the contracts by the project team that resolves all findings. On August 29th, our team amended this report to reflect the project's mainnet addresses. Although the ChefFun, ReferralRegistry, ChefToken, and ChefTokenFactory contracts are unverified, we have confirmed that the deployed bytecode matches the bytecode generated from the source code provided for the audit scope.

Audit Scope

* Although the ChefFun, ReferralRegistry, ChefToken, and ChefTokenFactory contracts are unverified, we have confirmed that the deployed bytecode matches the bytecode generated from the source code provided for the audit scope.

Audit Findings

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

function updateDistribution(
...
require(distributionPercs.elyPerc + distributionPercs.projectOwnerPerc
+ distributionPercs.marketingPerc + distributionPercsMem.buybackPerc == FEE_DIVISOR, "Must equal 100%");

require(
distributionPercsMem.elyPerc + distributionPercsMem.projectOwnerPerc
+ distributionPercsMem.marketingPerc + distributionPercsMem.buybackPerc == FEE_DIVISOR, "Must equal 100%");

function updateDistribution(uint24 _ely, uint24 _projectOwner, uint24 _marketing, uint24 _buyback) external onlyOwner {
    require(_ely + _projectOwner + _marketing + _buyback == FEE_DIVISOR, "Must equal 100%");

    distributionPercs.elyPerc = _ely;
    distributionPercs.projectOwnerPerc = _projectOwner;
    distributionPercs.marketingPerc = _marketing;
    distributionPercs.buybackPerc = _buyback;
}

if(canSwap && !swapping && isAMMPair[to] && lastSwapBackBlock + 1 <= block.number) {

dexRouter, lpPair, platformAddress, projectAddress, swapTokensAtAmt

referreeOwedAmount, referreeTotalRaisedAmount, walletReferralAmount

System Overview

Chefdotfun Token

The total supply of the token is set to 100 million $CHEF [100,000,000] and is minted to the deployer. No mint or burn functions are publicly accessible, though the circulating supply can be decreased by sending tokens to the 0x..dead address.

Trading must be enabled by the owner before all transfers can take place on the platform. Only transfers where either the sender or recipient is excluded from fees can occur when trading is disabled. Once trading is enabled, it can never be disabled.

The contract's whitelist is active for five minutes after trading is enabled. During this period, the recipient must be whitelisted for buys, the sender must be whitelisted for sells, and both the sender and recipient must be whitelisted for peer-to-peer transfers. After five minutes have passed, the whitelist is permanently disabled and the contract's public launch block is recorded.

The contract enforces a maximum transaction amount (determined by the owner) which imposes a limit to the number of tokens that can be bought or sold in a single transaction. The contract enforces a maximum wallet amount that prevents a transfer from occurring if the recipient's token balance will exceed the limit number of tokens (determined by the owner) after the transfer occurs.

The contract features a transfer delay that prevents buys or peer-to-peer transfers from occurring if they are attempted within the same block as the user's previous buy or peer-to-peer transfer. Additionally, the recipient address must match the address that initiated the transaction.

The contract features a cool-down mechanism that prevents a sell from occurring if the sender is initiating the sell within the same block as their previous buy or receipt of tokens through a peer-to-peer transfer.

There is a Liquidity fee, Marketing fee, and Dev fee on all buys and sells via Uniswap where neither the sender nor the recipient is excluded from fees.

The contract features a dynamic tax system, which, when enabled, automatically adjusts the total buy/sell fees and maximum transaction/wallet amounts based on the number of blocks elapsed since public trading was enabled. The contract's default tax rates and limits are used for the first 9 blocks. If the number of blocks passed ranges from 10 to 109, the buy and sell fees are reduced by 1% for every 10-block period, starting from an initial rate of 20%. The maximum transaction and wallet amounts are adjusted to a percentage of the total supply based on the elapsed block interval. After 110 blocks have passed, the dynamic tax is permanently disabled, the maximum transaction and wallet amounts are set to 100% of the total supply, and the total buy and sell fee are both set to 5%.

When the dynamic tax is triggered, 80% of the updated total buy and sell fee is allocated to the Marketing fund, and the remaining 20% is allocated to the Dev fund. The Liquidity fund allocation is set to zero.

The tokens collected through fees are stored in the contract address. The tokens are swapped for ETH for the purpose of funding Uniswap liquidity and addresses set by the team when the following conditions are met:

• The threshold number of tokens in the contract (determined by the owner) has been reached.
• The caller is initiating a sell transaction via Uniswap.
• At least 1 block has passed since the previous swap has occurred.

The tokens collected through the Liquidity fee are transferred to the Pair address. The tokens collected through the Dev fee and Marketing fee are swapped for ETH and sent to the team's Dev wallet and Marketing wallet respectively.

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.

• The owner can set the Liquidity fee, Marketing fee, and Dev fee for both the buy and sell fee structures to any percentages as long as the total fee percentage combined does not exceed 10%.
• The owner can exclude and include accounts from fees, the maximum transaction amount, and the maximum wallet amount at any time.
• The owner can set the maximum transaction and maximum wallet amounts to any values greater than or equal to 100,000 tokens at any time.
• The owner can disable the maximum transaction amount and maximum wallet amount restrictions at any time.
• The owner can disable the dynamic tax functionality at any time.
• The owner can enable/disable the cool-down block restriction at any time.
• The owner can update the threshold number of tokens needed to trigger the automatic token swapping functionality to any value between 1,000 and 500,000 at any time.
• The owner can transfer any number of tokens from their own address to any number of addresses in a single transaction at any time.
• The owner can add/remove any address from the contract's whitelist at any time.
• The owner can permanently disable the contract's whitelist functionality before the initial five-minute whitelist period has passed at any time.
• The owner can permanently disable the transfer delay functionality at any time.
• The owner can withdraw any tokens from the contract at any time.
• The owner can set the Marketing address and Dev address to any addresses at any time.
• The Dev address can set the Dev fee to zero and allocate its current percentage to the Marketing fee at any time.

ChefFun

Users can create a new token on the platform by specifying the token's name, symbol, maximum wallet percentage, buy and sell fee percentages, and Router address. If the owner has enabled the verification feature, the user must also provide a valid signature and a unique nonce. This signature must be signed by the verification address set by the owner, ensuring that only authorized users can create tokens. The caller must provide an amount of ETH to cover the contract's fee. The fee value is sent to the team's Fee receiver address. A new token contract is generated through the Factory contract.

If the caller sends more ETH than the required fee, the excess amount is used to automatically purchase tokens in a bundle-buy process. 5% of the ETH used for the bundle-buy is deducted and sent to the Fee receiver address. If a platform buy tax is set, the specified percentage is also deducted and sent to the project's address. The remaining ETH is used to calculate the amount of tokens the caller will receive. This calculation considers the current liquidity and token reserves in this contract. The determined token amount is transferred to the caller. The contract's active liquidity for this token is updated accordingly.

If the accumulated ETH liquidity has reached the threshold set by the owner, the contract's token balance is transferred to the token contract. The accumulated ETH and the full token balance is added as liquidity to the Pair. The token is marked as launched and ownership is renounced.

Users can initiate a buy for any token address before the token has been marked as launched by providing an amount of ETH for the purchase. If the owner has enabled the verification feature, the user must also provide a valid signature and a unique nonce. This signature must be signed by the verification address set by the owner, ensuring that only authorized users can create tokens. The platform fee is deducted from the ETH amount and sent to the Fee receiver address. If a referral address is included, a portion of the fee is allocated to the referrer. Additionally, if the token has a platform-specific buy tax, this amount is also deducted and sent to the project's designated address.

The remaining ETH is used to calculate the number of tokens the user will receive. This calculation considers the current liquidity and token reserves in the contract. The contract checks to ensure that the token amount being purchased does not exceed the maximum wallet limit.

Users can sell tokens for any token address before the token has been marked as launched by specifying a number of tokens and a minimum amount of ETH to receive. If the owner has enabled the verification feature, the user must also provide a valid signature and a unique nonce. This signature must be signed by the verification address set by the owner, ensuring that only authorized users can perform sell transactions. The specified number of tokens are transferred from the caller to the contract. The caller must grant the contract a sufficient allowance for the transaction to successfully occur. The platform fee is deducted from the ETH amount received from the sell and sent to the Fee receiver address. If the user has a registered referrer, a portion of the fee is allocated to the referrer. Additionally, if the token has a platform-specific sell tax, this amount is also deducted and sent to the project's designated address. The remaining ETH is transferred to the user.

Chef Token Factory

Any authorized address can generate a new token by specifying the token's info. A new ChefToken is created and 100% of the total supply is transferred to the ChefFun contract and the ChefFun contract is granted ownership.

The owner can update the Platform address referenced in the contract to any address at any time. The owner can update the authorized status of any address at any time.

Chef Token

The total supply of the token is set to 1 billion and is minted to the factory and subsequently transferred to the ChefFun contract. No mint or burn functions are publicly accessible, though the circulating supply can be decreased by sending tokens to the 0x..dead address.

Trading must be enabled by the owner before all transfers can take place on the platform. Only transfers where either the sender or recipient is fee-exempt or the owner can occur when trading is disabled. Once trading is enabled, it can never be disabled.

There is a fee charged on all buys and sells via Uniswap where neither the sender nor the recipient is excluded from fees.

The tokens collected through fees are stored in the contract address. The tokens are swapped for ETH and split amongst the Platform address and Project address when the following conditions are met:

• The threshold number of tokens in the contract (determined by the owner) has been reached.
• The caller is initiating a sell transaction via Uniswap.
• At least 1 block has passed since the previous swap has occurred.

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.

The token creator (Project address) can update the total Buy fee and Sell fee as long as their original values are not exceeded. The owner can exclude and include accounts from fees at any time. The owner can add liquidity to the Pair address using the contract's full token balance and ETH balance and any additionally supplied during the function call. The LP tokens are subsequently minted to the 0x..dead address.

ChefFun Splitter

Any ETH sent directly to the contract is automatically split amongst the Ely address, Project owner address, and Marketing address based on their assigned percentages. If the remaining ETH in the contract exceeds the contract's minimum swap threshold it is swapped for the Token address set by the owner and the received tokens are sent to the 0x..dead address.

The owner can set the Ely address, Project Owner address, Marketing address, and Token address referenced in the contract to any addresses at any time. The owner can set the distribution percentages for each fund to any values at any time as long as the total percentage equals 100%. The owner can set the minimum swap threshold to any value at any time. The owner can withdraw all of the ETH in the contract at any time.

Vulnerability Analysis

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