Quantum Audit Logo

Is Kekius Maximus Safe?

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

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

Kekius Maximus KEKIUS
0x26e5…7dd9
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive 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. 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.

1 Critical1 High3 Medium1 Low1 Informational
Volume 24h
$52.5K
Liquidity
$938.2K
Price
$0.006948
Token Age
1y
Top 10 Holders
45.0%

Security Findings

1 Crit1 High3 Med1 Low1 Info
Critical

Honeypot / Rug Pull Potential due to Excessive Owner Control

C-01The 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…
IssueThe 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…
FixImplement 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.
StatusUnresolved
High

High Centralization of Power

H-01Numerous 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.
IssueNumerous 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.
FixExplore 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.
StatusUnresolved
Medium

`_preventSwapBefore` Mechanism Can Trap Funds

M-01The `_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.
IssueThe `_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.
FixRe-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.
StatusUnresolved
Medium

Anti-Bot/Anti-Whale Mechanisms Bypass Potential

M-02While 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.
IssueWhile 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.
FixAcknowledge 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.
StatusUnresolved
Medium

`renounceOwnership` Implications for Dynamic Tokenomics

M-03The `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.
IssueThe `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.
FixIf 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.
StatusUnresolved
Low

Hardcoded Tax Wallet in Constructor

L-01The `_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.
IssueThe `_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.
FixConsider 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.
StatusUnresolved
Info

Unnecessary SafeMath Library Usage

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

Category Ratings

TechnicalLow7/10

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.

GovernanceLow7/10

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.

UpgradesLow9/10

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.

Security Checklist

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

Holder Composition

45.0% in top 10
38.2% in wallets6.8% in contracts
Effective Concentration40.9%

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

$945.5K across 4 pairs
Uniswap v2WETHanalysed$938.2K99.2%Uniswap v3WETH$5.1K0.5%Uniswap v4ETH$1.5K0.2%Uniswap v4TrumpBucks$6770.1%

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 Burned96.5% · ≈ permanent lock
LP Locked96.5% · Null Address

Key Addresses

9 addresses
Deployer
0xaa4f…1a7c
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.

What Raised This Score

5 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

Related Audits

6 more on the record
ClawdMedium RiskShiba Inu (SHIB)Medium RiskGrand Theft Auto VI (GTAVI)Medium RiskUnipeg (UPEG)Medium RiskMog Coin (MOG)Medium RiskWrapped TAO (WTAO)Medium Risk

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