Quantum Audit Logo
Launch App

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

Is XMAQUINA Safe?

DEUSBase
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades3/10Checks passed2 of 5Findings1 Critical · 2 High · 1 Medium · 2 Info6
SummaryAI Copilot

This audit covers the provided Solidity interfaces for an Omnichain Fungible Token (OFT) and the abstract Ownable contract.

Read the full analysis
What raised the score
  • Ownership not renounced — Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • Token age < 30 days
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
88.4%Contracts10.4%Everyone else
88.4%Contracts10.4%
ContractsWalletsEveryone elseBubble area = share of supply
89.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking88.4%
  • Walletsanonymous holders, free to sell1.1%
  • Everyone elsethe rest of the supply10.4%
Effective concentrationwhat the score reads36.5%
How holder types affect the score

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.

Holder balances as recorded by the audit of Sep 4, 2026

Liquidity

as of audit · Sep 4$762.7K across 6 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$716.1KShare of depth93.9%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x5552…2c81

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

Security Findings

1 Critical2 High1 Medium2 Info
Critical

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.C-01

Issue

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.

Fix

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.

Status

Unresolved

High

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.H-01

Issue

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.

Fix

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.

Status

Unresolved

High

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.H-02

Issue

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.

Fix

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.

Status

Unresolved

Medium

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.M-01

Issue

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.

Fix

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.

Status

Unresolved

Info

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.I-01

Issue

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.

Fix

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

Status

Resolved

Info

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.I-02

Issue

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.

Fix

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

Status

Resolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical4/10Medium risk

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.

Governance1/10High risk

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.

Upgrades3/10High risk

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.

Final RecommendationWhat to do about this score

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.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age9d
Contract0x940a…089b
Deployer0xdac4…0c6a
Badge for your website
XMAQUINA security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202671High
  2. Jul 23, 202670High

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the DEUS contract address?

The XMAQUINA (DEUS) contract on Base is 0x940a319b75861014a220d9c6c144d108552b089b. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is XMAQUINA a scam?

Quantum Audit's risk score for XMAQUINA is 71/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is DEUS liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $762.7K.

Who holds DEUS?

As of Sep 4, 2026, the 10 largest holders own 89.6% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
TownsBase71HighICPBase71HighGAME by VirtualsGAME · Base71HighMAGICBase71HighRecallBase72HighVANRYBase72High

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 Is this your token? Publish your own audit on this page