Kibble Token
Smart Contract Audit Report
Executive Summary
This report presents the outcomes of our collaborative engagement with the Cat Town team, focusing on the comprehensive evaluation of the KibbleToken contract.
Our team conducted an initial security assessment from June 3rd to June 4th, 2024.
Kibble Token is a new ERC-20 token deployed on Base that is an automatic liquidity providing protocol.
Audit Scope
Name |
Source Code |
Visualized |
KibbleToken |
Name |
Address/Source Code |
Visualized |
KibbleToken |
Audit Findings
A Low finding and Informational findings were identified and the team should consider resolving these issues. In addition, minimal centralized aspects are present.
Finding #1 |
KibbleToken |
Low Open |
Finding #1 - KibbleToken
|
||
Description: The setDeveloperAddress() function incorrectly updates the
Risk/Impact: The
Recommendation: The setDeveloperAddress() function should be modified to update the Resolution: The team has not yet addressed this issue. |
||
Finding #2 |
KibbleToken |
InformationalOpen |
Finding #2 - KibbleToken
|
||
Description: In the _transfer() function, the
Recommendation: The |
||
Finding #3 |
KibbleToken |
InformationalOpen |
Finding #3 - KibbleToken
|
||
Description: In the _transfer function, the second require statement below will always cause the transaction to revert if reached, as the 'from' address can never be the owner due to the first condition in the first if-statement below:
Recommendation: The above logic should be modified to fit the project team's intended functionality. |
System Overview
TOKENOMICSThe total supply of the token is set to 1 billion $KIBBLE (1,000,000,000). No mint functions are accessible beyond deployment. No burn functions are accessible though the total supply of the token can be reduced by transferring tokens to the 0x..dead address.
CURRENT TOKEN HOLDERSAt the time of writing this report, there are 1,162 token holders. The current token allocation is as follows:
- 86.03% of the total supply has been sent to an upgradeable token locking contract.
- 3.37% of the total supply belongs to a wallet controlled by the team.
- 1.17% of the total supply is in SushiSwap V2 liquidity.
- Of that liquidity, 99.55% of the LP tokens are locked in an upgradeable token locking contract and will unlock on April 1st, 2025.
- 0.75% of the total supply belongs to the deployer.
- The next five holders own a cumulative 1.35% of the total supply.
The owner has permanently enabled trading in the contract.
The contract enforces a maximum buy amount and maximum sell amount when the limits functionality is enabled, which imposes a limit to the number of tokens that can be bought or sold via an approved Pair address in a single transaction. The contract enforces a maximum wallet amount on buys and peer-to-peer transfers when the limits functionality is enabled, which prevents a transaction from occurring if the recipient's token balance will exceed the limit number of tokens after the transfer occurs.
There is a Liquidity fee, Treasury fee, and Developer fee, on all buys and sells via an approved Pair address where neither the sender nor the recipient is excluded from fees. A separate fee structure can be set by the team to apply different fee percentages depending on whether the transaction is a buy or sell.
The tokens collected through the fees are stored in the contract address. The tokens allocated towards the Liquidity and the Developer funds are swapped for ETH for the purpose of funding Uniswap liquidity and the Developer address when the following conditions are met:
- The automatic liquidity add functionality is enabled.
- The threshold number of tokens in the contract address (determined by the owner) has been reached.
- The contract is not currently performing an automatic liquidity add.
- The caller is not initiating a buy transaction via Uniswap.
- Neither the sender nor the recipient is excluded from fees.
Liquidity adds are automatically performed by selling the tokens collected as fees, pairing the received ETH with the token, and adding it as liquidity to the ETH pair. The LP tokens received through this process are sent to the owner. We recommend the team lock these newly acquired LP tokens.
The tokens collected through the Developer fee are swapped for ETH and sent to the team's Developer wallet. The tokens collected through the Treasury fee are transferred directly from the contract to the Treasury address.
As the contract is deployed with Solidity v0.8.24, it is protected from overflows/underflows. There are no fees associated with transferring tokens. The contract complies with the ERC-20 standard.
OWNERSHIP CONTROLSThe owner can set the Liquidity fee, Treasury fee, and Developer fee to any percentages as long as their total combined fee percentage does not exceed 10% for both buys and sells. The owner can include and exclude accounts from transfer fees at any time.
The owner can set the maximum buy amount and maximum sell amount to any values greater than 1 million tokens at any time. The owner can set the maximum wallet amount to any value greater than 3 million tokens at any time. The owner can permanently disable the above restrictions at any time. The owner can include and exclude accounts from the above restrictions at any time.
The owner can update the threshold number of tokens needed to trigger an automatic liquidity add to any value between 10,000 tokens and 1 million tokens at any time. The owner can add/remove any address from the approved Pair address list at any time. The Pair address created upon deployment may not be removed.
The owner can specify a list of recipient addresses and corresponding token amounts to initiate multiple transfers in a single transaction at any time. The owner can withdraw any tokens or ETH from the contract at any time. The owner can set the Treasury address to any address at any time.
Vulnerability Analysis
Vulnerability Category | Notes | Result |
---|---|---|
Arbitrary Jump/Storage Write | N/A | PASS |
Centralization of Control | The owner can set total fees on buys and sells up to 10% each at any time. | PASS |
Compiler Issues | N/A | PASS |
Delegate Call to Untrusted Contract | N/A | PASS |
Dependence on Predictable Variables | N/A | PASS |
Ether/Token Theft | N/A | PASS |
Flash Loans | N/A | PASS |
Front Running | The automatic token swapping functionality may be susceptible to front-running, although the risk is minimal as swapTokensAtAmount is currently set to a low value (0.05% of the total supply) in relation to the total supply. |
PASS |
Improper Events | N/A | PASS |
Improper Authorization Scheme | N/A | PASS |
Integer Over/Underflow | N/A | PASS |
Logical Issues | The setDeveloperAddress() function incorrectly updates the TreasuryAddress state variable instead of the DevAddress state variable. |
PASS |
Oracle Issues | N/A | PASS |
Outdated Compiler Version | N/A | PASS |
Race Conditions | N/A | PASS |
Reentrancy | N/A | PASS |
Signature Issues | N/A | PASS |
Sybil Attack | N/A | PASS |
Unbounded Loops | N/A | PASS |
Unused Code | N/A | PASS |
Overall Contract Safety | PASS |
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.