Discovery Trending Launches KYC Verified Watchlist Risk Alerts
Token Minter AI Threat Detection Token Burner
Blog & News Docs Visit SolidProof.io

Kimcoin Info

kimcoin.cash

KIMCOIN ($KIM) is a luxury-inspired meme token built on Binance Smart Chain. It combines viral community mechanics, instant on-chain referral rewards, and presale-only reflections to give early supporters the best advantage.

Kimcoin Logo
Onboarded date 21/08/2025

TrustNet Score

The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.

9.23
Poor Excellent

Real-Time Threat Detection

Real-time threat detection, powered by Cyvers.io, is currently not activated for this project.

This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks. For more information, click here.

Security Assessments

"Static Analysis Dynamic Analysis Symbolic Execution SWC Check Manual Review"
Contract address
0x3618...8F60
Network
BNB Smart Chain - Mainnet
License N/A
Compiler N/A
Type N/A
Language Solidity
Onboard date 2025/08/21
Revision date 2025/08/21

Summary and Final Words

No crucial issues found

The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.

Contract owner cannot mint

It is not possible to mint new tokens.

Contract owner cannot blacklist addresses.

It is not possible to lock user funds by blacklisting addresses.

Contract owner cannot set high fees

The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.

Contract cannot be locked

Owner cannot lock any user funds.

Token cannot be burned

There is no burning within the contract without any allowances

Ownership is not renounced

The owner retains significant control, which could potentially be used to modify key contract parameters.

Contract is not upgradeable

The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.

Scope of Work

This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.

The auditing process consists of the following systematic steps:

  1. Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
  2. Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
  3. Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
  4. Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
  5. Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
  6. Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
  7. Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.

A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.

Final Words

The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.

Ownership Privileges
  • The owner can enable trading only once.
  • The owner can set any arbitrary value in the airdrop minimum amount.
  • The owner can set the airdrop configurations.
  • The owner can set the sale configurations.
  • The owner can claim the stuck ETH.
  • The owner can claim the tokens from the contract.
  • The owner can set the liquidity pool address.
  • The owner can whitelist addresses.

Note - This Audit report consists of a security analysis of the Kimcoin smart contract. This analysis did not include functional testing (or unit testing) of the contract’s logic. Moreover, we only audited one token contract for the Kimcoin team. Other contracts associated with the project were not audited by our team. We recommend investors do their own research before investing.

Files and details

Functions
public

/

State variables
public

/

Total lines
of code

/

Capabilities
Hover on items

/

Findings and Audit result

Critical
1
High
4
Medium
Low
Optimization
2
Informational
high Issues | 1 findings

Pending

#1 high Issue
Centralization Risk in exitToken() Allows Owner to Drain All Unclaimed Reflection Rewards
kimcoin.sol
L288-297
Description

The exitToken() function creates a critical vulnerability by allowing the contract owner to withdraw the entire KIM token balance held by the contract. This contract balance includes all accumulated reflection fees which are owed to the token holders. If the owner calls this function, the reward pool is drained to zero. As a result, any subsequent attempts by users to call claimReflection() will fail, as the contract no longer has the funds to pay them. This flaw enables a straightforward "rug pull" of user rewards, fundamentally breaking the token's reflection mechanism.

Comments

To mitigate this vulnerability, the contract should be modified to track the total reflection fees collected and the total fees paid out to users. By introducing two new state variables, totalReflectionFeesCollected and totalReflectionFeesPaid, the contract can maintain a real-time ledger of its obligations. The _applyReflectionOnTransfer function should be updated to increment the collected fees, and the claimReflection function should increment the paid fees upon a successful claim. Consequently, the exitToken function must be rewritten to only allow the owner to withdraw the contract's surplus balance, which is calculated as the total contract balance minus the outstanding unclaimed reflections (totalReflectionFeesCollected - totalReflectionFeesPaid). This change ring-fences the reflection rewards, ensuring they remain in the contract and available for holders to claim, thereby preventing the owner from draining these essential funds.

medium Issues | 4 findings

Pending

#1 medium Issue
Transfer of tokens without enabling trade.
Kimcoin.sol
L187
Description

The trading needs to be enabled by the owner in order for regular users to transfer tokens. On the contrary, the owner can authorize addresses manually and those addresses will be able to trade tokens. This functionality can be exploited in the following way, For example, there is a presale and the wallets used for the presale can be authorized by the owner. All the tokens obtained can be consolidated into a final wallet address and facilitate trading and selling of the acquired tokens, the last wallet address can be authorized.

Pending

#2 medium Issue
Lack of Input Validation in setAirdropMinAmount.
kimcoin.sol
L300
Description

The setAirdropMinAmount(uint256 amount) function allows the owner to change the minimum BNB required to claim an airdrop. However, it does not validate the amount parameter. An owner could set this value to an unreasonably high number (e.g., 1,000,000 ether). This would cause the require(msg.value >= airdropMinAmount) check in the claimAirDrop function to fail for all legitimate users, effectively disabling the airdrop functionality at will. This gives the owner a "kill switch" for a core feature of the contract that is not transparent to users.

Comments

To prevent this, you should add a require statement to enforce a reasonable upper limit on the airdropMinAmount. This provides a safeguard against setting an impossible threshold while still giving the owner flexibility to adjust the fee.

Pending

#3 medium Issue
Owner Can Arbitrarily Modify or Reset Live Airdrop and Presale Events
kimcoin.sol
L386-402
Description

The startAirdrop() and startSale() functions can be called by the owner at any time, even while an event is in progress. This allows the owner to unilaterally change critical parameters like start/end blocks, token prices, and supply caps mid-event. Crucially, calling either function also resets the total amount sold or claimed (sTot or aTot) back to zero. This creates a severe trust issue, as the owner could unfairly extend a capped sale, manipulate reflection fee percentages by resetting the sold amount, or disrupt the contract by setting illogical parameters, such as an end block that occurs before the start block.

Comments

To mitigate this, the contract must enforce stricter controls by adding validation checks to both functions. The startAirdrop() and startSale() functions should be modified to prevent them from being called while an event is active, for instance, by requiring that the current block number is past the end block of the previous event. Furthermore, these functions must validate their inputs to ensure parameters are logical—for example, by requiring that the start block is in the future, the end block is after the start block, and that key values like the airdrop amount and sale price are positive. These changes would make event parameters immutable once started, providing participants with the assurance that the rules will not change unexpectedly.

Pending

#4 medium Issue
Incorrect Logic in burn() Function Artificially Preserves User Reflection Claims.
kimcoin.sol
L418-425
Description

The burn(uint256 amount) function contains a critical logic error that allows users to destroy their tokens while unfairly retaining the reflection rewards associated with them. The contract's reflection mechanism requires that when a user's token balance decreases, their magnifiedCorrections value must be increased (+=) to reduce their claim on future rewards. The burn function does the opposite; it incorrectly decreases (-=) the magnifiedCorrections value, which is the logic that should apply when a user receives tokens. This flaw means that a user's claimable reflection balance remains unchanged after burning, allowing them to claim rewards for tokens that no longer exist, effectively draining the reward pool at the expense of other holders.

Comments

To correct this vulnerability, the logic in the burn function must be inverted to match the contract's established pattern for a reduction in balance, as seen in the _applyReflectionOnTransfer function. The incorrect line, magnifiedCorrections[msg.sender] -= int256(magnifiedPerShare * amount);, must be changed to use addition instead of subtraction. The corrected implementation should be magnifiedCorrections[msg.sender] += int256(magnifiedPerShare * amount);. This change ensures that when a user burns tokens, they simultaneously forfeit the accumulated reflection rights tied to those tokens, thereby preserving the integrity of the reward system for all remaining holders.

informational Issues | 2 findings

Pending

#1 informational Issue
Floating pragma solidity version
Kimcoin.sol
L33
Description

Adding the constant version of solidity is recommended, as this prevents the unintentional deployment of a contract with an outdated compiler that contains unresolved bugs.

Pending

#2 informational Issue
Missing visibility
Kimcoin.sol
L100,101
Description

It is recommended to add 'public,' 'private,' or 'internal' visibility during the declaring or initialization of a state variable or a mapping.