Quantum Audit Logo

Is Akita Safe?

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

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

Akita AKITA
0x7def…56be
Ethereum
Not verifiedThis 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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The Akita contract implements a standard ERC20 token with OpenZeppelin's ERC20 and ERC20Permit functionalities. It includes a recovery mechanism for accidentally sent ETH and ERC20 tokens, controlled by a single 'recovery' address. While the core token logic is robust due to OpenZeppelin's battle-tested libraries, the centralized control over recovery functions introduces a significant access control risk.

1 High1 Low1 Informational
Volume 24h
$97.9K
Liquidity
$122.5K
Price
$0.01341
Token Age
6mo
Top 10 Holders
89.9%

Security Findings

1 High1 Low1 Info
High

Centralized Control of Recovery Functions

H-01The `recovery` address has sole control over critical functions: `recoverETH()`, `recoverERC20()`, and `updateRecovery()`. This means a single external owned account (EOA) or a single point of failure controls the ability to withdraw any ETH or ERC20 tokens accidentally sent to the contract, and can also transfer this control to another address. If this `recovery` address is compromised, all funds held by the contract (e.g., from accidental transfers) could be permanently lost or stolen by an attacker (7.3 Access Control, 7.8 Operations).
IssueThe `recovery` address has sole control over critical functions: `recoverETH()`, `recoverERC20()`, and `updateRecovery()`. This means a single external owned account (EOA) or a single point of failure controls the ability to withdraw any ETH or ERC20 tokens accidentally sent to the contract, and can also transfer this control to another address. If this `recovery` address is compromised, all funds held by the contract (e.g., from accidental transfers) could be permanently lost or stolen by an attacker (7.3 Access Control, 7.8 Operations).
FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the `recovery` address. This would require multiple trusted parties to authorize any recovery operation or change to the recovery address, significantly reducing the risk associated with a single point of failure.
StatusUnresolved
Low

Lack of Time-Lock or Delay for Critical Operations

L-01The `updateRecovery()` function allows the `recovery` address to instantly change itself to a new address. While controlled by `onlyRecovery`, an immediate change without a time-lock or delay period could be problematic if the `recovery` address is compromised. An attacker could quickly change the recovery address before the legitimate owner has a chance to react, potentially locking out the original owner from future recovery operations (7.3 Access Control, 7.8 Operations).
IssueThe `updateRecovery()` function allows the `recovery` address to instantly change itself to a new address. While controlled by `onlyRecovery`, an immediate change without a time-lock or delay period could be problematic if the `recovery` address is compromised. An attacker could quickly change the recovery address before the legitimate owner has a chance to react, potentially locking out the original owner from future recovery operations (7.3 Access Control, 7.8 Operations).
FixConsider adding a time-lock mechanism to the `updateRecovery()` function. This would introduce a delay (e.g., 24-72 hours) between initiating a recovery address change and its actual activation, providing a window for detection and intervention in case of a compromised `recovery` key.
StatusUnresolved
Info

Limited Recovery Scope for Non-ERC20 Tokens

I-01The contract includes functions to recover accidentally sent ETH (`recoverETH`) and ERC20 tokens (`recoverERC20`). However, there is no mechanism to recover other types of tokens, such as ERC-721 (NFTs) or ERC-1155 tokens, if they are mistakenly sent to the contract address. Any such tokens would be permanently locked within the contract (7.4 Economic, 7.8 Operations).
IssueThe contract includes functions to recover accidentally sent ETH (`recoverETH`) and ERC20 tokens (`recoverERC20`). However, there is no mechanism to recover other types of tokens, such as ERC-721 (NFTs) or ERC-1155 tokens, if they are mistakenly sent to the contract address. Any such tokens would be permanently locked within the contract (7.4 Economic, 7.8 Operations).
FixAssess the likelihood of non-ERC20 tokens being accidentally sent to the contract. If this is a significant concern, consider implementing additional recovery functions for other token standards (e.g., `recoverERC721`, `recoverERC1155`) or explicitly documenting that such assets are unrecoverable.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The Akita contract demonstrates strong technical foundations by inheriting from battle-tested OpenZeppelin ERC20 and ERC20Permit implementations, ensuring robust token functionality (7.2 Code Security). The recovery functions for ETH and ERC20 tokens are implemented correctly using safe transfer patterns. However, the single `recovery` address controlling these critical functions (7.3 Access Control) introduces a centralized point of failure, posing a technical risk if compromised.

GovernanceHigh1/10

The economic model is straightforward, with a fixed total supply minted to a single receiver at deployment, aligning with standard ERC20 tokenomics (7.4 Economic). There is no formal on-chain governance mechanism (7.5 Governance). The `recovery` address acts as a sole administrator for retrieving accidentally sent assets and can update itself, concentrating significant operational control (7.8 Operations) and presenting a governance risk if not managed securely.

UpgradesMedium6/10

The Akita contract is not designed with an upgradeability pattern (7.7 Upgrades), meaning its logic is immutable once deployed. This eliminates risks associated with proxy implementation bugs or upgrade path vulnerabilities. However, it also means that any discovered vulnerabilities or desired feature enhancements would necessitate a new contract deployment and token migration.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

89.9% in top 10
19.1% in wallets70.8% in contracts
Effective Concentration47.4%

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

$122.5K

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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x1926…7259
Unlocked LP Held By
0x92ba…4b50

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

What Raised This Score

7 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 30% (89.9% total → 47.4% effective; 19.1% in EOAs, 70.8% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • 1 High 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
Worldcoin (WLD)Medium RiskVANRYMedium RiskConvex Token (CVX)Medium RiskDUALMedium RiskAuroraMedium RiskBONE SHIBASWAP (BONE)Medium Risk

Would You Like a More Detailed Audit of Akita?

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

Get Detailed Audit