Quantum Audit Logo

Is XMAQUINA Safe?

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

XMAQUINA DEUS
0x940a…089b
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

This audit covers the provided Solidity interfaces for an Omnichain Fungible Token (OFT) and the abstract Ownable contract. A comprehensive security assessment of the full OFT implementation is not possible as the core logic for token transfers, LayerZero integration, and fee handling was not provided. The existing `Ownable` contract is robust, but its application in a cross-chain context introduces significant centralization risks. The inherent complexity of cross-chain operations necessitates rigorous security practices for the unseen implementation.

1 Critical2 High1 Medium2 Informational
Volume 24h
$37.4K
Liquidity
$716.1K
Price
$0.01851
Token Age
9d
Top 10 Holders
89.6%

Security Findings

1 Crit2 High1 Med2 Info
Critical

Incomplete Audit Scope Due to Missing Implementation

C-01The provided code consists of abstract contracts (`Context`, `Ownable`) and interfaces (`IOFT`, `ILayerZeroReceiver`, `IOAppReceiver`). The core implementation logic for the Omnichain Fungible Token (OFT), including how tokens are minted, burned, transferred across chains via LayerZero, and how fees are handled, is entirely missing. Without this crucial implementation, a comprehensive security assessment of the actual token functionality and cross-chain bridge logic is impossible. This leaves the most critical components of the system unaudited.
IssueThe provided code consists of abstract contracts (`Context`, `Ownable`) and interfaces (`IOFT`, `ILayerZeroReceiver`, `IOAppReceiver`). The core implementation logic for the Omnichain Fungible Token (OFT), including how tokens are minted, burned, transferred across chains via LayerZero, and how fees are handled, is entirely missing. Without this crucial implementation, a comprehensive security assessment of the actual token functionality and cross-chain bridge logic is impossible. This leaves the most critical components of the system unaudited.
FixProvide the complete source code for the OFT implementation, including all contracts that inherit from or implement the provided interfaces. A full audit of the entire system is essential to identify and mitigate vulnerabilities in the core cross-chain logic.
StatusUnresolved
High

Centralized Control via Ownable Pattern

H-01The system relies on the `Ownable` pattern, granting a single address exclusive control over critical administrative functions, such as `transferOwnership` and potentially other sensitive operations within the OFT implementation (e.g., setting LayerZero configurations, pausing transfers, or upgrading the contract if a proxy is used). In a complex cross-chain environment, this centralization creates a single point of failure. A compromise of the owner's private key or malicious intent could lead to catastrophic loss of funds or system manipulation.
IssueThe system relies on the `Ownable` pattern, granting a single address exclusive control over critical administrative functions, such as `transferOwnership` and potentially other sensitive operations within the OFT implementation (e.g., setting LayerZero configurations, pausing transfers, or upgrading the contract if a proxy is used). In a complex cross-chain environment, this centralization creates a single point of failure. A compromise of the owner's private key or malicious intent could lead to catastrophic loss of funds or system manipulation.
FixFor critical administrative functions, consider implementing a multi-signature wallet (e.g., Gnosis Safe) as the owner. For highly sensitive operations, explore a more decentralized governance model or time-locked execution to introduce delays and community oversight, reducing the risk associated with a single point of control.
StatusUnresolved
High

Inherent Complexity of Cross-Chain Operations

H-02The `IOFT` and LayerZero receiver interfaces indicate a highly complex cross-chain token system. Cross-chain bridges and omnichain tokens are inherently high-risk due to the intricate logic involved in message passing, state synchronization, nonce management, fee handling, and token burning/minting across disparate blockchain environments. Even without the implementation, the design space itself is prone to subtle vulnerabilities that can lead to significant exploits, as demonstrated by numerous past bridge hacks.
IssueThe `IOFT` and LayerZero receiver interfaces indicate a highly complex cross-chain token system. Cross-chain bridges and omnichain tokens are inherently high-risk due to the intricate logic involved in message passing, state synchronization, nonce management, fee handling, and token burning/minting across disparate blockchain environments. Even without the implementation, the design space itself is prone to subtle vulnerabilities that can lead to significant exploits, as demonstrated by numerous past bridge hacks.
FixEnsure the implementation adheres strictly to LayerZero's security best practices and thoroughly validates all incoming cross-chain messages. Implement robust error handling, comprehensive testing (unit, integration, and fuzzing), and formal verification for the core cross-chain logic. Consider external security reviews specifically focused on LayerZero integration patterns.
StatusUnresolved
Medium

Lack of Emergency Control Mechanisms

M-01The provided interfaces and `Ownable` contract do not expose any emergency control mechanisms such as a pause function or circuit breaker. In a cross-chain system, the ability to temporarily halt operations in response to a detected vulnerability, exploit, or critical bug is crucial to prevent further damage or loss of funds. Without such controls, any ongoing attack would continue unchecked until a patch is deployed and potentially all funds are drained.
IssueThe provided interfaces and `Ownable` contract do not expose any emergency control mechanisms such as a pause function or circuit breaker. In a cross-chain system, the ability to temporarily halt operations in response to a detected vulnerability, exploit, or critical bug is crucial to prevent further damage or loss of funds. Without such controls, any ongoing attack would continue unchecked until a patch is deployed and potentially all funds are drained.
FixImplement a robust pause mechanism (e.g., using OpenZeppelin's `Pausable` contract) that can be triggered by the owner or a designated emergency multisig. This mechanism should allow for pausing critical functions like `send` and `lzReceive` to mitigate risks during incidents. Clearly define the conditions under which the system can be paused and unpaused.
StatusUnresolved
Info

Use of Solidity 0.8.28

I-01The contract is compiled with Solidity version 0.8.28. This version includes automatic overflow and underflow checks for all arithmetic operations, which significantly reduces the risk of integer manipulation vulnerabilities.
IssueThe contract is compiled with Solidity version 0.8.28. This version includes automatic overflow and underflow checks for all arithmetic operations, which significantly reduces the risk of integer manipulation vulnerabilities.
FixContinue to use the latest stable and audited Solidity compiler versions. Regularly review compiler release notes for new features, bug fixes, and security improvements.
StatusResolved
Info

Use of Custom Errors

I-02The `Ownable` contract and `IOFT` interface utilize custom errors (e.g., `OwnableUnauthorizedAccount`, `InvalidLocalDecimals`, `SlippageExceeded`). This is a good practice as it provides more gas-efficient error handling compared to `require()` statements with string messages, and offers clearer, structured error information for off-chain applications.
IssueThe `Ownable` contract and `IOFT` interface utilize custom errors (e.g., `OwnableUnauthorizedAccount`, `InvalidLocalDecimals`, `SlippageExceeded`). This is a good practice as it provides more gas-efficient error handling compared to `require()` statements with string messages, and offers clearer, structured error information for off-chain applications.
FixMaintain the use of custom errors throughout the full OFT implementation for all relevant error conditions, ensuring consistent and gas-efficient error reporting.
StatusResolved

Category Ratings

TechnicalMedium4/10

The provided code includes standard OpenZeppelin `Context` and `Ownable` abstract contracts, which are well-tested and robust for basic access control (7.3 Access Control). The `IOFT`, `ILayerZeroReceiver`, and `IOAppReceiver` interfaces define a complex cross-chain token system using LayerZero. However, the actual implementation of the OFT logic, including token burning/minting, cross-chain message verification, and fee handling, was not provided for review (7.1 Architecture, 7.2 Code Security). This significantly limits the technical assessment, as cross-chain bridges are highly susceptible to technical vulnerabilities like reentrancy, logic errors, and oracle manipulation if not implemented with extreme care.

GovernanceHigh1/10

The `Ownable` pattern centralizes control to a single address, which can manage critical functions like `transferOwnership` and potentially other administrative actions in the OFT implementation (7.5 Governance). In a cross-chain token system, this single point of failure presents a high economic risk if the owner's key is compromised or misused (7.4 Economic). The `IOFT` interface defines functions for quoting fees and sending tokens, implying economic mechanisms that require careful implementation to prevent slippage, front-running, or fee manipulation (7.4 Economic). The lack of multi-signature or decentralized governance for critical operations increases the overall governance and economic risk.

UpgradesHigh3/10

The provided `Ownable` contract and interfaces do not inherently include upgradeability mechanisms (7.7 Upgrades). This means the contract itself is not designed to be upgradeable. If the full OFT system utilizes a proxy pattern for upgradeability, those proxy contracts and their implementation would need separate review to assess upgrade safety. Based solely on the provided code, there are no specific upgrade-related risks introduced.

Security Checklist

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

Holder Composition

89.6% in top 10
1.1% in wallets88.4% in contracts
Effective Concentration36.5%

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

$762.7K across 6 pairs
AerodromeVIRTUALanalysed$716.1K93.9%AerodromeUSDC$33.0K4.3%AerodromeUSDC$6.2K0.8%Uniswap v4USDC$3.3K0.4%Uniswap v3USDC$2.9K0.4%Uniswap v4USDC$1.1K0.1%

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
0xdac4…0c6a
Unlocked LP Held By
0x5552…2c81

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 — Multisig (2-of-3)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30% (89.6% total → 36.5% effective; 1.1% in EOAs, 88.4% 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 = 94% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 94% of DEX liquidity)
  • Token age < 30 days (still settling)
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 1 Medium 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
TownsCritical RiskICPCritical RiskGAME by Virtuals (GAME)Critical RiskRecallCritical RiskVANRYCritical RiskRIZEHigh Risk

Would You Like a More Detailed Audit of XMAQUINA?

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

Get Detailed Audit