Honeypot, rug-pull and ownership checks

Is Koma Inu a Scam?

KOMA

BNB Chain

Not verified

This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →

Last checked Sep 4, 2026 · 1 audit on record

Chart

26/ 100

Low RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical9/10 Governance5/10 Upgrades10/10 Checks passed5 of 5 Findings1 High · 2 Medium · 1 Low · 1 Info5

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.

Read the full analysis

What raised the score

Top-10 concentration > 70%
1 High finding(s) from audit
2 Medium finding(s) from audit
1 Low finding(s) from audit

Exact 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

Our automated scanner reviewed Koma Inu (KOMA) on BNB Chain. 5 of 5 security checks passed — see the full breakdown below.

Security Checklist

as of audit · Sep 45 of 5 checks passed

Contract verifiedVerified

OwnershipRenounced

MintNo mint

Liquidity lockLocked

UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

85.1%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking15.5%
Walletsanonymous holders, free to sell69.6%
Everyone elsethe rest of the supply14.9%

Effective concentrationwhat the score reads75.8%

How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$2.26M across 6 pairs

The risk score reads depth across every pair.

LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$2.06MShare of depth91.4%

LP Locked71.0% · OnlyMoons Lock

Top-1 Unlocked Holder14.6%

Unlocked LP held by

0x5036…6a20

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

Security Findings

1 High2 Medium1 Low1 Info

High

Centralization Risk with Immutable Marketing Receiver

The 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.H-01

Issue

Fix

Implement 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.

Status

Unresolved

Medium

Unrecoverable ETH on Marketing Receiver Call Failure

In 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.M-01

Issue

Fix

Implement 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.

Status

Unresolved

Medium

Owner's Broad Power to Exempt Fees

The 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.M-02

Issue

Fix

Consider 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.

Status

Unresolved

Low

Hardcoded External Contract Addresses

The 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.L-01

Issue

The 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.

Fix

For 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.

Status

Unresolved

Info

Initial High Taxes and Short Durations

The 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.I-01

Issue

Fix

This 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.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

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.

Technical9/10Low risk

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).

Governance5/10Medium risk

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).

Upgrades10/10Low risk

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.

Final RecommendationWhat to do about this score

It is recommended to review and mitigate the identified centralization risks, particularly concerning the marketing_receiver address.

Consider implementing a mechanism to update this address or distribute funds to multiple, more resilient destinations. Additionally, implement a recovery mechanism for ETH that might get stuck in the contract due to failed external calls to the marketing receiver. Carefully consider the implications of broad owner privileges, such as fee exemptions, and ensure robust operational procedures are in place for their use.

Contract & Record

1 audit on record

TypeRouter, Token

NetworkBNB Chain

Token age1y

Contract0xd5ea…3c19

Deployer0x0d16…b708

Badge for your website

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History

Aug 13, 202626Low

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the KOMA contract address?

The Koma Inu (KOMA) contract on BNB Chain is 0xd5eaaac47bd1993d661bc087e15dfb079a7f3c19. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.