Quantum Audit Logo

Is Anoma Safe?

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

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

Anoma XAN
0x7427…a07f
BNB Chain Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

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.

1 High1 Medium1 Low2 Informational
Volume 24h
$586.7K
Liquidity
$490.4K
Price
$0.01311
Token Age
10mo
Top 10 Holders
89.6%

Security Findings

1 High1 Med1 Low2 Info
High

Centralized Control over Token Supply and Metadata

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

Non-Standard `transferFrom` Logic

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

EIP-712 Permit Front-Running Risk

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

Custom Ownership Implementation

I-01The 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).
IssueThe 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).
FixConsider 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.
StatusUnresolved
Info

Redundant `_initializePermitStateIfNeeded` Call in `permit`

I-02The `_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).
IssueThe `_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).
FixConsider 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.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

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.

GovernanceHigh3/10

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.

UpgradesHigh1/10

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.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source

Holder Composition

89.6% in top 10
13.6% in wallets76.1% in contracts
Effective Concentration44.0%

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

$506.6K across 6 pairs
Pancakeswap v3USDTanalysed$490.4K96.8%UniswapUSDT$16.1K3.2%Pancakeswap v3WBNB$880.0%Pancakeswap v2WBNB$20.0%Pancakeswap v2Cake$20.0%Pancakeswap v3WBNB$00.0%

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

Key Addresses

3 addresses
Deployer
0x3e03…5936
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.

What Raised This Score

11 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

Related Audits

6 more on the record
Plasma (XPL)Critical RiskMirex (MRX)Critical RiskCoinMarketCap 20 Index DTF (CMC20)Critical RiskPancakeSwap Token (CAKE)Critical RiskSubsquid (SQD)Critical RiskInfinity Ground AI (AIN)High Risk

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