Quantum Audit Logo

Is ACEToken Safe?

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

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

ACEToken ACE
0xc27a…def4
BNB Chain Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

1 High1 Medium1 Low1 Informational
Volume 24h
$1.7900
Liquidity
$18.2500
Price
$0.1845
Token Age
2y
Top 10 Holders
89.1%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control of Token Supply by Bridge

H-01The `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).
IssueThe `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).
FixWhile 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.
StatusUnresolved
Medium

Dependency on External Bridge Contract Security

M-01The `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).
IssueThe `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).
FixThe `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.
StatusUnresolved
Low

Standard ERC-20 Front-Running Risks

L-01The `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).
IssueThe `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).
FixUsers 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.
StatusUnresolved
Info

Immutability of Bridge Address

I-01The `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).
IssueThe `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).
FixEnsure 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.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

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

GovernanceHigh1/10

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

UpgradesHigh3/10

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

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

89.1% in top 10
89.1% in wallets0.0% in contracts
Effective Concentration89.1%

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

$18.2500

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
0x2ba7…e3fc
Unlocked LP Held By
0x7a98…4bc0

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

What Raised This Score

10 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

Related Audits

6 more on the record
Bless Token (BLESS)Critical RiskWebKey DAO 2.0 (WKEYDAO2)Critical RiskPieverse Token (PIEVERSE)Critical RiskSnapCoinCritical RiskTesla, Inc. (TSLAB)Critical RiskSK Hynix (SKHYB)Critical Risk

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