Quantum Audit Logo

Is Animecoin Safe?

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

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

Animecoin ANIME
0x4dc2…c277
Ethereum Not verifiedLast checked 2d ago 1 audit on record
Executive SummaryAI Copilot

The Animecoin contract is an ERC20Permit token with owner-controlled functionality for registering the token on an Arbitrum L2 gateway. The audit identified a high-severity issue regarding potential trapped ETH, a medium-severity issue concerning an unusual view function behavior, and several minor issues. The contract's core ERC20 functionality is robust due to OpenZeppelin inheritance, but specific custom logic introduces notable risks.

1 High1 Medium1 Low1 Informational
Volume 24h
$2.5K
Liquidity
$143.9K
Price
$0.002767
Token Age
1y
Top 10 Holders
95.2%

Security Findings

High

Missing ETH Withdrawal Mechanism for Owner

H-01The `registerTokenOnL2` function is payable and forwards `valueForGateway` and `valueForRouter` to external Arbitrum gateway contracts. If the `msg.value` sent to `registerTokenOnL2` by the owner exceeds the sum of `valueForGateway` and `valueForRouter`, the excess ETH will remain in the `Animecoin` contract. There is no owner-controlled function to withdraw this trapped ETH, leading to a permanent loss of funds for the owner.
IssueThe `registerTokenOnL2` function is payable and forwards `valueForGateway` and `valueForRouter` to external Arbitrum gateway contracts. If the `msg.value` sent to `registerTokenOnL2` by the owner exceeds the sum of `valueForGateway` and `valueForRouter`, the excess ETH will remain in the `Animecoin` contract. There is no owner-controlled function to withdraw this trapped ETH, leading to a permanent loss of funds for the owner.
FixImplement a dedicated `withdrawETH` function, restricted to the `onlyOwner` role, allowing the owner to recover any excess ETH sent to the contract. This function should transfer the contract's balance to a specified address.
StatusUnresolved
Medium

Unusual `isArbitrumEnabled` View Function Behavior

M-01The `isArbitrumEnabled` view function is guarded by `require(shouldRegisterGateway, "NOT_EXPECTED_CALL")`. The `shouldRegisterGateway` flag is only set to `true` temporarily during the execution of the `registerTokenOnL2` function. This means that `isArbitrumEnabled()` will almost always revert when called directly or by external systems outside of the specific L2 registration process, which is unexpected for a public view function and could cause integration issues or confusion.
IssueThe `isArbitrumEnabled` view function is guarded by `require(shouldRegisterGateway, "NOT_EXPECTED_CALL")`. The `shouldRegisterGateway` flag is only set to `true` temporarily during the execution of the `registerTokenOnL2` function. This means that `isArbitrumEnabled()` will almost always revert when called directly or by external systems outside of the specific L2 registration process, which is unexpected for a public view function and could cause integration issues or confusion.
FixRe-evaluate the necessity of the `shouldRegisterGateway` check within `isArbitrumEnabled`. If the intent is to only allow this function to be called during registration, this design is highly restrictive. Consider removing the `require` statement to allow the function to always return its intended value, or provide clear documentation on its intended usage and limitations.
StatusUnresolved
Low

Reliance on External Arbitrum Bridge Parameters

L-01The `registerTokenOnL2` function requires the owner to provide several complex parameters (`maxSubmissionCostForCustomGateway`, `maxSubmissionCostForRouter`, `maxGasForCustomGateway`, `maxGasForRouter`, `gasPriceBid`, `valueForGateway`, `valueForRouter`) for the Arbitrum bridge calls. Incorrectly calculated or provided values for these parameters could lead to failed L2 registration transactions, wasted gas, or trapped funds if `value` is too high and not fully consumed (as noted in H-01). This places a significant operational burden on the owner.
IssueThe `registerTokenOnL2` function requires the owner to provide several complex parameters (`maxSubmissionCostForCustomGateway`, `maxSubmissionCostForRouter`, `maxGasForCustomGateway`, `maxGasForRouter`, `gasPriceBid`, `valueForGateway`, `valueForRouter`) for the Arbitrum bridge calls. Incorrectly calculated or provided values for these parameters could lead to failed L2 registration transactions, wasted gas, or trapped funds if `value` is too high and not fully consumed (as noted in H-01). This places a significant operational burden on the owner.
FixProvide comprehensive documentation and clear guidelines for the owner on how to correctly calculate and provide these Arbitrum-specific parameters. Consider adding sanity checks within the contract, if feasible, to validate parameter ranges or relationships, although this might be complex given the dynamic nature of gas prices and submission costs.
StatusUnresolved
Info

Hardcoded Arbitrum Enabled Return Value

I-01The `isArbitrumEnabled` function returns `uint8(0xb1)`. While `0xb1` is a specific and known constant used by Arbitrum for custom tokens, its direct hardcoding as a magic number without an explicit constant definition or comment can reduce code readability and maintainability. Future changes to Arbitrum's protocol might require updating this value, which would be less clear without a named constant.
IssueThe `isArbitrumEnabled` function returns `uint8(0xb1)`. While `0xb1` is a specific and known constant used by Arbitrum for custom tokens, its direct hardcoding as a magic number without an explicit constant definition or comment can reduce code readability and maintainability. Future changes to Arbitrum's protocol might require updating this value, which would be less clear without a named constant.
FixDefine `0xb1` as a named constant (e.g., `uint8 public constant ARBITRUM_ENABLED_VALUE = 0xb1;`) and use this constant in the `isArbitrumEnabled` function. This improves readability and makes the code easier to understand and maintain.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract utilizes standard OpenZeppelin ERC20Permit and Ownable implementations, providing a solid foundation for token functionality (7.2 Code Security). The architecture integrates with Arbitrum L1/L2 gateways for token registration, demonstrating a clear purpose (7.1 Architecture). However, a high-severity issue was identified where excess ETH sent during the `registerTokenOnL2` call can become permanently trapped in the contract due to a missing withdrawal mechanism (7.4 Economic, 7.8 Operations). Additionally, the `isArbitrumEnabled` view function's restrictive access control (7.3 Access Control) could lead to unexpected reverts for external callers.

GovernanceHigh1/10

The contract employs a simple `Ownable` access control model, granting the deployer exclusive rights to critical functions like `registerTokenOnL2` (7.5 Governance). This centralized control is appropriate for a token registration mechanism. Economically, a significant risk exists where the owner could inadvertently trap ETH in the contract if they overpay for L2 registration (7.4 Economic), as there is no mechanism to recover these funds. The reliance on the owner to correctly provide complex parameters for external bridge calls also introduces operational risk (7.8 Operations).

UpgradesMedium6/10

The Animecoin contract is not designed with an upgradeability pattern (7.7 Upgrades). This means its logic is immutable once deployed, eliminating risks associated with proxy implementation, upgradeability proxies, or beacon proxies. Any future changes would require a new contract deployment and migration of assets.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

10.9% in wallets84.3% in contracts
Effective Concentration44.7%

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

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

Deployer
0xf915…e8f3
Unlocked LP Held By
0x68ed…e4a0

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

What Raised This Score

  • Ownership NOT renounced — owner is an EOA (single private key)
  • Top-10 concentration > 30% (95.2% total → 44.7% effective; 10.9% in EOAs, 84.3% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 87% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 87% 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

Tether Gold (XAUT)High RiskMatrix (MTX)High RiskCentrifuge (CFG)High RiskToken Prometeus Network (PROM)High RiskFake World Assets (FWA)High RiskPrismHigh Risk

Would You Like a More Detailed Audit of Animecoin?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit