On-chain security analysis — is it a scam or legit?
EthereumThe MTXTokenV1 contract is an upgradeable ERC-20 token utilizing OpenZeppelin's battle-tested libraries.
Read the full analysisEach 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
How the supply is spread across holders could not be read — the indexer's holder list does not add up to the supply. Check the largest holders on a block explorer, which reads current balances.
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0xfe0b…b540No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
MTXTokenV1 contract relies on an external ISanctionsList contract to restrict token transfers for sanctioned addresses. The owner has the sole authority to update this sanctionsList to any arbitrary address via setSanctionsList. A malicious or compromised SanctionsList contract, or a compromised owner, could arbitrarily freeze funds or block transfers for any address, leading to significant censorship risk and potential loss of access to funds for users (7.3 Access Control, 7.4 Economic, 7.6 External).H-01The MTXTokenV1 contract relies on an external ISanctionsList contract to restrict token transfers for sanctioned addresses. The owner has the sole authority to update this sanctionsList to any arbitrary address via setSanctionsList. A malicious or compromised SanctionsList contract, or a compromised owner, could arbitrarily freeze funds or block transfers for any address, leading to significant censorship risk and potential loss of access to funds for users (7.3 Access Control, 7.4 Economic, 7.6 External).
Implement a more decentralized or time-locked approach for updating the sanctionsList. Consider requiring multiple approvals (e.g., via a multi-sig or DAO governance) and/or a timelock delay before a new sanctionsList address becomes active. Clearly document the criteria and process for sanctioning addresses and the expected behavior of the ISanctionsList contract.
Unresolved
owner role holds significant power within the MTXTokenV1 contract. This includes the ability to upgrade the contract logic via the UUPS proxy pattern, change the metadataURI, and critically, update the sanctionsList contract. While the owner is identified as a contract (likely a multi-sig), a compromise of this owner contract would grant an attacker full control over the token's functionality, including the ability to introduce malicious logic through an upgrade or arbitrarily freeze user funds via the sanctions list (7.3 Access Control, 7.7 Upgrades, 7.8 Operations).M-01The owner role holds significant power within the MTXTokenV1 contract. This includes the ability to upgrade the contract logic via the UUPS proxy pattern, change the metadataURI, and critically, update the sanctionsList contract. While the owner is identified as a contract (likely a multi-sig), a compromise of this owner contract would grant an attacker full control over the token's functionality, including the ability to introduce malicious logic through an upgrade or arbitrarily freeze user funds via the sanctions list (7.3 Access Control, 7.7 Upgrades, 7.8 Operations).
Strengthen the security of the owner contract, ensuring it is a robust multi-signature wallet or a well-audited governance contract with appropriate safeguards. For highly sensitive operations like upgrades and sanctionsList changes, consider adding a timelock mechanism to allow for community review and potential intervention before changes take effect.
Unresolved
MTXTokenV1 contract does not include a pause mechanism. In the event of a critical vulnerability discovered within the token contract itself, or an external attack on a dependency (such as the SanctionsList), there is no way for the owner or a governance body to temporarily halt operations to mitigate damage or fix the issue. This could lead to irreversible losses if an exploit is discovered and cannot be immediately contained (7.2 Code Security, 7.8 Operations).L-01The MTXTokenV1 contract does not include a pause mechanism. In the event of a critical vulnerability discovered within the token contract itself, or an external attack on a dependency (such as the SanctionsList), there is no way for the owner or a governance body to temporarily halt operations to mitigate damage or fix the issue. This could lead to irreversible losses if an exploit is discovered and cannot be immediately contained (7.2 Code Security, 7.8 Operations).
Consider implementing an emergency pause mechanism (e.g., using OpenZeppelin's PausableUpgradeable contract). This would allow the owner (or a designated emergency multi-sig) to temporarily pause transfers and other critical functions in case of an unforeseen exploit or emergency, providing time to address the issue without further loss.
Unresolved
decimals() function is hardcoded to return 6, which is a non-standard value for ERC-20 tokens (typically 18). While this is a valid design choice and explicitly defined, it's important for integrators and users to be aware of this specific decimal value to prevent potential calculation errors or display issues in external systems, wallets, or DeFi protocols that might assume 18 decimals by default (7.4 Economic).I-01The token's decimals() function is hardcoded to return 6, which is a non-standard value for ERC-20 tokens (typically 18). While this is a valid design choice and explicitly defined, it's important for integrators and users to be aware of this specific decimal value to prevent potential calculation errors or display issues in external systems, wallets, or DeFi protocols that might assume 18 decimals by default (7.4 Economic).
Ensure that all documentation, front-end interfaces, and integration guides clearly communicate that the MTX token uses 6 decimals. Developers integrating with the token should explicitly account for this decimal value in their calculations to avoid discrepancies.
Unresolved
The MTXTokenV1 contract is an upgradeable ERC-20 token utilizing OpenZeppelin's battle-tested libraries. It includes a sanctions list mechanism and owner-controlled upgradeability. While the core implementation is robust, significant risks stem from the centralized control over the sanctions list and the owner's extensive authority, particularly regarding upgrades and external dependencies.
The contract leverages battle-tested OpenZeppelin upgradeable libraries for ERC-20, ERC-20 Permit, Ownable, and UUPS functionalities, demonstrating sound architectural choices (7.1 Architecture, 7.2 Code Security). Custom allowance functions correctly handle overflow/underflow, enhancing code security (7.2 Code Security). However, a significant technical risk arises from the critical dependency on an external ISanctionsList contract, which can arbitrarily restrict token transfers (7.6 External). The owner's ability to change this external dependency introduces a potential attack vector if the owner is compromised (7.3 Access Control).
The token's economic model involves an initial fixed supply distribution to specific addresses, with no further minting or burning functions (7.4 Economic). A major governance and economic risk is the centralized control over the sanctionsList (7.5 Governance). The owner can update this list to any address, enabling arbitrary freezing or blocking of user funds, which poses a severe censorship risk (7.4 Economic). While the owner is a contract, this central point of control could lead to significant economic disruption if compromised or misused (7.5 Governance).
The contract correctly implements the UUPS proxy pattern using OpenZeppelin's UUPSUpgradeable (7.7 Upgrades). Storage compatibility is maintained with the __gap variable, ensuring smooth future upgrades (7.7 Upgrades). The _authorizeUpgrade function is restricted to the onlyOwner modifier, providing a clear and secure upgrade path (7.7 Upgrades). However, this centralizes upgrade authority, meaning a compromise of the owner address could lead to unauthorized contract logic changes (7.7 Upgrades).
It is recommended to implement a robust governance mechanism for critical functions, especially for updating the sanctionsList and initiating upgrades, to mitigate the risks associated with centralized control.
Consider introducing a time-lock or multi-signature approval process for these sensitive operations to provide a window for review and prevent immediate malicious actions. Additionally, evaluate the necessity and scope of the sanctions mechanism to ensure it aligns with the project's decentralization goals and user expectations.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
The Matrix (MTX) contract on Ethereum is 0x000025b3816630ad283267d4eb3a5fc8b0200000. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for Matrix is 58/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Upgradeable; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $2.97M.
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
