Quantum Audit Logo
Launch App

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

Is ACEToken Safe?

ACEBNB 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 · 1 audit on record
Chart
Critical RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades3/10Checks passed2 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The ACEToken contract is a wrapped ERC-20 token built upon OpenZeppelin's battle-tested ERC20 implementation.

Read the full analysis
What raised the score
  • Ownership not renounced
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 70%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $10k
  • LP top1 unlocked holder = 100.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 (admin/mint authority retained)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 70% (89.1% total → 89.1% effective; 89.1% in EOAs, 0.0% in contracts — extreme)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $10k ($18 across 1 pairs — easily drained)
  • 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 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 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
89.1%Wallets10.9%Everyone else
89.1%Wallets10.9%
WalletsEveryone elseBubble area = share of supply
89.1%of supply sits with the top 10 holders
  • Walletsanonymous holders, free to sell89.1%
  • Everyone elsethe rest of the supply10.9%
Effective concentrationwhat the score reads89.1%
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$18.2500

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$18Share of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x7a98…4bc0

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 of Token Supply by Bridge

The WrappedERC20 contract, and thus ACEToken, grants the bridge address exclusive control over mint and burn functions. This centralization means the security of the ACEToken's supply is entirely dependent on the security and integrity of the bridge contract. A compromise of the bridge could lead to arbitrary minting or burning of ACEToken, severely impacting its value and ecosystem (7.3, 7.4).H-01

Issue

The WrappedERC20 contract, and thus ACEToken, grants the bridge address exclusive control over mint and burn functions. This centralization means the security of the ACEToken's supply is entirely dependent on the security and integrity of the bridge contract. A compromise of the bridge could lead to arbitrary minting or burning of ACEToken, severely impacting its value and ecosystem (7.3, 7.4).

Fix

While inherent to wrapped token designs, it's crucial to ensure the bridge contract itself undergoes rigorous security audits and implements robust security measures (e.g., multi-signature, time-locks, circuit breakers). Users should be aware of this centralized control point.

Status

Unresolved

Medium

Dependency on External Bridge Contract Security

The ACEToken contract's functionality, particularly its supply management, is entirely reliant on an external bridge contract whose code was not provided for this audit. The security posture of the ACEToken is therefore directly tied to the security of this external bridge. Any vulnerabilities in the bridge contract could directly impact the integrity and functionality of ACEToken (7.6).M-01

Issue

The ACEToken contract's functionality, particularly its supply management, is entirely reliant on an external bridge contract whose code was not provided for this audit. The security posture of the ACEToken is therefore directly tied to the security of this external bridge. Any vulnerabilities in the bridge contract could directly impact the integrity and functionality of ACEToken (7.6).

Fix

The bridge contract should be thoroughly audited for common vulnerabilities, including reentrancy, access control, and logic errors. Implement robust monitoring and incident response for the bridge.

Status

Unresolved

Low

Standard ERC-20 Front-Running Risks

The approve function in the underlying OpenZeppelin ERC20 contract is susceptible to a known front-running attack vector. If a user approves an amount, and then attempts to decrease that approval, a malicious actor could front-run the decrease transaction, spending the original approved amount before the decrease takes effect. This could lead to the malicious actor spending more than the user intended. While mitigated by increaseAllowance and decreaseAllowance, the base approve function still exists (7.2).L-01

Issue

The approve function in the underlying OpenZeppelin ERC20 contract is susceptible to a known front-running attack vector. If a user approves an amount, and then attempts to decrease that approval, a malicious actor could front-run the decrease transaction, spending the original approved amount before the decrease takes effect. This could lead to the malicious actor spending more than the user intended. While mitigated by increaseAllowance and decreaseAllowance, the base approve function still exists (7.2).

Fix

Users should be advised to use increaseAllowance and decreaseAllowance functions instead of directly calling approve to modify existing allowances, as these functions are not susceptible to this specific front-running attack.

Status

Unresolved

Info

Immutability of Bridge Address

The bridge address is declared as immutable in WrappedERC20.sol and set during construction. This prevents any modification of the bridge address after deployment, which is generally good for security as it removes a potential point of attack for unauthorized changes. However, it also means that if the initially configured bridge address is incorrect or becomes compromised and unrecoverable, there is no on-chain mechanism to update it, potentially rendering the token's mint/burn functionality permanently unusable or controlled by a defunct address (7.8).I-01

Issue

The bridge address is declared as immutable in WrappedERC20.sol and set during construction. This prevents any modification of the bridge address after deployment, which is generally good for security as it removes a potential point of attack for unauthorized changes. However, it also means that if the initially configured bridge address is incorrect or becomes compromised and unrecoverable, there is no on-chain mechanism to update it, potentially rendering the token's mint/burn functionality permanently unusable or controlled by a defunct address (7.8).

Fix

Ensure extreme diligence in verifying the bridge address during deployment. Consider off-chain emergency procedures or a migration plan in case the bridge becomes permanently inoperable.

Status

Unresolved

Analysis

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

The ACEToken contract is a wrapped ERC-20 token built upon OpenZeppelin's battle-tested ERC20 implementation. Its primary function is to allow a designated 'bridge' address to mint and burn tokens, facilitating cross-chain operations. The contract's code is minimal, well-structured, and leverages standard, audited libraries. Key risks identified relate to the centralized control of token supply by the bridge and the inherent dependency on the security of this external bridge contract, which was not part of this audit. Operational diligence during deployment is crucial due to the immutable nature of the bridge address.

Technical4/10Medium risk

The ACEToken contract is a minimal wrapper around WrappedERC20, which extends OpenZeppelin's battle-tested ERC20 implementation (7.1). The custom logic for mint and burn is correctly restricted by an onlyBridge modifier, ensuring only the designated bridge can control token supply (7.3). The use of immutable for the bridge address enhances security by preventing unauthorized changes post-deployment. However, the system's overall technical security is heavily reliant on the external bridge contract, which was not part of this audit (7.6). Standard ERC-20 front-running risks for approve also exist (7.2).

Governance1/10High risk

The economic model of ACEToken is highly centralized, with the bridge address holding exclusive control over the mint and burn functions (7.4). This design is typical for wrapped tokens but introduces a single point of failure; a compromise of the bridge would directly impact the token's supply and value (7.3). There is no explicit on-chain governance mechanism for the token itself (7.5). The immutability of the bridge address, while secure, means no recovery mechanism if the bridge becomes permanently inoperable (7.8).

Upgrades3/10High risk

The ACEToken and WrappedERC20 contracts are not designed with upgradeability patterns (e.g., proxies). They are deployed as immutable implementations. This eliminates risks associated with upgrade mechanisms, such as proxy misconfigurations or logic errors during upgrades. However, it also means that any discovered vulnerabilities or desired feature enhancements would require a new contract deployment and a migration strategy (7.7).

Final RecommendationWhat to do about this score

Prioritize a comprehensive security audit of the external bridge contract that interacts with ACEToken, as its security directly dictates the integrity of the token's supply.

Implement robust operational procedures for the deployment of ACEToken, ensuring the correct and secure bridge address is set, given its immutable nature. Educate users on the use of increaseAllowance and decreaseAllowance to mitigate standard ERC-20 front-running risks.

Contract & Record

1 audit on record
TypeACEToken
NetworkBNB Chain
Token age2y
Contract0xc27a…def4
Deployer0x2ba7…e3fc
Badge for your website
ACEToken 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, 202698Critical
  2. Aug 15, 202692Critical

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

Related Audits

6 more on the recordAll audits
Bless TokenBLESS · BNB Chain97CriticalWebKey DAO 2.0WKEYDAO2 · BNB Chain100CriticalPieverse TokenPIEVERSE · BNB Chain100CriticalSnapCoinBNB Chain100CriticalTesla, Inc. TSLAB · BNB Chain96CriticalSK HynixSKHYB · BNB Chain100Critical

Would You Like a More Detailed Audit of ACEToken?

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