Quantum Audit Logo
Launch App

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

Is Anoma Safe?

XANBNB 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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance3/10Upgrades1/10Checks passed1 of 5Findings1 High · 1 Medium · 1 Low · 2 Info5
SummaryAI Copilot

This audit covers the TokenImplementation contract, which serves as the logic for a BridgeToken deployed via a BeaconProxy on the BSC network.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Complex proxy pattern
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.6%
  • 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 — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 30% (89.6% total → 44.0% effective; 13.6% in EOAs, 76.1% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 99.6% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 97% 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 41 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
76.1%Contracts13.6%Wallets10.4%Everyone else
76.1%Contracts13.6%Wallets10.4%
ContractsWalletsEveryone elseBubble area = share of supply
89.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking76.1%
  • Walletsanonymous holders, free to sell13.6%
  • Everyone elsethe rest of the supply10.4%
Effective concentrationwhat the score reads44.0%
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$506.6K across 6 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$490.4KShare of depth96.8%
Top-1 Unlocked Holder99.6%
Top-3 Unlocked100.0%
Unlocked LP held by
0xf949…02980xf5d2…2397

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

Security Findings

1 High1 Medium1 Low2 Info
High

Centralized Control over Token Supply and Metadata

The owner address has exclusive control over critical functions such as mint(address account_, uint256 amount_), burn(address account_, uint256 amount_), and updateDetails(string memory name_, string memory symbol_, uint64 sequence_). This allows the owner to arbitrarily increase or decrease the token supply, directly impacting its value, and to change the token's identifying metadata (name, symbol). While common for bridge tokens, this represents a significant centralization risk (7.4 Economic, 7.5 Governance).H-01

Issue

The owner address has exclusive control over critical functions such as mint(address account_, uint256 amount_), burn(address account_, uint256 amount_), and updateDetails(string memory name_, string memory symbol_, uint64 sequence_). This allows the owner to arbitrarily increase or decrease the token supply, directly impacting its value, and to change the token's identifying metadata (name, symbol). While common for bridge tokens, this represents a significant centralization risk (7.4 Economic, 7.5 Governance).

Fix

Ensure the owner address () is controlled by a highly secure multi-signature wallet or a robust decentralized autonomous organization (DAO) to mitigate the risk of a single point of failure or compromise. Implement transparent processes for any minting, burning, or metadata update operations.

Status

Unresolved

Medium

Non-Standard transferFrom Logic

The transferFrom function implements the token transfer (_transfer) before checking and reducing the allowance (require(currentAllowance >= amount_) and _approve). While the transaction will revert if the allowance is insufficient, this order deviates from the standard ERC-20 pattern where allowance is typically checked and reduced *before* or as part of the transfer. This can lead to higher gas costs for failed transactions, as the token transfer is attempted even when the allowance is insufficient (7.2 Code Security).M-01

Issue

The transferFrom function implements the token transfer (_transfer) before checking and reducing the allowance (require(currentAllowance >= amount_) and _approve). While the transaction will revert if the allowance is insufficient, this order deviates from the standard ERC-20 pattern where allowance is typically checked and reduced *before* or as part of the transfer. This can lead to higher gas costs for failed transactions, as the token transfer is attempted even when the allowance is insufficient (7.2 Code Security).

Fix

Refactor the transferFrom function to first check and reduce the allowance, and then perform the token transfer. This aligns with common ERC-20 implementations and improves gas efficiency for reverting transactions. For example, adopt the OpenZeppelin _spendAllowance pattern.

Status

Unresolved

Low

EIP-712 Permit Front-Running Risk

The permit function, which allows users to sign approvals off-chain, is inherently susceptible to front-running. If a signed permit message is broadcast publicly (e.g., via a relayer or mempool) before being included in a transaction, a malicious actor could observe the message and submit their own transaction to execute the permit call, potentially causing the original transaction to revert or be exploited (7.2 Code Security). This is a known characteristic of the EIP-2612 standard and not a flaw in this specific implementation.L-01

Issue

The permit function, which allows users to sign approvals off-chain, is inherently susceptible to front-running. If a signed permit message is broadcast publicly (e.g., via a relayer or mempool) before being included in a transaction, a malicious actor could observe the message and submit their own transaction to execute the permit call, potentially causing the original transaction to revert or be exploited (7.2 Code Security). This is a known characteristic of the EIP-2612 standard and not a flaw in this specific implementation.

Fix

Educate users about the front-running risks associated with the permit function. Advise them to use private transaction relays or to be cautious when broadcasting signed messages publicly, especially for high-value transactions.

Status

Unresolved

Info

Custom Ownership Implementation

The contract implements its own ownership logic by storing the owner in _state.owner and using a custom onlyOwner modifier, rather than inheriting from OpenZeppelin's Ownable contract. While functionally similar, using a widely audited and standardized library like OpenZeppelin's Ownable is generally preferred for consistency, reduced risk of subtle bugs, and easier integration with ecosystem tools (7.2 Code Security).I-01

Issue

The contract implements its own ownership logic by storing the owner in _state.owner and using a custom onlyOwner modifier, rather than inheriting from OpenZeppelin's Ownable contract. While functionally similar, using a widely audited and standardized library like OpenZeppelin's Ownable is generally preferred for consistency, reduced risk of subtle bugs, and easier integration with ecosystem tools (7.2 Code Security).

Fix

Consider inheriting from OpenZeppelin's Ownable contract in TokenState or TokenImplementation for a more standardized and battle-tested ownership solution. If a custom implementation is necessary, ensure it has undergone thorough testing and review.

Status

Unresolved

Info

Redundant _initializePermitStateIfNeeded Call in permit

The _initializePermitStateIfNeeded() function is called at the beginning of every permit function invocation. While its internal logic prevents unnecessary state updates if the cached values are current, calling it repeatedly adds a minor, albeit negligible, gas overhead. This function is primarily intended for initial setup or when metadata details are updated (7.2 Code Security).I-02

Issue

The _initializePermitStateIfNeeded() function is called at the beginning of every permit function invocation. While its internal logic prevents unnecessary state updates if the cached values are current, calling it repeatedly adds a minor, albeit negligible, gas overhead. This function is primarily intended for initial setup or when metadata details are updated (7.2 Code Security).

Fix

Consider removing the _initializePermitStateIfNeeded() call from the permit function, as the permit domain separator is typically stable after initialization and metadata updates. The _domainSeparatorV4() function already handles re-computation if block.chainid or address(this) changes, making the explicit call in permit redundant for most cases.

Status

Unresolved

Analysis

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

This audit covers the TokenImplementation contract, which serves as the logic for a BridgeToken deployed via a BeaconProxy on the BSC network. The contract implements standard ERC-20 functionalities, including minting, burning, and EIP-712 permit. The code demonstrates good practices for upgradeability, such as state separation and an initializer. While the technical implementation is largely robust, the centralized control over token supply and metadata by the owner presents a significant governance and economic risk, albeit mitigated by the owner being a contract. A non-standard implementation of transferFrom was noted, along with minor informational findings.

Technical6/10Medium risk

The contract exhibits a strong technical foundation (7.1 Architecture, 7.2 Code Security). It correctly implements ERC-20 standards and integrates EIP-712 permit functionality. State separation via TokenState is well-utilized for proxy compatibility, and arithmetic operations are safe due to Solidity 0.8.0+ checks. Access control (7.3 Access Control) for sensitive functions like mint and burn is properly enforced with an onlyOwner modifier. However, the transferFrom function deviates from standard ERC-20 patterns, performing the token transfer before the allowance check, which can lead to inefficient gas usage for reverting transactions.

Governance3/10High risk

The contract design (7.4 Economic, 7.5 Governance) grants significant centralized control to the owner address. The owner can mint and burn tokens, directly impacting the total supply and potentially the token's value. Additionally, the owner can updateDetails to change the token's name and symbol, which could affect its identity and market perception. This centralization is partially mitigated by the owner being a contract (), suggesting a multi-signature or governance mechanism is in place, which reduces the single point of failure risk.

Upgrades1/10High risk

The contract is designed for upgradeability using the BeaconProxy pattern (7.7 Upgrades). The initializer modifier is correctly implemented to prevent re-initialization of the contract's state after deployment or upgrades. The use of a separate TokenState contract ensures proper storage layout for future upgrades, preventing storage collisions. This architecture provides a robust and secure mechanism for future contract enhancements without requiring redeployment of the proxy.

Final RecommendationWhat to do about this score

It is recommended to review the transferFrom implementation to align with standard ERC-20 practices, ensuring allowance checks and reductions occur before token transfers for improved efficiency and clarity.

While centralized control is inherent to many bridge tokens, ensure the owner contract () is secured by a robust multi-signature wallet or a well-tested decentralized governance mechanism. Users of the permit function should be educated on the inherent front-running risks.

Contract & Record

1 audit on record
TypeBridgeToken
NetworkBNB Chain
Token age10mo
Contract0x7427…a07f
Deployer0x3e03…5936
Proxy Upgrade Controls
Proxy TypeBeacon
ImplementationVerified source
Badge for your website
Anoma 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, 202671High
  2. Aug 11, 202681High

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

Related Audits

6 more on the recordAll audits
PlasmaXPL · BNB Chain71HighMirexMRX · BNB Chain71HighCoinMarketCap 20 Index DTFCMC20 · BNB Chain71HighKGSTBNB Chain71HighPancakeSwap TokenCAKE · BNB Chain72HighSubsquidSQD · BNB Chain72High

Would You Like a More Detailed Audit of Anoma?

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