Quantum Audit Logo

Is USDS Stablecoin Safe?

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

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

USDS Stablecoin USDS
0xdc03…384f
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The USDS Stablecoin contract implements an ERC-20 compatible token with UUPS upgradeability and EIP-2612 permit functionality. The contract exhibits good technical practices, leveraging OpenZeppelin's battle-tested libraries. However, the audit identified a high-severity centralization risk due to the `auth` role's control over critical functions like minting and upgrades. A medium-severity finding related to unchecked arithmetic in the `mint` function was also noted, alongside low and informational findings concerning `permit` front-running and an `_isValidSignature` edge case. Addressing the centralization risk is paramount for the long-term security and trust of the protocol.

1 High1 Medium1 Low1 Informational
Volume 24h
$477.1K
Liquidity
$8.99M
Price
$0.9978
Token Age
1y
Top 10 Holders
93.2%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control of Critical Functions

H-01The `auth` modifier grants a single address (or a set of addresses added via `rely`) complete control over critical functions such as `mint` (token supply inflation) and `_authorizeUpgrade` (contract logic changes). This centralization introduces a single point of failure and trust, as a compromise of this address could lead to arbitrary minting or malicious upgrades, severely impacting the stablecoin's integrity and user trust (7.3 Access Control, 7.4 Economic, 7.5 Governance, 7.7 Upgrades).
IssueThe `auth` modifier grants a single address (or a set of addresses added via `rely`) complete control over critical functions such as `mint` (token supply inflation) and `_authorizeUpgrade` (contract logic changes). This centralization introduces a single point of failure and trust, as a compromise of this address could lead to arbitrary minting or malicious upgrades, severely impacting the stablecoin's integrity and user trust (7.3 Access Control, 7.4 Economic, 7.5 Governance, 7.7 Upgrades).
FixImplement a robust multi-signature wallet or a decentralized governance mechanism (e.g., a DAO) to manage the `auth` role. This would require multiple approvals for critical operations, significantly reducing the risk of a single point of compromise and distributing control.
StatusUnresolved
Medium

Missing Overflow Check in `mint` Function

M-01The `mint` function uses `unchecked` blocks for `balanceOf[to] = balanceOf[to] + value` and `totalSupply = totalSupply + value`. While `uint256` is very large, in the extreme theoretical case where `totalSupply` or an individual `balanceOf` approaches `type(uint256).max`, adding `value` could lead to an overflow, wrapping the value to zero. Although highly improbable in practical scenarios for a stablecoin, explicit overflow checks or removal of `unchecked` for additions are generally safer, especially for functions that increase total supply (7.2 Code Security).
IssueThe `mint` function uses `unchecked` blocks for `balanceOf[to] = balanceOf[to] + value` and `totalSupply = totalSupply + value`. While `uint256` is very large, in the extreme theoretical case where `totalSupply` or an individual `balanceOf` approaches `type(uint256).max`, adding `value` could lead to an overflow, wrapping the value to zero. Although highly improbable in practical scenarios for a stablecoin, explicit overflow checks or removal of `unchecked` for additions are generally safer, especially for functions that increase total supply (7.2 Code Security).
FixRe-evaluate the necessity of `unchecked` for additions in the `mint` function. If `unchecked` is desired for gas optimization, ensure that external safeguards or protocol invariants prevent `totalSupply` or `balanceOf` from reaching values close to `type(uint256).max` when `mint` is called. Alternatively, remove `unchecked` to rely on default Solidity 0.8+ overflow protection.
StatusUnresolved
Low

`permit` Function Front-Running Vulnerability

L-01The `permit` function, while correctly implemented according to EIP-2612, is inherently susceptible to front-running. A malicious actor could observe a pending `permit` transaction and submit their own transaction with a higher gas price, potentially causing the legitimate transaction to fail or consuming the `nonce` for a different `permit` call if they can craft a valid signature. While the `nonce` mechanism prevents replay attacks of the *same* signature, it does not prevent gas griefing or denial of service for the legitimate user (7.2 Code Security).
IssueThe `permit` function, while correctly implemented according to EIP-2612, is inherently susceptible to front-running. A malicious actor could observe a pending `permit` transaction and submit their own transaction with a higher gas price, potentially causing the legitimate transaction to fail or consuming the `nonce` for a different `permit` call if they can craft a valid signature. While the `nonce` mechanism prevents replay attacks of the *same* signature, it does not prevent gas griefing or denial of service for the legitimate user (7.2 Code Security).
FixUsers should be aware of the front-running risks associated with `permit` transactions. While the protocol cannot fully mitigate this inherent characteristic, providing clear warnings to users about potential gas griefing or allowance 'theft' for specific `permit` parameters can be beneficial.
StatusUnresolved
Info

`_isValidSignature` Contract Check Edge Case

I-01The `_isValidSignature` function checks `signer.code.length > 0` to determine if an address is a contract before attempting an `IERC1271.isValidSignature` staticcall. This check can be bypassed during contract deployment if a contract calls `permit` within its constructor, as `signer.code.length` would still be zero. While this is a known edge case for `extcodesize` checks and unlikely to be exploited in the context of `permit` where `owner` is typically an EOA or a fully deployed contract, it's a subtle detail in contract interaction logic (7.2 Code Security).
IssueThe `_isValidSignature` function checks `signer.code.length > 0` to determine if an address is a contract before attempting an `IERC1271.isValidSignature` staticcall. This check can be bypassed during contract deployment if a contract calls `permit` within its constructor, as `signer.code.length` would still be zero. While this is a known edge case for `extcodesize` checks and unlikely to be exploited in the context of `permit` where `owner` is typically an EOA or a fully deployed contract, it's a subtle detail in contract interaction logic (7.2 Code Security).
FixNo immediate action is required as the impact is minimal for the `permit` function's intended use. However, for future implementations involving `extcodesize` checks, consider alternative methods or acknowledge this specific edge case.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates good technical practices, utilizing OpenZeppelin's UUPSUpgradeable for secure upgradeability and implementing EIP-2612 `permit` functionality (7.1 Architecture). Standard ERC-20 operations are present, with `unchecked` blocks used for gas optimization in `transfer` and `burn` where safety is ensured by prior checks (7.2 Code Security). However, the `mint` function also uses `unchecked` for additions without explicit overflow checks, posing a theoretical risk (7.2 Code Security). Additionally, the `_isValidSignature` function's contract check has a known edge case during contract deployment (7.2 Code Security).

GovernanceHigh1/10

The contract establishes a clear `auth` role for administrative functions, which is initialized to the deployer and can be managed via `rely` and `deny` (7.3 Access Control). This role controls critical economic functions like `mint`, allowing for centralized supply management typical of a stablecoin (7.4 Economic). The primary concern is the high degree of centralization, as a single compromised `auth` address could lead to arbitrary token minting, impacting the stablecoin's peg and trust (7.5 Governance).

UpgradesHigh1/10

The contract correctly implements the UUPS upgradeability pattern using OpenZeppelin's `UUPSUpgradeable` base contract (7.7 Upgrades). The `_authorizeUpgrade` function is appropriately overridden and protected by the `auth` modifier, ensuring only authorized entities can initiate upgrades (7.7 Upgrades). However, this also means that the upgrade process is entirely controlled by the centralized `auth` role, presenting a significant single point of failure for contract evolution and security (7.7 Upgrades).

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

93.2% in top 10
0.7% in wallets92.5% in contracts
Effective Concentration37.7%

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

$9.82M across 22 pairs
Uniswap v2SKYanalysed$8.99M91.6%Uniswap v4USDT$218.6K2.2%Uniswap v3DAI$208.1K2.1%Uniswap v4USDR$196.4K2.0%Uniswap v4USDT$60.4K0.6%Uniswap v4SKY$46.6K0.5%
Show 4 more pairsShow less
Uniswap v4DFiUSD$45.0K0.5%Uniswap v4ETH$20.5K0.2%Uniswap v3USDC$18.1K0.2%Uniswap v3PEPE$1.6K0.0%

The 12 remaining pairs hold $7.3K between them and are not listed.

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
0x4ec2…cfb8
Unlocked LP Held By
0xce63…fd0a

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

What Raised This Score

10 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 > 30% (93.2% total → 37.7% effective; 0.7% in EOAs, 92.5% 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, pool = 92% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 92% of DEX liquidity)
  • 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
SPACE ID (ID)High RiskMarlin POND (POND)High RiskSushiToken (SUSHI)High RiskEspresso (ESP)High RiskSEIHigh RiskDolomite (DOLO)High Risk

Would You Like a More Detailed Audit of USDS Stablecoin?

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

Get Detailed Audit