BearishPods

Smart Contract Audit Report

Audit Summary

COMB Financial is building a new platform that allows users to add liquidity to Uniswap and stake their earned LP tokens in a MasterChef.

For this audit, we reviewed the following contracts on the Fantom Mainnet:

• BearishPods contract at 0xb15e6bb7f16396465c23c3aa954acdd8957a69f3.
• PodsSettings contract at 0xce10702d79a736d8dd18a5fafb684d8f5dd8d712.
• PodsHelper contract at 0xe5de965bf9fa7e0c7f5cb20b415e6734244f27ea.
• PodsManager and PodsWallet contracts at 0xab7940de34d26bf4ec4b6c590ac5cf2f322b1578#code.
• ScreamPodDepositor contract at 0x3806d97536f076517b756664250d379d1d895107.
• BooPodDepositor contract at 0x9f1f18ff34c97e475a4f04b1f9c6b08b3c27bacc.
• BtcPodLiquidator contract at 0x90b181cc4ccc485ed13dd0a7244439984ad9999b.
• EthPodLiquidator contract at 0x9ed284a5f92405cb83fc237cbd9c12b5e272962f.
• FtmPodLiquidator contract at 0x38d3c3353ae464d2a086ab30669ed5fd7203add4.

Audit Findings

Please ensure trust in the team prior to investing as they have substantial control in the ecosystem.
Date: May 4th, 2022.
Updated: May 9th, 2022 to reflect the Mainnet contracts.

Contracts Overview

• As the contracts are implemented with Solidity v0.8.11, they are safe from any possible overflows/underflows.

BearishPods Contract:

• This contract facilitates the minting of BearishPods NFTs.
• The maximum supply of BearishPods NFTs is 300.
• The maximum number of BearishPods that one wallet can own is 15.
• In the event that the address receiving a BearishPods NFT is a contract, the contract must have implemented the onERC721Received() function in order to successfully receive the NFT.
• Every BearishPods NFT has an associated royalty percentage and receiver.
• This contract complies with the ERC-721 standard.
• As this contract is acting through a proxy, the implementation code can be upgraded at any time.
• The Minter can mint any number of NFTs up to the maximum supply to any address at any time.
• The Admin can update the royalty receiver and percentage at any time.
• The Admin can update the URI for any BearishPods NFT to any value at any time.
• The Admin can update the maximum supply to any value at any time.

PodsManager Contract:

• This contract is used to mint BearishPods NFTs for $COMB tokens.
• BearishPods available for minting have been supplied by the Owner; they each have an associated Pod with a type, cost, fee, and depositor.
• The Pod type is one of ETH, BTC, or FTM.
• A fee is taken on all mints and sent to the depositor address associated with that Pod.
• When a user mints a BearishPod NFT, a Pod Wallet is created and the $COMB remaining after the fee is taken is sent to that address.
• While the whitelisting is enabled, only addresses on the whitelist can mint tokens.
• This contract and the created Pod Wallet contract have associated settings that are managed by a podsSettings contract.
• As this contract is acting through a proxy, the implementation code can be upgraded at any time.
• The Owner can update the podsSettings address to any address at any time.
• The Owner can add BearishPods to be minted at any time.
• The Owner can update the whitelist at any time.
• The Owner can enable or disable whitelisting at any time.

PodWallet Contract:

• This contract is used to manage a MasterChef by harvesting and locking assets.
• Users can perform a harvest on the MasterChef at any time.
• Harvested assets are immediately locked using a VotingEscrow contract.
• The VotingEscrow contract is out of the scope of this audit, so we are unable to provide an assessment in regards to that contract's security.
• As this contract is acting through a proxy, the implementation code can be upgraded at any time.
• The Owner of the contract and any users on a whitelist specified by the pods settings can act as an Admin.
• The Admin can transfer their earned tokens from the wallet contract to any address at any time.
• The Admin can lock any amount of tokens for any duration at any time.
• The Admin has the ability to withdraw any token or any amount of ETH from the contract; this is intended to be a "rescue" for random tokens or ETH stuck in the contract.

BooPodDepositor and ScreamPodDepositor Contracts:

• These contracts are used to add liquidity to a Uniswap pool and deposit the earned LP tokens into a MasterChef.
• The BooPodDepositor contract is associated with a $BOO token and $WFTM pair, the ScreamPodDepositor is associated with a $SCREAM token and $WFTM pair.
• Users can deposit $COMB tokens which are then swapped to $WFTM and added as liquidity to the pair.
• When a liquidity add is performed, half of the $WFTM in the contract is swapped for either $BOO or $SCREAM tokens which are then paired with the other half and added as liquidity.
• A team fee is taken on all deposits and transferred to a wallet controlled by the team.
• The team fee amount is specified by the pod settings.
• Users can remove their liquidity at any time, in which case the $BOO or $SCREAM tokens are swapped for $COMB tokens and sent to the user.
• As this contract is acting through a proxy, the implementation code can be upgraded at any time.
• The Owner has the ability to withdraw any token or any amount of ETH from the contract; this is intended to be a "rescue" for random tokens or ETH stuck in the contract.

PodsHelper Contract:

• This contract is used with a Pod Wallet and FeeDistributor contract to manage funds staked in a MasterChef.
• The FeeDistributor contract is out of the scope of this audit, so we are unable to provide an assessment in regards to that contract's security.
• Users who own a BearPod NFT can harvest or pull out of a MasterChef contract that their Pod Wallet has staked LP tokens in.
• As this contract is acting through a proxy, the implementation code can be upgraded at any time.

PodsSettings Contract:

• This contract manages the settings associated with pod wallets, pod depositors, and pod liquidators.
• The Owner can update the whitelist of addresses able to manage wallets at any time.
• The Owner can update the Voting Escrow contract used by wallets to lock tokens to any address at any time.
• The Owner can update the team wallet address to any address at any time.
• The Owner can update the address receiving liquidation from the pod liquidators to any address at any time.
• The Owner can update the team fee to any value under 2% at any time.
• The Owner can update the deposit fee to any value under 6% at any time.
• The Owner can update the liquidation fee to any value under 4.5% at any time.

BtcPodLiquidator, EthPodLiquidator, and FtmPodLiquidator Contracts:

• These contracts facilitate the swapping of tokens for BTC, ETH, and FTM respectively.
• The tokens supported for swapping are SpookyToken ($BOO), SpiritSwap Token ($SPIRIT), Comb Finance ($COMB), Scream ($SCREAM), and BeethovenxToken ($BEETS).
• A single liquidate will swap all supported tokens present in the contract at once.
• A fee is taken on the total BTC, ETH, or FTM received and sent to an address specified in the pod settings.
• The remaining balance is sent to an address specified by the user.

Audit Results

Contract Source Summary and Visualizations

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