Quantum Audit Logo

Is Keeta Safe?

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

Keeta KTA
0xc063…8973
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

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.

1 High2 Low2 Informational
Volume 24h
$280.2K
Liquidity
$4.13M
Price
$0.07163
Token Age
1y
Top 10 Holders
67.5%

Security Findings

1 High2 Low2 Info
High

Centralization Risk: All Initial LP Tokens Transferred to Single Recipient

H-01In 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.
IssueIn 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.
FixClearly 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.
StatusUnresolved
Low

Restrictive `receive` Function

L-01The `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.
IssueThe `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.
FixEvaluate 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.
StatusUnresolved
Low

Hardcoded Slippage Limit in Liquidity Provision

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

Misleading Event Name for LP Token Transfer

I-01The `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.
IssueThe `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.
FixRename the event to accurately reflect the action, for example, `LPTokensTransferred` or `LPTokensSentToTaxRecipient`, to avoid misinterpretation.
StatusUnresolved
Info

Time-Based Tax Reduction Using `block.number`

I-02The 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.
IssueThe 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.
FixFor 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.
StatusUnresolved

Category Ratings

TechnicalLow9/10

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.

GovernanceMedium5/10

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.

UpgradesLow9/10

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.

Security Checklist

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

Holder Composition

67.5% in top 10
24.1% in wallets43.3% in contracts
Effective Concentration41.5%

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

$4.27M across 16 pairs
AerodromeWETHanalysed$4.13M96.6%Uniswap v3WETH$70.8K1.7%AerodromeWETH$52.9K1.2%AerodromeMAMO$14.9K0.3%Uniswap v4USDC$2.9K0.1%Hydrex CLAMMWETH$2.4K0.1%
Show 4 more pairsShow less
AerodromeAERO$8290.0%Uniswap v4ETH$7910.0%Uniswap v3USDC$6210.0%Uniswap v4HASH$960.0%

The 6 remaining pairs hold $83 between them and are not listed.

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

Top-1 Unlocked Holder70.3%
Top-3 Unlocked90.0%

Key Addresses

11 addresses
Deployer
0xac97…d05b
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.

What Raised This Score

6 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

Related Audits

6 more on the record
Apple Inc. (AAPLC)Low RiskvAPI Network (VAPI)Low RiskSAIRILow RiskEdelLow RiskBario Entertainment System (BAES)Low RiskCoinbase Wrapped Hyperliquid (CBHYPE)Low Risk

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