FEG (Feed Every Gorilla)

The SmartBondingCurve contract relies on the external SDDeployerContract(0x00716ee91E94853B1306F6B3331a56207D175CEe) to facilitate ERC20 token creation. Since this external contract is out of the audit’s scope, any vulnerabilities or malicious behavior could directly impact the integrity and security of the audited system.

The ERC20 token contracts deployed through the SmartBondingCurve mechanism are outside the scope of this audit. Any vulnerabilities or non-standard implementations within those tokens could introduce security risks or unexpected behaviors that may affect the overall reliability and trustworthiness of the audited system.

The system interacts with multiple external addresses, including DEADADDRESS, WETHADDRESS, ROUTER, SDDEPLOYERADDRESS, PANCAKE_POSITION_MANAGER, and LP_LOCKER. Since these contracts are outside the scope of the system, any vulnerabilities, misconfigurations, or malicious behavior in these external contracts could directly affect the security, functionality, or integrity of the system.

The swapFee, referralFee, and toOwnerFee parameters can be changed at any time by the boss address. Users interacting with the bonding curve via swapInETH() and swapToETH() may therefore experience different fees between buy and sell operations, potentially leading to unfair or unpredictable outcomes.

The registerReferral() function allows users to assign a referrer, but doing so reduces their effective returns in swaps since referral fees are deducted from the input amount. As users gain no tangible benefit from registering a referrer, the referral mechanism might see limited use, reducing its practical impact within the system.

In both swapInETH() and swapToETH(), users can specify a minimum acceptable output amount (amountOutMin) to protect against unfavorable price movements. However, since this parameter can be set to zero, users who omit or misuse it may receive significantly fewer tokens than expected. Proper use of amountOutMin is essential to avoid unexpected trading outcomes.

The VestingContract inherits from the Ownable abstract contract, which includes the renounceOwnership() function. If called, this function sets the contract owner to the zero address, permanently removing all administrative privileges. While this may be intended to achieve decentralization, it also eliminates the ability to perform future updates, parameter changes, or emergency interventions, reducing flexibility and recovery options.

The functions getFinishAmount(), getAmountIn(), and getAmountOut() provide estimated values based on the current swapFees and toReferr parameters. Since these fees can be changed at any time by the boss address, the values returned by these functions may not match the actual amounts.

The contract includes several hardcoded addresses (e.g., WETHADDRESS, ROUTER, SDDEPLOYERADDRESS, PANCAKE_POSITION_MANAGER, LP_LOCKER) and chain-specific logic in functions such as addLiquidityV3(), which checks for chainId 56 (Binance Smart Chain). As a result, the contract is tightly coupled to BSC and will not function correctly on other chains without redeployment and reconfiguration of these addresses and chain-dependent logic.

When a trading stage is finalized via finalizeTrade(), the contract deploys collected tokens and WETH into liquidity pools using addLiquidityV2() and addLiquidityV3(). In V2, liquidity tokens are sent to the DEADADDRESS, and in V3, positions are locked in LP_LOCKER for up to 10 years. While this mechanism secures user funds and prevents token creators from performing rug pulls, it also permanently restricts control over the liquidity. The contract or its owner cannot recover or adjust these tokens in case of unexpected issues, bugs, or changes in the ecosystem, limiting flexibility and contingency options even after trade completion.

Token creators receive a share of trading fees through the toOwnerToken parameter, which is calculated based on the global swapFees setting. Both parameters can be modified at any time by the boss address, meaning that the rewards distributed to token creators are not fixed and may fluctuate. This flexibility introduces uncertainty regarding the consistency of creator incentives and expected returns over time.