Quantum Audit Logo
Base · Smart Contract Security · Updated Jul 24, 2026

Is XMAQUINA Safe? DEUS

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

Contract 0x940a…089b DexScreener ↗
Volume 24h
$11.6K
Liquidity
$747.5K
Price
$0.02312
Token Age
9d
Top 10 Holders
90.2%

Security Checklist

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

Audit History

Jul 2370

Every audit run adds a dated snapshot — history is append-only and cannot be edited.

Audit Summary

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.

Final Recommendation: Prioritize a full security audit of the complete OFT implementation, including all LayerZero integration logic, token minting/burning mechanisms, and fee calculations. Implement robust emergency controls such as a pause mechanism or circuit breaker to mitigate risks during unforeseen events or attacks. Consider decentralizing critical administrative functions currently controlled by the single `Ownable` address, potentially through a multi-signature wallet or a more decentralized governance model, to reduce the single point of failure risk inherent in cross-chain systems.

Category Ratings

TechnicalMedium
4/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. How

GovernanceHigh
1/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 ri

UpgradesHigh
3/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 woul

LP Distribution

Top-1 Unlocked Holder99.1%
Top-3 Unlocked100.0%

What Raised This Score

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 Findings

1 Critical 2 High 1 Medium 2 Info
C-01CriticalUnresolved

Incomplete Audit Scope Due to Missing Implementation

The 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.

Recommendation: Provide 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.
H-01HighUnresolved

Centralized Control via Ownable Pattern

The 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.

Recommendation: For 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.
H-02HighUnresolved

Inherent Complexity of Cross-Chain Operations

The `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.

Recommendation: Ensure 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.
M-01MediumUnresolved

Lack of Emergency Control Mechanisms

The 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.

Recommendation: Implement 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.
I-01InformationalResolved

Use of Solidity 0.8.28

The 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.

Recommendation: Continue to use the latest stable and audited Solidity compiler versions. Regularly review compiler release notes for new features, bug fixes, and security improvements.
I-02InformationalResolved

Use of Custom Errors

The `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.

Recommendation: Maintain the use of custom errors throughout the full OFT implementation for all relevant error conditions, ensuring consistent and gas-efficient error reporting.

Would You Like a More Detailed Audit of XMAQUINA?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, no signup required.

Get Detailed Audit
Run Free Audit →