Quantum Audit Logo

Is Koma Inu a Scam?

Honeypot, rug-pull and ownership checks

Is this your token? Publish your own audit on this page →

Koma Inu KOMA
0xd5ea…3c19
BNB Chain Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The KOMA token contract is an ERC-20 compliant token with custom fee mechanisms, anti-bot features, and an auto-liquidity/marketing function. The contract utilizes the Ownable pattern for administrative control and includes reentrancy protection for its swap operations. Key findings include a high centralization risk due to an immutable marketing receiver, potential for unrecoverable ETH if external calls fail, and significant owner privileges regarding fee exemptions. The overall risk level is assessed as Medium.

1 High2 Medium1 Low1 Informational
i Our automated scanner reviewed Koma Inu (KOMA) on BNB Chain. 5 of 5 security checks passed — see the full breakdown below.
Volume 24h
$261.9K
Liquidity
$2.06M
Price
$0.01332
Age
1y
Top 10 Holders
85.1%

Security Findings

1 High2 Med1 Low1 Info
High

Centralization Risk with Immutable Marketing Receiver

H-01The `marketing_receiver` address is hardcoded in the constructor and cannot be changed after deployment. This address acts as a single point of failure for all collected transaction fees. If this address were to be compromised or become inaccessible, all accumulated funds would be at risk, and the protocol's ability to utilize these funds for marketing or other purposes would be severely hindered. This impacts 7.5 Governance and 7.4 Economic.
IssueThe `marketing_receiver` address is hardcoded in the constructor and cannot be changed after deployment. This address acts as a single point of failure for all collected transaction fees. If this address were to be compromised or become inaccessible, all accumulated funds would be at risk, and the protocol's ability to utilize these funds for marketing or other purposes would be severely hindered. This impacts 7.5 Governance and 7.4 Economic.
FixImplement a function, callable only by the owner, to update the `marketing_receiver` address. Consider using a multi-signature wallet for the `marketing_receiver` to enhance security and decentralization, or a contract that allows for recovery/redirection of funds.
StatusUnresolved
Medium

Unrecoverable ETH on Marketing Receiver Call Failure

M-01In the `swapAndLiquify` function, if the `marketing_receiver.call{value: deltaBalance}("")` operation fails (e.g., due to the receiver being a contract that reverts on receiving ETH, or gas limits), the ETH remains in the KOMA contract. There is no mechanism for the owner or any other party to recover or redirect these stuck funds, leading to potential loss of value. This impacts 7.8 Operations.
IssueIn the `swapAndLiquify` function, if the `marketing_receiver.call{value: deltaBalance}("")` operation fails (e.g., due to the receiver being a contract that reverts on receiving ETH, or gas limits), the ETH remains in the KOMA contract. There is no mechanism for the owner or any other party to recover or redirect these stuck funds, leading to potential loss of value. This impacts 7.8 Operations.
FixImplement a recovery mechanism for stuck ETH. This could be an `onlyOwner` function to sweep any ETH balance from the contract to a designated address, or a more sophisticated retry/fallback mechanism within `swapAndLiquify`.
StatusUnresolved
Medium

Owner's Broad Power to Exempt Fees

M-02The `setisExempt` function allows the contract owner to exempt any address from transaction fees. While intended for legitimate purposes (e.g., exempting router addresses or specific contract interactions), this power is highly centralized. It could be abused to give preferential treatment to certain parties, allowing them to bypass fees for large transfers, potentially impacting the token's economic model and fairness. This impacts 7.3 Access Control and 7.4 Economic.
IssueThe `setisExempt` function allows the contract owner to exempt any address from transaction fees. While intended for legitimate purposes (e.g., exempting router addresses or specific contract interactions), this power is highly centralized. It could be abused to give preferential treatment to certain parties, allowing them to bypass fees for large transfers, potentially impacting the token's economic model and fairness. This impacts 7.3 Access Control and 7.4 Economic.
FixConsider implementing a more granular or time-bound fee exemption mechanism. If broad exemption is necessary, ensure robust off-chain governance and transparency around its usage. Document the intended use cases for fee exemptions clearly.
StatusUnresolved
Low

Hardcoded External Contract Addresses

L-01The PancakeSwap router and factory addresses are hardcoded in the constructor (0x10ED…024E and 0xcA14…0c73). While this is common for single-chain deployments, it makes the contract non-portable to other EVM chains or future versions/upgrades of the router/factory without a complete redeployment. This impacts 7.6 External.
IssueThe PancakeSwap router and factory addresses are hardcoded in the constructor ( and ). While this is common for single-chain deployments, it makes the contract non-portable to other EVM chains or future versions/upgrades of the router/factory without a complete redeployment. This impacts 7.6 External.
FixFor future deployments or multi-chain considerations, consider making these addresses configurable via an `onlyOwner` function or through a constructor parameter that can be set during deployment. For this specific deployment, this is a minor concern given the BSC context.
StatusUnresolved
Info

Initial High Taxes and Short Durations

I-01The contract implements `INITIAL_BUY_TAX` (30%) and `INITIAL_SELL_TAX` (30%) with relatively short durations (`BUY_TAX_DURATION` 15 seconds, `SELL_TAX_DURATION` 30 minutes). While these aggressive tax structures are often intended to deter bots and early price manipulation, they can also deter legitimate early participants and lead to significant price volatility during the initial trading phase. This impacts 7.4 Economic.
IssueThe contract implements `INITIAL_BUY_TAX` (30%) and `INITIAL_SELL_TAX` (30%) with relatively short durations (`BUY_TAX_DURATION` 15 seconds, `SELL_TAX_DURATION` 30 minutes). While these aggressive tax structures are often intended to deter bots and early price manipulation, they can also deter legitimate early participants and lead to significant price volatility during the initial trading phase. This impacts 7.4 Economic.
FixThis is a design choice, but it's important for the project team to be aware of the potential impact on early adoption and market dynamics. Ensure clear communication to the community regarding these initial tax mechanics.
StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract demonstrates good code quality and utilizes Solidity 0.8.18, benefiting from built-in overflow/underflow checks. Reentrancy protection is implemented for the `swapAndLiquify` function using a `lockTheSwap` modifier (7.2 Code Security). However, a technical issue exists where ETH could become unrecoverable if the `marketing_receiver.call` fails (7.8 Operations). Additionally, external contract addresses are hardcoded (7.6 External).

GovernanceMedium5/10

The tokenomics include dynamic buy/sell fees and an initial high tax period, designed to manage early trading behavior (7.4 Economic). A significant centralization risk arises from the hardcoded and immutable `marketing_receiver` address, which receives all collected fees, creating a single point of failure (7.5 Governance). The owner possesses broad privileges, including the ability to exempt any address from fees, which could be misused (7.3 Access Control).

UpgradesLow10/10

The KOMA token contract is not designed with an upgrade mechanism (e.g., proxy pattern). Therefore, there are no upgrade-related risks (7.7 Upgrades). Any changes to the contract logic would require a new deployment.

Security Checklist

5/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedPass
Not a ProxyPass

Holder Composition

85.1% in top 10
69.6% in wallets15.5% in contracts
Effective Concentration75.8%

Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.

Liquidity Depth

$2.26M across 6 pairs
Pancakeswap v2WBNBanalysed$2.06M91.4%Pancakeswap v3WBNB$186.3K8.3%Pancakeswap v2USDT$6.0K0.3%Squadswap v2WBNB$1.2K0.1%UniswapUSDT$8390.0%UniswapUSDT$6380.0%

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

LP Locked71.0% · OnlyMoons Lock
Top-1 Unlocked Holder14.6%

Key Addresses

2 addresses
Deployer
0x0d16…b708
Unlocked LP Held By
0x5036…6a20

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

4 factors
  • Top-10 concentration > 70% (85.1% total → 75.8% effective; 69.6% in EOAs, 15.5% in contracts — extreme)
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit

Each factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed

Related Audits

6 more on the record
LABMedium RiskFLORKMedium RiskThe Final Form Bull (CZ)Medium RiskBaby Asteroid (BABYASTEROID)Medium RiskDecentrawood (DEOD)Medium RiskTest (TST)Medium Risk

Would You Like a More Detailed Audit of Koma Inu?

Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.

Get Detailed Audit