Is Matrix (MTX) Safe? Smart Contract Security Analysis

Security Findings

1 High1 Med1 Low1 Info

High

Centralized Sanctions List Control

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

IssueThe `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).

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

StatusUnresolved

Medium

Owner's Extensive Control

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

IssueThe `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).

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

StatusUnresolved

Low

Lack of Emergency Pause Mechanism

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

IssueThe `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).

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

StatusUnresolved

Info

Fixed Decimals (6)

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

IssueThe 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).

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceHigh3/10

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

UpgradesHigh2/10

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

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Uups

ImplementationVerified source

Upgrades (30d)0 · stable

Liquidity Depth

$2.97M

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

0x000b…b000

Unlocked LP Held By

0xfe0b…b540

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

What Raised This Score

9 factors

Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
Proxy contract (upgradeable — admin can replace logic)
Top-10 concentration > 30% (105.5% total → 42.5% effective; 0.4% in EOAs, 105.1% 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)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
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

Is Matrix Safe?

Security Findings

Centralized Sanctions List Control

Owner's Extensive Control

Lack of Emergency Pause Mechanism

Fixed Decimals (6)

Category Ratings

Security Checklist

Proxy Upgrade Controls

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of Matrix?