Quantum Audit Logo

Is Sperax USD Safe?

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

Sperax USD USDS
0xd74f…5748
Arbitrum
Not verifiedThis 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.
Last checked 7d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The audit covers the USDs token implementation contract, deployed as an upgradeable proxy on Arbitrum. The contract is built using OpenZeppelin's upgradeable standards, including ERC-20, Ownable, Pausable, and Permit functionalities. Key findings include centralized control over token operations, redundant SafeMath usage, and the absence of an explicit upgrade timelock.

1 Medium1 Low2 Informational
Volume 24h
$35.1K
Liquidity
$110.7K
Price
$0.9985
Token Age
4y
Top 10 Holders
92.6%

Security Findings

1 Med1 Low2 Info
Medium

Centralized Control over Token Supply and Operations

M-01The contract's `owner` (a 3/5 multisig) and `DEFAULT_ADMIN_ROLE` (also a 3/5 multisig) hold significant power. This includes the ability to mint new tokens via `_mint`, burn tokens via `_burn`, pause all token transfers via `pause()`, and upgrade the contract logic. While a multisig mitigates single-point-of-failure risks, this concentration of power means that a compromise or collusion among multisig signers could lead to arbitrary changes in token supply, freezing of user funds, or introduction of malicious logic through upgrades. (7.3 Access Control, 7.4 Economic, 7.5 Governance)
IssueThe contract's `owner` (a 3/5 multisig) and `DEFAULT_ADMIN_ROLE` (also a 3/5 multisig) hold significant power. This includes the ability to mint new tokens via `_mint`, burn tokens via `_burn`, pause all token transfers via `pause()`, and upgrade the contract logic. While a multisig mitigates single-point-of-failure risks, this concentration of power means that a compromise or collusion among multisig signers could lead to arbitrary changes in token supply, freezing of user funds, or introduction of malicious logic through upgrades. (7.3 Access Control, 7.4 Economic, 7.5 Governance)
FixImplement a timelock for critical administrative actions (e.g., minting, burning, pausing, upgrades) to provide a delay for users to react and for potential issues to be identified. Consider further decentralizing roles if feasible, or clearly document the multisig's operational procedures and security measures.
StatusUnresolved
Low

Redundant SafeMath Usage in Solidity 0.8.19

L-01The contract utilizes the `SafeMathUpgradeable` library for arithmetic operations. Solidity version 0.8.19, as specified by the pragma, includes native protection against integer overflows and underflows by default. Consequently, the explicit use of `SafeMathUpgradeable` for basic operations (e.g., `add`, `sub`, `mul`, `div`, `mod` without `try` or `errorMessage` parameters) is redundant. While not a security vulnerability in this context, it adds unnecessary gas costs and increases code verbosity without providing additional safety benefits. (7.2 Code Security)
IssueThe contract utilizes the `SafeMathUpgradeable` library for arithmetic operations. Solidity version 0.8.19, as specified by the pragma, includes native protection against integer overflows and underflows by default. Consequently, the explicit use of `SafeMathUpgradeable` for basic operations (e.g., `add`, `sub`, `mul`, `div`, `mod` without `try` or `errorMessage` parameters) is redundant. While not a security vulnerability in this context, it adds unnecessary gas costs and increases code verbosity without providing additional safety benefits. (7.2 Code Security)
FixFor Solidity 0.8.x and above, remove `SafeMathUpgradeable` and rely on native overflow/underflow checks. If specific `try` or `errorMessage` functionalities are desired, consider implementing them directly or using a more lightweight custom library.
StatusUnresolved
Info

Lack of Explicit Upgrade Timelock

I-01The contract is deployed behind a `TransparentUpgradeableProxy`, with the `ProxyAdmin` controlled by a 3/5 multisig. This setup allows for future upgrades to the contract's logic. However, the current architecture does not include an explicit on-chain timelock mechanism that would delay the execution of an upgrade proposal. While the multisig provides a layer of security by requiring multiple approvals, the absence of a timelock means that an approved upgrade could be executed immediately. This could limit the community's time to review proposed changes or react to potentially malicious upgrades. (7.7 Upgrades, 7.5 Governance)
IssueThe contract is deployed behind a `TransparentUpgradeableProxy`, with the `ProxyAdmin` controlled by a 3/5 multisig. This setup allows for future upgrades to the contract's logic. However, the current architecture does not include an explicit on-chain timelock mechanism that would delay the execution of an upgrade proposal. While the multisig provides a layer of security by requiring multiple approvals, the absence of a timelock means that an approved upgrade could be executed immediately. This could limit the community's time to review proposed changes or react to potentially malicious upgrades. (7.7 Upgrades, 7.5 Governance)
FixConsider implementing a timelock contract between the `ProxyAdmin` and the multisig wallet. This would introduce a mandatory delay period (e.g., 24-72 hours) between the approval of an upgrade and its execution, providing transparency and a window for community review and response.
StatusUnresolved
Info

Unused `_disableInitializers` Function

I-02The `Initializable` base contract provides a `_disableInitializers()` function, which, when called, permanently prevents any further initialization or re-initialization of the contract by setting `_initialized` to `type(uint8).max`. While this function is useful for non-upgradeable contracts to prevent re-initialization attacks, it is not explicitly called in the provided contract snippet. For upgradeable contracts, `reinitializer` might be used in future versions, making `_disableInitializers` undesirable. However, if the contract is intended to eventually become non-upgradeable or if a final initialization state is desired, not calling this function leaves the possibility of future re-ini…
IssueThe `Initializable` base contract provides a `_disableInitializers()` function, which, when called, permanently prevents any further initialization or re-initialization of the contract by setting `_initialized` to `type(uint8).max`. While this function is useful for non-upgradeable contracts to prevent re-initialization attacks, it is not explicitly called in the provided contract snippet. For upgradeable contracts, `reinitializer` might be used in future versions, making `_disableInitializers` undesirable. However, if the contract is intended to eventually become non-upgradeable or if a final initialization state is desired, not calling this function leaves the possibility of future re-ini…
FixDocument the intended lifecycle of the contract regarding initialization. If the contract is designed to remain upgradeable indefinitely, no action is strictly required. If there's a point where re-initialization should be permanently prevented, consider calling `_disableInitializers()` at that stage, ensuring it aligns with the overall upgrade strategy.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract leverages Solidity 0.8.19, benefiting from native overflow/underflow protection, and integrates well-tested OpenZeppelin upgradeable libraries for core functionalities (7.2 Code Security). The architecture is standard for an ERC-20 token with features like pausing and permit (7.1 Architecture). However, a centralized multisig retains significant control over token supply and operations (7.3 Access Control), posing a medium technical risk. Redundant `SafeMathUpgradeable` usage (L-01) introduces minor gas overhead.

GovernanceMedium4/10

Governance is managed by a 3/5 multisig for critical roles, including the owner, admin, and pauser, which enhances security over a single EOA (7.5 Governance). The economic model is based on a standard ERC-20 token with minting and burning capabilities (7.4 Economic). The multisig's extensive control over token supply and operational parameters (M-01) represents a centralization risk, despite the multisig setup. There is no explicit on-chain timelock for critical governance actions.

UpgradesHigh1/10

The contract utilizes a TransparentUpgradeableProxy pattern with an OpenZeppelin ProxyAdmin, controlled by a 3/5 multisig, providing a secure and flexible upgrade path (7.7 Upgrades). OpenZeppelin's `Initializable` and `__gap` variables are correctly implemented to prevent storage collisions. However, the upgrade process lacks an explicit on-chain timelock (I-01), allowing immediate execution of approved upgrades and reducing the window for community review.

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 3-of-5
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

92.6% in top 10
4.8% in wallets87.8% in contracts
Effective Concentration39.9%

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

$116.4K across 8 pairs
UniswapUSDCanalysed$110.7K95.2%Camelot v3USDC$4.3K3.7%Camelot v3USDC$6870.6%UniswapWETH$3040.3%Camelot v3USD₮0$1140.1%Camelot v3WETH$910.1%
Show 2 more pairsShow less
CamelotUSDC$800.1%Ramses v2USDC$490.0%

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 Holder85.2%
Top-3 Unlocked97.1%

Key Addresses

11 addresses
Deployer
0x42d2…9600
Unlocked LP Held By
0x638d…3a4d0xa9b6…2bff0x7775…f2be0xb744…b4a40x17eb…4c7b0x6827…c8b60x1877…46250x16b7…46700x5ac5…664e0xd4e3…2cf3

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 — strong Multisig (3-of-5)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (92.6% total → 39.9% effective; 4.8% in EOAs, 87.8% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 85.2% (independent LP — depth risk, pool = 95% of DEX liquidity)
  • LP top3 unlocked holders = 97.1% (independent LP — depth risk, pool = 95% of DEX liquidity)
  • 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
Subsquid (SQD)High RiskAutonomi (ANT)High RiskArbitrum Dog (MILES)High RiskCoW Protocol Token (COW)High RiskEquilibria Token (EQB)High RiskWrapped BTC (WBTC)High Risk

Would You Like a More Detailed Audit of Sperax USD?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit