Quantum Audit Logo

Is USDx a Scam?

Early-stage security check — honeypot & rug-pull analysis

Is this your token? Publish your own audit on this page →

USDx USDX
0xa1fa…33f8
Ethereum Not verifiedLast checked 1d ago 1 audit on record New Launch · 3d old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The USDx contract, an upgradeable ERC-20 token, implements standard functionalities with additional access control, pausing, and blacklisting features. The contract leverages OpenZeppelin's upgradeable libraries, ensuring robust architecture and upgrade safety. While the implementation is technically sound, the inherent centralization through privileged roles presents significant governance and economic risks, particularly concerning the control over minting, burning, and user funds.

1 High1 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (3d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$4.13M
Liquidity
$2.01M
Price
$0.9988
Token Age
3d
Top 10 Holders
100.0%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control and Single Point of Failure

H-01The `DEFAULT_ADMIN_ROLE` in the `USDx` contract holds extensive power, including the ability to grant and revoke all other roles (`MARKET_ROLE`, `BRIDGE_ROLE`, `RESTRICTION_ROLE`, `PAUSER_ROLE`). If this role's private key or controlling entity is compromised, an attacker could gain full control over the token's supply (via minting/burning roles), pause all operations, and blacklist any address, leading to a complete compromise of the protocol and user funds. While the proxy admin is a Timelock, the `admin` for the contract's internal roles needs to be equally robust.
IssueThe `DEFAULT_ADMIN_ROLE` in the `USDx` contract holds extensive power, including the ability to grant and revoke all other roles (`MARKET_ROLE`, `BRIDGE_ROLE`, `RESTRICTION_ROLE`, `PAUSER_ROLE`). If this role's private key or controlling entity is compromised, an attacker could gain full control over the token's supply (via minting/burning roles), pause all operations, and blacklist any address, leading to a complete compromise of the protocol and user funds. While the proxy admin is a Timelock, the `admin` for the contract's internal roles needs to be equally robust.
FixEnsure that the `DEFAULT_ADMIN_ROLE` is controlled by a robust governance mechanism, such as a multi-signature wallet with a high threshold or a time-locked governance contract. Avoid assigning this role to a single External Owned Account (EOA). Regularly review and audit the security of the entities holding these privileged roles.
StatusUnresolved
Medium

Blacklist and Pause Functionality Risks

M-01The contract includes `pause()` and `blacklist()` functionalities, controlled by the `PAUSER_ROLE` and `RESTRICTION_ROLE` respectively. These functions allow privileged entities to halt all token transfers and approvals, or to prevent specific addresses from interacting with the token. While intended for emergency response or regulatory compliance, these features introduce a significant centralization risk, enabling potential censorship, denial of service for users, or freezing of funds at the discretion of the role holders.
IssueThe contract includes `pause()` and `blacklist()` functionalities, controlled by the `PAUSER_ROLE` and `RESTRICTION_ROLE` respectively. These functions allow privileged entities to halt all token transfers and approvals, or to prevent specific addresses from interacting with the token. While intended for emergency response or regulatory compliance, these features introduce a significant centralization risk, enabling potential censorship, denial of service for users, or freezing of funds at the discretion of the role holders.
FixClearly communicate the existence and implications of these functionalities to all users. Implement strict operational procedures and multi-party control for the `PAUSER_ROLE` and `RESTRICTION_ROLE` to prevent misuse. Consider adding a time-lock or governance vote requirement for activating these critical functions, if feasible within the protocol's design.
StatusUnresolved
Low

Potential for `approve` Front-running

L-01The standard ERC-20 `approve` function is susceptible to a known front-running vulnerability. If a user approves an amount for a spender, and then attempts to approve a different amount, a malicious actor can front-run the second `approve` transaction by spending the initially approved amount. When the second `approve` transaction confirms, the spender will have access to the sum of both approved amounts, potentially leading to unintended fund transfers.
IssueThe standard ERC-20 `approve` function is susceptible to a known front-running vulnerability. If a user approves an amount for a spender, and then attempts to approve a different amount, a malicious actor can front-run the second `approve` transaction by spending the initially approved amount. When the second `approve` transaction confirms, the spender will have access to the sum of both approved amounts, potentially leading to unintended fund transfers.
FixAdvise users to set `approve` amounts to zero before increasing them, or to use the `increaseAllowance` and `decreaseAllowance` functions (if available, though not explicitly implemented in this contract beyond `ERC20Upgradeable`'s internal `_approve`). The `permit` function, which includes a `deadline`, offers better protection against this specific front-running vector.
StatusUnresolved
Info

Unused Constant `AxisV2Ids.VERSION`

I-01The `AxisV2Ids.VERSION` constant is imported from `AxisV2Ids.sol` but is not utilized anywhere within the `USDx` contract. While this does not pose a security vulnerability, it represents dead code.
IssueThe `AxisV2Ids.VERSION` constant is imported from `AxisV2Ids.sol` but is not utilized anywhere within the `USDx` contract. While this does not pose a security vulnerability, it represents dead code.
FixRemove the import or the constant if it is not intended for use within this contract to improve code clarity and reduce unnecessary dependencies.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates strong technical foundations (7.1 Architecture, 7.2 Code Security). It correctly utilizes OpenZeppelin's upgradeable ERC-20, ERC-20Permit, and AccessControl libraries, ensuring standard compliance and security best practices. The implementation of custom error types enhances gas efficiency and clarity. However, the extensive power granted to the `DEFAULT_ADMIN_ROLE` and other privileged roles (7.3 Access Control) introduces a centralized control point, which, if compromised, could lead to significant technical vulnerabilities.

GovernanceHigh1/10

The USDx token's economic model (7.4 Economic) is inherently centralized, typical for a managed stablecoin. Privileged roles (`MARKET_ROLE`, `BRIDGE_ROLE`) have the ability to mint tokens, and `BRIDGE_ROLE` can burn tokens, giving significant control over the token supply. The `PAUSER_ROLE` and `RESTRICTION_ROLE` enable pausing all operations and blacklisting individual accounts, which can lead to censorship or freezing of user funds. While these features are intended for operational control (7.8 Operations), they represent a high governance risk (7.5 Governance) due to the concentration of power in a few entities.

UpgradesHigh1/10

The contract is designed for upgradeability using the TransparentUpgradeableProxy pattern (7.7 Upgrades). It correctly inherits from `Initializable` and includes a `__gap` storage variable to prevent storage collisions in future upgrades. The constructor properly calls `_disableInitializers()`, and the `initialize` function uses the `initializer` modifier, ensuring safe deployment and upgrade paths. The proxy's admin is controlled by a Timelock, providing a robust and time-delayed mechanism for upgrades.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

100.0% in top 10
40.9% in wallets59.0% in contracts
Effective Concentration64.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

$2.01M

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
0x12dd…ce63
Unlocked LP Held By
0x3e95…328d

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

What Raised This Score

11 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 50% (100.0% total → 64.5% effective; 40.9% in EOAs, 59.0% in contracts — heavy)
  • 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)
  • Token age < 7 days (early, volatile)
  • 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

Related Audits

6 more on the record
Main Street USD (MSUSD)Critical RiskCovalent X Token (CXT)Critical RiskNEXOCritical RiskCronos (CRO)Critical RiskEpic Chain (EPIC)Critical RisktrUSDCritical Risk

Would You Like a More Detailed Audit of USDx?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit