Quantum Audit Logo

Is AKE Safe?

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

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

AKE AKE
0x2c3a…f7db
BNB Chain Not verifiedLast checked 2d ago 2 audits on record
Executive SummaryAI Copilot

The AKEToken contract implements a standard ERC20 token with custom transfer restrictions managed by a 'transfer controller' role. The contract utilizes OpenZeppelin's Ownable and ERC20 implementations, contributing to a solid foundation. Key risks include significant centralization of control over token transfers and an initial restricted transfer mode. The owner role is managed by a multisig, which is a strong security practice, but the transfer controller could be a single EOA.

1 High1 Medium1 Low1 Informational
Volume 24h
$45.39M
Liquidity
$2.00M
Price
$0.01348
Token Age
11mo
Top 10 Holders
49.2%

Security Findings

High

Centralized Control Over Token Transfers

H-01The `_transferController` role possesses the ability to set the `_transferMode` to `RESTRICTED` or `CONTROLLED`, effectively halting all token transfers or limiting them to only transfers involving the controller. This grants significant power to a single entity, potentially impacting token liquidity and user asset control. While the `owner` (a multisig) can change the `_transferController`, the controller itself could be an EOA, representing a single point of failure (7.3 Access Control, 7.4 Economic).
IssueThe `_transferController` role possesses the ability to set the `_transferMode` to `RESTRICTED` or `CONTROLLED`, effectively halting all token transfers or limiting them to only transfers involving the controller. This grants significant power to a single entity, potentially impacting token liquidity and user asset control. While the `owner` (a multisig) can change the `_transferController`, the controller itself could be an EOA, representing a single point of failure (7.3 Access Control, 7.4 Economic).
FixIt is strongly recommended to assign the `_transferController` role to a robust multi-signature wallet with a high threshold or a decentralized autonomous organization (DAO). This would distribute control and reduce the risk associated with a single point of failure or compromise. Clearly communicate the capabilities of this role to all token holders.
StatusUnresolved
Medium

Irreversible Transfer Mode Change to NORMAL

M-01The `setTransferMode` function includes a condition `if (_transferMode != TransferMode.NORMAL)` which prevents the transfer mode from being changed once it has been set to `NORMAL`. This means that after transfers are fully enabled, the `_transferController` cannot re-restrict them. While this provides a degree of security for users, it also removes any future flexibility for the project to re-introduce restrictions if unforeseen circumstances arise (7.1 Architecture, 7.8 Operations).
IssueThe `setTransferMode` function includes a condition `if (_transferMode != TransferMode.NORMAL)` which prevents the transfer mode from being changed once it has been set to `NORMAL`. This means that after transfers are fully enabled, the `_transferController` cannot re-restrict them. While this provides a degree of security for users, it also removes any future flexibility for the project to re-introduce restrictions if unforeseen circumstances arise (7.1 Architecture, 7.8 Operations).
FixEnsure this design choice is intentional and aligns with the long-term strategy for the token. If future flexibility to re-introduce restrictions is desired, consider modifying the logic to allow a controlled reversal, perhaps with a timelock, governance vote, or a higher-level access control mechanism.
StatusUnresolved
Low

Initial Restricted Transfer Mode

L-01Upon deployment, the `AKEToken` contract initializes with `_transferMode` set to `CONTROLLED`. This means that token transfers are restricted from the outset, only allowing transfers where either the sender or receiver is the `_transferController`. This might be unexpected for users anticipating a standard, unrestricted ERC20 token (7.4 Economic, 7.8 Operations).
IssueUpon deployment, the `AKEToken` contract initializes with `_transferMode` set to `CONTROLLED`. This means that token transfers are restricted from the outset, only allowing transfers where either the sender or receiver is the `_transferController`. This might be unexpected for users anticipating a standard, unrestricted ERC20 token (7.4 Economic, 7.8 Operations).
FixClearly document the initial transfer restrictions and the process by which the token's transfer mode will transition to `NORMAL`. This transparency will help manage user expectations and prevent confusion regarding token functionality.
StatusUnresolved
Info

Interface Mismatch for `isTransferController`

I-01The `isTransferController` function in the `IFourERC20` interface is declared as `external returns (bool)`, while its implementation in `AKEToken` is `external view returns (bool)`. Although this difference does not cause a runtime error (a `view` function can be called where a non-`view` is expected), it represents an inconsistency between the interface and its concrete implementation (7.1 Architecture).
IssueThe `isTransferController` function in the `IFourERC20` interface is declared as `external returns (bool)`, while its implementation in `AKEToken` is `external view returns (bool)`. Although this difference does not cause a runtime error (a `view` function can be called where a non-`view` is expected), it represents an inconsistency between the interface and its concrete implementation (7.1 Architecture).
FixUpdate the `IFourERC20` interface to include the `view` keyword for the `isTransferController` function to accurately reflect the implementation in `AKEToken`. This ensures better adherence to interface contracts and improves code clarity.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good technical security practices (7.2 Code Security) by inheriting from battle-tested OpenZeppelin contracts (ERC20, Ownable) and using Solidity 0.8+, which includes default overflow/underflow checks. The custom transfer logic in `_update` is correctly implemented to enforce the defined transfer modes. A minor inconsistency was noted in the `IFourERC20` interface regarding the `view` keyword for `isTransferController` (7.1 Architecture).

GovernanceHigh1/10

The contract design introduces significant centralization (7.3 Access Control, 7.4 Economic, 7.5 Governance). The `_transferController` role has the power to restrict or halt all token transfers, which could severely impact token liquidity and user freedom. While the `owner` (a multisig, as per provided info) can change the `_transferController`, the controller itself could be a single EOA, creating a single point of failure. Additionally, the token initializes in a `CONTROLLED` transfer mode, which is a notable restriction from deployment (7.8 Operations).

UpgradesLow7/10

The AKEToken contract is not designed as an upgradeable proxy (7.7 Upgrades). Therefore, there are no upgrade-related risks or considerations for this specific contract. Any changes to its logic would require a new deployment and migration of assets.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

22.7% in wallets26.5% in contracts
Effective Concentration33.3%

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

Show 2 more pairsShow less

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

Key Addresses

Deployer
0x6468…eac2
Unlocked LP Held By
0x71eb…a43d0xef15…60980xd379…60d80xb262…eeed0x7853…3d030xe375…42630x80bc…a5b50xa873…91b90x5ad1…2cb00x8e0a…76c1

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

What Raised This Score

  • Ownership NOT renounced — strong Multisig (4-of-6)
  • Top-10 concentration > 30% (49.2% total → 33.3% effective; 22.7% in EOAs, 26.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Volume/Liquidity > 15× (22.7× — wash-trading signal)
  • LP top1 unlocked holder = 77.0% (independent LP — depth risk, pool = 98% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 98% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 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

Frequently Asked Questions

Is AKE a scam?

Based on automated analysis, AKE scores 64/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.

Is AKE safe to buy?

Our scanner flagged a risk score of 64/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.

Has AKE been audited?

The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.

Related Audits

ChainOpera AI (COAI)High RiskYooldo Games (ESPORTS)High RiskSIXSEVEN (67)High RiskOPENHigh RiskBaby Ansem (BABYANSEM)High RiskEVAAHigh Risk

Would You Like a More Detailed Audit of AKE?

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

Get Detailed Audit