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.

Early-stage security check — honeypot & rug-pull analysis
Is USDx a Scam?
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 →The USDx contract, an upgradeable ERC-20 token, implements standard functionalities with additional access control, pausing, and blacklisting features.
Read the full analysis- Ownership status UNKNOWN
- Mintable supply — no cap found, dilution unbounded
- Proxy contract
- Top-10 concentration > 50%
- 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 < 7 days
- 1 High finding(s) from audit
- 1 Medium finding(s) from audit
- 1 Low finding(s) from audit
Exact 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
Security Checklist
as of audit · Sep 5Holders
as of audit · Sep 5, 2026- Contractstreasury, vesting, bridge, staking59.0%
- Walletsanonymous holders, free to sell40.9%
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 5, 2026
Liquidity
as of audit · Sep 5The 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.
0x3e95…328dNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
HighCentralized Control and Single Point of Failure
The 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.H-01
Issue
The 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.
Fix
Ensure 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.
Status
Unresolved
MediumBlacklist and Pause Functionality Risks
The 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.M-01
Issue
The 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.
Fix
Clearly 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.
Status
Unresolved
LowPotential for approve Front-running
The 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.L-01
approve Front-runningIssue
The 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.
Fix
Advise 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.
Status
Unresolved
InfoUnused Constant AxisV2Ids.VERSION
The 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.I-01
AxisV2Ids.VERSIONIssue
The 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.
Fix
Remove the import or the constant if it is not intended for use within this contract to improve code clarity and reduce unnecessary dependencies.
Status
Unresolved
Analysis
AI Copilotas of audit · Sep 5The 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.
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.
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.
It is crucial to ensure that all privileged roles, especially the DEFAULT_ADMIN_ROLE, are assigned to robust, multi-signature wallets or time-locked governance contracts to mitigate the risks associated with centralized control.
Implement comprehensive monitoring for all role-based actions and token supply changes. Users should be fully aware of the inherent centralization and the capabilities of the privileged roles, particularly regarding pausing and blacklisting functionalities.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 5, 202674High
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Frequently Asked Questions
What is the USDX contract address?
The USDx contract on Ethereum is 0xa1fa7777974312f7d801a8880714a218f76233f8. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Is USDx a scam?
Quantum Audit's risk score for USDx is 74/100 (High risk) as of Sep 5, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; 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.
Is USDX liquidity locked?
Liquidity lock: Not locked (as of Sep 5, 2026). Total DEX liquidity: $2.01M.
Who holds USDX?
As of Sep 5, 2026, the 10 largest holders own 100.0% of the supply. The Holders section on this page shows who they are by holder type.
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 Is this your token? Publish your own audit on this page