Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is Kekius Maximus Safe?

KEKIUSEthereum
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
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical7/10Governance7/10Upgrades9/10Checks passed5 of 5Findings1 Critical · 1 High · 3 Medium · 1 Low · 1 Info7
SummaryAI Copilot

The Kekius Maximus (KEKIUS) token contract implements a standard ERC-20 interface with additional features for dynamic transaction taxes, anti-bot measures, and automatic liquidity management.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 3 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (45.0% total → 40.9% effective; 38.2% in EOAs, 6.8% in contracts — moderate)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 3 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

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
6.8%Contracts38.2%Wallets55.0%Everyone else
6.8%38.2%Wallets55.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
45.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking6.8%
  • Walletsanonymous holders, free to sell38.2%
  • Everyone elsethe rest of the supply55.0%
Effective concentrationwhat the score reads40.9%
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$945.5K across 4 pairs

The risk score reads depth across every pair.

LP tokensLocked

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

Analysed pool$938.2KShare of depth99.2%
LP Burned96.5% · ≈ permanent lock
LP Locked96.5% · Null Address
Unlocked LP held by
0x1d1c…1bfd0x2515…fbc00xd1bb…69930xb3ac…68a00x826f…1e650xf947…aa630x0000…8a900x1f2f…f387

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

Security Findings

1 Critical1 High3 Medium1 Low1 Info
Critical

Honeypot / Rug Pull Potential due to Excessive Owner Control

The contract owner has extensive and unilateral control over critical economic parameters, including _initialBuyTax, _initialSellTax, _finalBuyTax, _finalSellTax, _reduceBuyTaxAt, _reduceSellTaxAt, _preventSwapBefore, _maxTxAmount, _maxWalletSize, _taxSwapThreshold, _maxTaxSwap, and the bots mapping. This allows the owner to set extremely high taxes (up to 21% initially), block transfers for specific addresses, prevent selling for a period (_preventSwapBefore), or exclude specific addresses from fees. This combination of controls can be configured to trap user funds, prevent selling for non-owner addresses, or drain liquidity, creating a high risk of a rug pull or…C-01

Issue

The contract owner has extensive and unilateral control over critical economic parameters, including _initialBuyTax, _initialSellTax, _finalBuyTax, _finalSellTax, _reduceBuyTaxAt, _reduceSellTaxAt, _preventSwapBefore, _maxTxAmount, _maxWalletSize, _taxSwapThreshold, _maxTaxSwap, and the bots mapping. This allows the owner to set extremely high taxes (up to 21% initially), block transfers for specific addresses, prevent selling for a period (_preventSwapBefore), or exclude specific addresses from fees. This combination of controls can be configured to trap user funds, prevent selling for non-owner addresses, or drain liquidity, creating a high risk of a rug pull or…

Fix

Implement a decentralized governance mechanism (e.g., DAO) or a multi-signature wallet for critical parameter changes. Consider time-locking significant parameter adjustments to provide transparency and allow users to react. Reduce the owner's ability to arbitrarily block transfers or prevent selling. Clearly document the intended behavior of all dynamic parameters and their limits.

Status

Unresolved

High

High Centralization of Power

Numerous critical functions are protected by the onlyOwner modifier, granting the deployer address absolute control over the token's economic model and operational flow. This includes the ability to enable/disable trading, set taxes, modify transaction and wallet limits, and manage the bots and _isExcludedFromFee mappings. This high degree of centralization introduces a single point of failure and a significant trust requirement from users, as the owner can unilaterally make decisions that drastically impact token holders.H-01

Issue

Numerous critical functions are protected by the onlyOwner modifier, granting the deployer address absolute control over the token's economic model and operational flow. This includes the ability to enable/disable trading, set taxes, modify transaction and wallet limits, and manage the bots and _isExcludedFromFee mappings. This high degree of centralization introduces a single point of failure and a significant trust requirement from users, as the owner can unilaterally make decisions that drastically impact token holders.

Fix

Explore options to decentralize control over sensitive functions. This could involve implementing a multi-signature wallet for critical operations, introducing a time-lock for parameter changes, or transitioning to a community-governed model where token holders vote on significant protocol adjustments.

Status

Unresolved

Medium

_preventSwapBefore Mechanism Can Trap Funds

The _preventSwapBefore variable, controlled by the owner, dictates the minimum _buyCount before the swapAndLiquify function can execute. If set to a high value, this mechanism can effectively prevent the contract from processing accumulated taxes or adding liquidity to the pool for an extended period. This could lead to a build-up of tokens in the contract, delay liquidity provision, and potentially prevent users from selling their tokens if the swap mechanism is crucial for market stability or tax processing.M-01

Issue

The _preventSwapBefore variable, controlled by the owner, dictates the minimum _buyCount before the swapAndLiquify function can execute. If set to a high value, this mechanism can effectively prevent the contract from processing accumulated taxes or adding liquidity to the pool for an extended period. This could lead to a build-up of tokens in the contract, delay liquidity provision, and potentially prevent users from selling their tokens if the swap mechanism is crucial for market stability or tax processing.

Fix

Re-evaluate the necessity and implications of _preventSwapBefore. If retained, consider setting a reasonable upper bound for this variable or implementing a time-based lock instead of a _buyCount based one. Ensure clear communication to users about this mechanism and its potential impact on trading.

Status

Unresolved

Medium

Anti-Bot/Anti-Whale Mechanisms Bypass Potential

While the bots mapping, _maxTxAmount, and _maxWalletSize are intended to prevent malicious actors and large holders, sophisticated attackers may find ways to bypass these restrictions. For example, using multiple wallets to circumvent wallet size limits or employing complex contract interactions to bypass transaction limits. Furthermore, the owner's ability to add/remove bots and exclude addresses from fees can be misused to selectively apply these restrictions, creating an unfair playing field.M-02

Issue

While the bots mapping, _maxTxAmount, and _maxWalletSize are intended to prevent malicious actors and large holders, sophisticated attackers may find ways to bypass these restrictions. For example, using multiple wallets to circumvent wallet size limits or employing complex contract interactions to bypass transaction limits. Furthermore, the owner's ability to add/remove bots and exclude addresses from fees can be misused to selectively apply these restrictions, creating an unfair playing field.

Fix

Acknowledge that anti-bot/anti-whale measures are often imperfect and can be bypassed. Focus on making the token's core economics robust rather than relying solely on these mechanisms. If retained, ensure the owner's control over these features is transparent and subject to checks, such as time-locks or multi-signature approvals.

Status

Unresolved

Medium

renounceOwnership Implications for Dynamic Tokenomics

The renounceOwnership function is present, allowing the owner to transfer ownership to the zero address. However, given the contract's highly dynamic tax system, anti-bot measures, and liquidity management, renouncing ownership would render many critical functions inaccessible. This would effectively 'brick' the contract's ability to adapt to market conditions, adjust taxes, or manage liquidity, potentially leading to an unmanageable or broken state for the token.M-03

Issue

The renounceOwnership function is present, allowing the owner to transfer ownership to the zero address. However, given the contract's highly dynamic tax system, anti-bot measures, and liquidity management, renouncing ownership would render many critical functions inaccessible. This would effectively 'brick' the contract's ability to adapt to market conditions, adjust taxes, or manage liquidity, potentially leading to an unmanageable or broken state for the token.

Fix

If the intention is for the contract to be immutable after deployment, ensure all dynamic parameters are set to their final, desired values before renouncing ownership. Alternatively, remove the renounceOwnership function if continuous owner intervention is expected for the token's operation. If renouncing ownership is desired, consider a phased approach or a transfer of ownership to a community-controlled multi-sig or DAO.

Status

Unresolved

Low

Hardcoded Tax Wallet in Constructor

The _taxWallet address is hardcoded in the constructor (`_taxWallet = payable(0xa86D…002B);). While there is a setTaxWallet` function to change it later, an incorrect or compromised address initially hardcoded could lead to misdirection of funds before the setTaxWallet function is called.L-01

Issue

The _taxWallet address is hardcoded in the constructor (`_taxWallet = payable();). While there is a setTaxWallet` function to change it later, an incorrect or compromised address initially hardcoded could lead to misdirection of funds before the setTaxWallet function is called.

Fix

Consider passing the _taxWallet address as a constructor argument to ensure it is explicitly set at deployment. This reduces the risk of an incorrect hardcoded value and improves deployment flexibility.

Status

Unresolved

Info

Unnecessary SafeMath Library Usage

The contract uses the SafeMath library for arithmetic operations (e.g., add, sub, mul, div). However, the contract is compiled with Solidity version 0.8.23, which natively includes checked arithmetic, meaning integer overflow and underflow will automatically revert. Therefore, the SafeMath library is redundant and adds unnecessary bytecode and gas cost without providing additional security benefits in this Solidity version.I-01

Issue

The contract uses the SafeMath library for arithmetic operations (e.g., add, sub, mul, div). However, the contract is compiled with Solidity version 0.8.23, which natively includes checked arithmetic, meaning integer overflow and underflow will automatically revert. Therefore, the SafeMath library is redundant and adds unnecessary bytecode and gas cost without providing additional security benefits in this Solidity version.

Fix

Remove the SafeMath library and its usage. Rely on Solidity's native checked arithmetic for uint256 operations. This will reduce contract size and slightly optimize gas costs.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The Kekius Maximus (KEKIUS) token contract implements a standard ERC-20 interface with additional features for dynamic transaction taxes, anti-bot measures, and automatic liquidity management. The contract utilizes the Ownable pattern, granting significant control to the deployer over critical economic parameters. While some security patterns like reentrancy guards are present, the extensive owner privileges introduce substantial centralization and potential for malicious manipulation, leading to a high overall risk level.

Technical7/10Low risk

The contract demonstrates a solid foundation with standard ERC-20 implementation and the use of SafeMath for arithmetic operations, although SafeMath is redundant in Solidity 0.8.23. A reentrancy guard (lockTheSwap modifier) is correctly applied to the swapAndLiquify function (7.2 Code Security). However, the contract's logic for dynamic taxes and anti-bot mechanisms introduces complexity that could lead to unintended behavior or be exploited (7.1 Architecture). The _preventSwapBefore mechanism can temporarily halt critical swap operations, impacting liquidity flow.

Governance7/10Low risk

The contract exhibits a high degree of centralization, with the owner possessing extensive control over critical economic parameters (7.4 Economic). The owner can adjust buy/sell taxes, set transaction and wallet size limits, enable/disable trading, and exclude addresses from fees or mark them as bots (7.3 Access Control). This level of control, combined with mechanisms like _preventSwapBefore and dynamic tax reduction based on _buyCount, creates a significant potential for a rug pull or honeypot scenario, where the owner could manipulate conditions to their advantage (7.5 Governance). The renounceOwnership function, if called, would render these critical functions inaccessible, potentially bricking the contract.

Upgrades9/10Low risk

The contract is not designed to be upgradeable, as it does not implement any proxy patterns (7.7 Upgrades). This eliminates upgrade-related risks but means any discovered vulnerabilities or desired feature changes would require a new contract deployment and token migration.

Final RecommendationWhat to do about this score

It is strongly recommended to significantly decentralize control over critical economic parameters to mitigate the high centralization risk.

Consider implementing a multi-signature wallet for sensitive operations or time-locked contracts for parameter changes. Thoroughly review the dynamic tax and anti-bot logic to ensure it cannot be manipulated to create unfair trading conditions or trap user funds. If the intention is for the contract to be immutable, ensure all parameters are set irrevocably at deployment or through a transparent, community-governed process.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkEthereum
Token age1y
Contract0x26e5…7dd9
Deployer0xaa4f…1a7c
Badge for your website
Kekius Maximus security record badge

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
  1. Aug 1, 202624Low

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

Frequently Asked Questions

What is the KEKIUS contract address?

The Kekius Maximus (KEKIUS) contract on Ethereum is 0x26e550ac11b26f78a04489d5f20f24e3559f7dd9. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Kekius Maximus a scam?

Quantum Audit's risk score for Kekius Maximus is 24/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is KEKIUS liquidity locked?

Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $945.5K.

Who holds KEKIUS?

As of Sep 4, 2026, the 10 largest holders own 45.0% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
ClawdEthereum24LowInference Backed Endogenous Financial ReserveINFER · Ethereum24LowFuseEthereum25LowSPECTRE AISPECTRE · Ethereum25LowOGEthereum23LowQairosQRS · Ethereum25Low

Would You Like a More Detailed Audit of Kekius Maximus?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit Is this your token? Publish your own audit on this page