Quantum Audit Logo
Launch App

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

Is AKE Safe?

BNB Chain
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 · 2 audits on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance1/10Upgrades7/10Checks passed3 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The AKEToken contract implements a standard ERC20 token with custom transfer restrictions managed by a 'transfer controller' role.

Read the full analysis
What raised the score
  • Ownership not renounced — strong Multisig
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Volume/Liquidity > 15×
  • LP top1 unlocked holder = 77.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • 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

Security Checklist

as of audit · Sep 43 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
26.5%Contracts22.7%Wallets50.8%Everyone else
26.5%Contracts22.7%Wallets50.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
49.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking26.5%
  • Walletsanonymous holders, free to sell22.7%
  • Everyone elsethe rest of the supply50.8%
Effective concentrationwhat the score reads33.3%
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$2.05M across 8 pairs
Show 2 more pairs

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$2.00MShare of depth97.5%
Top-1 Unlocked Holder77.0%
Top-3 Unlocked100.0%
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.

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control Over Token Transfers

The _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).H-01

Issue

The _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).

Fix

It 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.

Status

Unresolved

Medium

Irreversible Transfer Mode Change to NORMAL

The 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).M-01

Issue

The 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).

Fix

Ensure 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.

Status

Unresolved

Low

Initial Restricted Transfer Mode

Upon 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).L-01

Issue

Upon 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).

Fix

Clearly 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.

Status

Unresolved

Info

Interface Mismatch for isTransferController

The 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).I-01

Issue

The 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).

Fix

Update 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.

Status

Unresolved

Analysis

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

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.

Technical8/10Low risk

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).

Governance1/10High risk

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).

Upgrades7/10Low risk

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.

Final RecommendationWhat to do about this score

To enhance the security and decentralization of the AKEToken, it is recommended to carefully manage the _transferController role.

Consider assigning this critical role to a robust multi-signature wallet or a decentralized autonomous organization (DAO) to mitigate the risk of a single point of failure. Additionally, ensure clear communication to users regarding the initial transfer restrictions and the irreversible nature of setting the transfer mode to 'NORMAL'.

Contract & Record

2 audits on record
TypeAKEToken
NetworkBNB Chain
Token age11mo
Contract0x2c3a…f7db
Deployer0x6468…eac2
Badge for your website
AKE 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, 202652Medium
  2. Jul 27, 202648Medium
  3. Jul 26, 202664Medium

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

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

6 more on the recordAll audits
ChainOpera AICOAI · BNB Chain52MediumYooldo GamesESPORTS · BNB Chain52MediumSIXSEVEN67 · BNB Chain52MediumOPENBNB Chain52MediumKamirai$KAMIRAI · BNB Chain52MediumBaby AnsemBABYANSEM · BNB Chain51Medium

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 Is this your token? Publish your own audit on this page