Quantum Audit Logo
Launch App

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

Is USDS Stablecoin Safe?

USDSEthereum
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 →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 High · 1 Medium · 1 Low · 1 Info4
SummaryAI Copilot

The USDS Stablecoin contract implements an ERC-20 compatible token with UUPS upgradeability and EIP-2612 permit functionality.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 30%
  • 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%
  • 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 > 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
92.5%Contracts6.8%Everyone else
92.5%Contracts6.8%
ContractsWalletsEveryone elseBubble area = share of supply
93.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking92.5%
  • Walletsanonymous holders, free to sell0.7%
  • Everyone elsethe rest of the supply6.8%
Effective concentrationwhat the score reads37.7%
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 4, 2026

Liquidity

as of audit · Sep 4$9.82M across 22 pairs
Show 4 more pairs

The 12 remaining pairs hold $7.3K between them and are not listed. The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$8.99MShare of depth91.6%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xce63…fd0a

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

Security Findings

1 High1 Medium1 Low1 Info
High

Centralized Control of Critical Functions

The 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).H-01

Issue

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

Fix

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

Status

Unresolved

Medium

Missing Overflow Check in mint Function

The 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).M-01

Issue

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

Fix

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

Status

Unresolved

Low

permit Function Front-Running Vulnerability

The 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).L-01

Issue

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

Fix

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

Status

Unresolved

Info

_isValidSignature Contract Check Edge Case

The _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).I-01

Issue

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

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

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.

Technical6/10Medium risk

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

Governance1/10High risk

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

Upgrades1/10High risk

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

Final RecommendationWhat to do about this score

To enhance the security posture of the USDS Stablecoin, it is strongly recommended to decentralize control over critical administrative functions.

Implementing a robust multi-signature wallet or a decentralized autonomous organization (DAO) for the auth role would significantly mitigate the risks associated with a single point of failure for minting and upgrades. Additionally, review the mint function's unchecked block to either add explicit overflow checks or remove unchecked to rely on default Solidity 0.8+ protections, ensuring maximum safety for token supply management.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkEthereum
Token age1y
Contract0xdc03…384f
Deployer0x4ec2…cfb8
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
USDS Stablecoin security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Aug 13, 202663Medium

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Related Audits

6 more on the recordAll audits
SPACE IDID · Ethereum63MediumMarlin PONDPOND · Ethereum63MediumSushiTokenSUSHI · Ethereum63MediumEspressoESP · Ethereum64MediumSEIEthereum62MediumDolomiteDOLO · Ethereum62Medium

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 Is this your token? Publish your own audit on this page