Quantum Audit Logo
Launch App

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

Is Keeta Safe?

KTABase
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
Technical9/10Governance5/10Upgrades9/10Checks passed4 of 5Findings1 High · 2 Low · 2 Info5
SummaryAI Copilot

The audited contract implements an ERC20 token with a dynamic, time-decaying tax mechanism and integrates with Aerodrome for liquidity provision.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 70.3%
  • LP top3 unlocked holders = 90.0%
  • 1 High finding(s) from audit
  • 2 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (67.5% total → 41.5% effective; 24.1% in EOAs, 43.3% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 70.3% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • LP top3 unlocked holders = 90.0% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • 1 High finding(s) from audit
  • 2 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 44 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
43.3%Contracts24.1%Wallets32.5%Everyone else
43.3%Contracts24.1%Wallets32.5%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
67.5%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking43.3%
  • Walletsanonymous holders, free to sell24.1%
  • Everyone elsethe rest of the supply32.5%
Effective concentrationwhat the score reads41.5%
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$4.27M across 16 pairs
Show 4 more pairs

The 6 remaining pairs hold $83 between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$4.13MShare of depth96.6%
Top-1 Unlocked Holder70.3%
Top-3 Unlocked90.0%
Unlocked LP held by
0x5234…3f790xabf3…34dd0x37aa…698f0x3a2a…f6e00xab01…ef0b0x4150…97c50x32c9…83260xee2f…9f090x4c81…4cfe0x33ab…21fa

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

Security Findings

1 High2 Low2 Info
High

Centralization Risk: All Initial LP Tokens Transferred to Single Recipient

In the createLiquidityPool function, after successfully adding liquidity to Aerodrome, all generated LP tokens (lpBalance) are transferred to the _taxRecipient address via IERC20(liquidityPool).safeTransfer(_taxRecipient, lpBalance). This design choice means that the _taxRecipient gains sole control over the initial liquidity pool, including the ability to remove liquidity. This concentrates significant power in a single address, which could be a point of failure or an unexpected outcome for the project deployer if they intended to hold or manage the LP tokens themselves. This impacts 7.1 Architecture, 7.3 Access Control, and 7.4 Economic.H-01

Issue

In the createLiquidityPool function, after successfully adding liquidity to Aerodrome, all generated LP tokens (lpBalance) are transferred to the _taxRecipient address via IERC20(liquidityPool).safeTransfer(_taxRecipient, lpBalance). This design choice means that the _taxRecipient gains sole control over the initial liquidity pool, including the ability to remove liquidity. This concentrates significant power in a single address, which could be a point of failure or an unexpected outcome for the project deployer if they intended to hold or manage the LP tokens themselves. This impacts 7.1 Architecture, 7.3 Access Control, and 7.4 Economic.

Fix

Clearly document this design choice and its implications. If this is not the intended behavior, modify the createLiquidityPool function to distribute LP tokens to a more decentralized set of addresses (e.g., the deployer, a multisig, or a timelock contract) or to burn a portion. If the _taxRecipient is intended to manage the liquidity, ensure it is a secure, multi-signature wallet or a governance-controlled contract.

Status

Unresolved

Low

Restrictive receive Function

The receive function contains a strict require(msg.sender == _WETH, "Only accept ETH from WETH") check. This prevents the contract from receiving direct ETH transfers from any address other than the WETH contract. While this might be an intentional design to enforce specific interaction patterns, it also means that any accidental ETH sent directly to the contract from other sources would be unrecoverable, and it limits the contract's ability to receive ETH for other purposes in the future. This impacts 7.2 Code Security and 7.8 Operations.L-01

Issue

The receive function contains a strict require(msg.sender == _WETH, "Only accept ETH from WETH") check. This prevents the contract from receiving direct ETH transfers from any address other than the WETH contract. While this might be an intentional design to enforce specific interaction patterns, it also means that any accidental ETH sent directly to the contract from other sources would be unrecoverable, and it limits the contract's ability to receive ETH for other purposes in the future. This impacts 7.2 Code Security and 7.8 Operations.

Fix

Evaluate if this strict restriction is absolutely necessary. If the contract might need to receive ETH from other sources (e.g., for donations, future features, or emergency recovery), consider relaxing this restriction or implementing an onlyOwner function to withdraw accidentally sent ETH. If the restriction is intentional, ensure it is well-documented.

Status

Unresolved

Low

Hardcoded Slippage Limit in Liquidity Provision

The createLiquidityPool function enforces a maxSlippage parameter with a hardcoded range of 1-1000 (0.01% to 10%). While providing a slippage control is good practice, a fixed range might not be optimal for all market conditions or liquidity sizes. In highly volatile markets, even 10% slippage might be exceeded, or for very large liquidity additions, a dynamic or configurable slippage might be more appropriate. This impacts 7.4 Economic.L-02

Issue

The createLiquidityPool function enforces a maxSlippage parameter with a hardcoded range of 1-1000 (0.01% to 10%). While providing a slippage control is good practice, a fixed range might not be optimal for all market conditions or liquidity sizes. In highly volatile markets, even 10% slippage might be exceeded, or for very large liquidity additions, a dynamic or configurable slippage might be more appropriate. This impacts 7.4 Economic.

Fix

Consider making the maxSlippage parameter configurable by the owner or through a governance mechanism, allowing for adjustments based on market conditions or operational needs. Alternatively, ensure the current range is sufficient for all anticipated scenarios.

Status

Unresolved

Info

Misleading Event Name for LP Token Transfer

The createLiquidityPool function emits an event named LPTokensBurned after transferring LP tokens to the _taxRecipient. The term 'burned' typically implies that tokens are sent to an unspendable address (e.g., address(0)), effectively removing them from circulation. In this case, the tokens are merely transferred to another active address. This misleading event name could cause confusion for users or off-chain monitoring systems. This impacts 7.2 Code Security.I-01

Issue

The createLiquidityPool function emits an event named LPTokensBurned after transferring LP tokens to the _taxRecipient. The term 'burned' typically implies that tokens are sent to an unspendable address (e.g., address(0)), effectively removing them from circulation. In this case, the tokens are merely transferred to another active address. This misleading event name could cause confusion for users or off-chain monitoring systems. This impacts 7.2 Code Security.

Fix

Rename the event to accurately reflect the action, for example, LPTokensTransferred or LPTokensSentToTaxRecipient, to avoid misinterpretation.

Status

Unresolved

Info

Time-Based Tax Reduction Using block.number

The tax reduction mechanism in getCurrentTax relies on block.number to determine the passage of time and subsequent tax reductions. While block.number is a common and generally acceptable method for time-based logic in smart contracts, it is susceptible to minor manipulation by miners who can slightly influence block production times. For a gradual tax reduction, this is typically not a severe vulnerability, but it means the exact timing of tax changes can be slightly imprecise or influenced. This impacts 7.4 Economic and 7.2 Code Security.I-02

Issue

The tax reduction mechanism in getCurrentTax relies on block.number to determine the passage of time and subsequent tax reductions. While block.number is a common and generally acceptable method for time-based logic in smart contracts, it is susceptible to minor manipulation by miners who can slightly influence block production times. For a gradual tax reduction, this is typically not a severe vulnerability, but it means the exact timing of tax changes can be slightly imprecise or influenced. This impacts 7.4 Economic and 7.2 Code Security.

Fix

For gradual, non-critical time-based events, block.number is generally acceptable. No immediate action is required, but be aware of this characteristic if precise timing becomes critical for future features.

Status

Unresolved

Analysis

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

The audited contract implements an ERC20 token with a dynamic, time-decaying tax mechanism and integrates with Aerodrome for liquidity provision. It utilizes OpenZeppelin's Ownable, ERC20Permit, ReentrancyGuard, and SafeERC20 libraries, enhancing security. Key functionalities include initial token minting to the contract, a tax applied to transfers, and a function to create and fund an Aerodrome liquidity pool. The primary concern identified is the transfer of all initial LP tokens to a single tax recipient, concentrating control over the pool's liquidity.

Technical9/10Low risk

The contract demonstrates good technical security practices (7.2 Code Security) by inheriting from OpenZeppelin's ReentrancyGuard and SafeERC20, and implementing a robust approve override to prevent front-running. The _update function correctly applies the dynamic tax without introducing reentrancy. However, the receive function (7.2 Code Security, 7.8 Operations) is highly restrictive, only allowing ETH from the WETH contract, which could prevent recovery of accidentally sent ETH or limit future functionality. The event LPTokensBurned (7.2 Code Security) is misleading as LP tokens are transferred, not burned.

Governance5/10Medium risk

The economic model (7.4 Economic) features a dynamic tax that reduces over time, providing a clear mechanism for tokenomics. Slippage control is implemented in createLiquidityPool to protect against unfavorable trades. A significant design choice (7.1 Architecture, 7.3 Access Control) is the transfer of all initial LP tokens to the _taxRecipient, centralizing control over the initial liquidity. While this might be intended, it concentrates power and could pose a single point of failure or unexpected behavior for the deployer. The tax reduction mechanism (7.4 Economic) relies on block.number, which is generally acceptable but can be minimally influenced by miners.

Upgrades9/10Low risk

The contract is not designed with an upgradeable proxy pattern (7.7 Upgrades). Therefore, there are no upgrade-related risks such as proxy initialization issues, storage collisions, or logic contract immutability concerns. Any changes to the contract's logic would require a new deployment.

Final RecommendationWhat to do about this score

It is recommended to carefully review the implications of transferring all initial LP tokens to the _taxRecipient and ensure this aligns with the project's long-term strategy and risk tolerance.

Consider documenting this design choice explicitly. Additionally, evaluate the strictness of the receive function to ensure it does not hinder future operational needs or recovery scenarios. For all external interactions, ensure the addresses for WETH, Router, and Factory are verified and trusted.

Contract & Record

1 audit on record
TypeRouter, Token
NetworkBase
Token age1y
Contract0xc063…8973
Deployer0xac97…d05b
Badge for your website
Keeta 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. Sep 4, 202617Low
  2. Aug 11, 202615Low

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

Frequently Asked Questions

What is the KTA contract address?

The Keeta (KTA) contract on Base is 0xc0634090f2fe6c6d75e61be2b949464abb498973. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Keeta a scam?

Quantum Audit's risk score for Keeta is 17/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: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is KTA liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $4.27M.

Who holds KTA?

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

Related Audits

6 more on the recordAll audits
Apple Inc.AAPLC · Base17LowvAPI NetworkVAPI · Base17LowSAIRIBase18LowEdelBase16LowBario Entertainment SystemBAES · Base16LowCoinbase Wrapped HyperliquidCBHYPE · Base18Low

Would You Like a More Detailed Audit of Keeta?

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