Quantum Audit Logo

Is ACU Safe?

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

ACU ACU
0xc5fe…3f0b
Base Not verifiedLast checked 2d ago 1 audit on record
Executive SummaryAI Copilot

The AcuOFT contract is an Omnichain Fungible Token (OFT) implementation built on LayerZero V2, inheriting from OpenZeppelin's Ownable. It provides standard token functionalities with cross-chain capabilities. The contract is simple, primarily relying on audited base contracts. Key findings include centralized owner control, non-standard token decimals, and the absence of an emergency pause mechanism.

1 High1 Medium1 Low2 Informational
Volume 24h
$37.2K
Liquidity
$201.2K
Price
$0.1384
Token Age
1y
Top 10 Holders
87.7%

Security Findings

High

Centralized Control by Owner/Delegate

H-01The `_delegate` address provided in the constructor becomes both the `Ownable` owner and the LayerZero delegate. This address has significant administrative control over the OFT contract, including setting LayerZero configurations (e.g., trusted remotes, message libraries, etc.) and other `Ownable` functions. While the prefill indicates a multisig is used, this single entity holds substantial power, making it a critical point of control.
IssueThe `_delegate` address provided in the constructor becomes both the `Ownable` owner and the LayerZero delegate. This address has significant administrative control over the OFT contract, including setting LayerZero configurations (e.g., trusted remotes, message libraries, etc.) and other `Ownable` functions. While the prefill indicates a multisig is used, this single entity holds substantial power, making it a critical point of control.
FixEnsure the multisig owner address is secured with the highest level of operational security, including robust key management, multi-factor authentication, and strict governance procedures for executing transactions. Clearly define and communicate the scope of the owner's powers to all stakeholders.
StatusUnresolved
Medium

Non-Standard Decimals

M-01The `decimals()` function is explicitly overridden to return `12`. This deviates from the common ERC-20 standard of 18 decimals. While technically valid, this non-standard precision can lead to misinterpretations, display errors, or incorrect calculations in wallets, exchanges, and other DeFi protocols if they assume 18 decimals by default.
IssueThe `decimals()` function is explicitly overridden to return `12`. This deviates from the common ERC-20 standard of 18 decimals. While technically valid, this non-standard precision can lead to misinterpretations, display errors, or incorrect calculations in wallets, exchanges, and other DeFi protocols if they assume 18 decimals by default.
FixThoroughly document the 12-decimal precision and ensure all integrating systems (frontends, wallets, exchanges, analytics platforms) are aware of and correctly handle this value. Implement clear checks in any off-chain or on-chain integrations to prevent errors due to decimal mismatches.
StatusUnresolved
Low

Lack of Emergency Pause Mechanism

L-01The contract lacks an emergency pause mechanism that could halt token transfers or cross-chain operations. In the event of a critical vulnerability in the LayerZero protocol, a major exploit, or other unforeseen circumstances, the absence of such a mechanism could limit the ability to react quickly and protect user funds from further loss.
IssueThe contract lacks an emergency pause mechanism that could halt token transfers or cross-chain operations. In the event of a critical vulnerability in the LayerZero protocol, a major exploit, or other unforeseen circumstances, the absence of such a mechanism could limit the ability to react quickly and protect user funds from further loss.
FixConsider implementing a `Pausable` mechanism (e.g., from OpenZeppelin) controlled by the multisig owner. This would allow the team to temporarily halt operations in emergencies, providing a crucial safety net. Ensure the pause mechanism has clear activation and deactivation policies.
StatusUnresolved
Info

Reliance on LayerZero Protocol Security

I-01The `AcuOFT` contract is an Omnichain Fungible Token (OFT) and its core functionality, especially cross-chain transfers, is entirely dependent on the security and operational integrity of the LayerZero V2 protocol and its endpoint. Any vulnerabilities, misconfigurations, or operational issues within the LayerZero infrastructure could directly impact the security and functionality of this token.
IssueThe `AcuOFT` contract is an Omnichain Fungible Token (OFT) and its core functionality, especially cross-chain transfers, is entirely dependent on the security and operational integrity of the LayerZero V2 protocol and its endpoint. Any vulnerabilities, misconfigurations, or operational issues within the LayerZero infrastructure could directly impact the security and functionality of this token.
FixMaintain continuous monitoring of the LayerZero protocol for security announcements, upgrades, and potential vulnerabilities. Ensure the LayerZero endpoint address used is the official and most secure one. Implement robust monitoring for cross-chain transactions.
StatusUnresolved
Info

No Explicit `_lzEndpoint` Validation in Constructor

I-02The constructor accepts an `_lzEndpoint` address but does not include explicit validation (e.g., checking if it's a known LayerZero endpoint address or if it implements the `ILayerZeroEndpointV2` interface) before passing it to the `OFT` base constructor. While the `OFT` base contract likely handles interactions, a direct check could enhance robustness against misconfiguration.
IssueThe constructor accepts an `_lzEndpoint` address but does not include explicit validation (e.g., checking if it's a known LayerZero endpoint address or if it implements the `ILayerZeroEndpointV2` interface) before passing it to the `OFT` base constructor. While the `OFT` base contract likely handles interactions, a direct check could enhance robustness against misconfiguration.
FixConsider adding a require statement in the constructor to validate the `_lzEndpoint` address, for example, by checking if it's a non-zero address or if it supports the `ILayerZeroEndpointV2` interface using `IERC165` (if applicable to the endpoint contract).
StatusUnresolved

Category Ratings

TechnicalLow8/10

The AcuOFT contract (7.2 Code Security) is a straightforward implementation of LayerZero's OFT standard, inheriting from well-audited OpenZeppelin Ownable. The code is concise and follows common patterns, reducing the likelihood of direct code-level vulnerabilities. However, the contract overrides the `decimals()` function to return 12 instead of the common 18, which could lead to integration issues if not handled correctly by external systems (7.1 Architecture). Additionally, the contract lacks an emergency pause mechanism (7.8 Operations), which could be beneficial for a cross-chain asset in case of protocol-wide issues.

GovernanceHigh2/10

The contract's access control (7.3 Access Control) is managed by the `Ownable` pattern, with the owner (also the LayerZero delegate) having significant control over LayerZero configurations and other administrative functions. While the owner is a multisig (7.5 Governance), this centralized control point remains a high-impact risk if compromised. The economic model (7.4 Economic) is that of a standard fungible token, with its cross-chain functionality relying entirely on the LayerZero protocol (7.6 External).

UpgradesLow7/10

The AcuOFT contract is not designed as an upgradeable proxy (7.7 Upgrades). Therefore, there are no direct upgrade safety concerns for this specific contract. Any future changes would require a new deployment and migration of assets.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

31.4% in wallets56.4% in contracts
Effective Concentration53.9%

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
0x6c8f…3837
Unlocked LP Held By
0x656d…c4840x5a01…a692

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 — strong Multisig (4-of-7)
  • Top-10 concentration > 50% (87.7% total → 53.9% effective; 31.4% in EOAs, 56.4% in contracts — heavy)
  • 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 = 90% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 90% 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

Venice Token (VVV)High RiskRainbow (RNBW)High RiskHOMEHigh RiskCTRHigh RiskMetronome Synth ETH (MSETH)High RiskOpenUSDT (OUSDT)High Risk

Would You Like a More Detailed Audit of ACU?

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

Get Detailed Audit