Quantum Audit Logo
Launch App

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

Is United Stables Safe?

UBNB Chain
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
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 Critical · 1 High · 2 Medium · 1 Low · 1 Info6
SummaryAI Copilot

The StablecoinV2 contract, an upgradeable ERC20 token, introduces EIP-7598 authorization features.

Read the full analysis
What raised the score
  • Ownership not renounced — Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Top-10 concentration > 70%
  • 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 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership NOT renounced — Multisig (2-of-4)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 70% (96.6% total → 93.0% effective; 90.5% in EOAs, 6.0% in contracts — extreme)
  • 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 = 84% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 84% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 2 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
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
6.0%Contracts90.5%Wallets3.4%
6.0%90.5%Wallets3.4%
ContractsWalletsEveryone elseBubble area = share of supply
96.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking6.0%
  • Walletsanonymous holders, free to sell90.5%
  • Everyone elsethe rest of the supply3.4%
Effective concentrationwhat the score reads93.0%
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$24.92M across 5 pairs

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$21.01MShare of depth84.3%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x556b…d59e0xd84e…617b0x1a8d…d6ff0x0700…e297

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

Security Findings

1 Critical1 High2 Medium1 Low1 Info
Critical

Missing __gap in Base Contract for Upgradeability

The Stablecoin base contract, which StablecoinV2 inherits from, does not include a __gap storage variable. This is crucial for upgradeable contracts to prevent storage collisions if new state variables are added to the base contract in future upgrades, or if StablecoinV2 adds new state variables that conflict with future Stablecoin state variables. While StablecoinV2 itself has a __gap, the base contract's omission creates a significant risk for the overall upgradeability pattern (7.7 Architecture).C-01

Issue

The Stablecoin base contract, which StablecoinV2 inherits from, does not include a __gap storage variable. This is crucial for upgradeable contracts to prevent storage collisions if new state variables are added to the base contract in future upgrades, or if StablecoinV2 adds new state variables that conflict with future Stablecoin state variables. While StablecoinV2 itself has a __gap, the base contract's omission creates a significant risk for the overall upgradeability pattern (7.7 Architecture).

Fix

Add uint256[50] private __gap; (or an appropriately sized array) to the Stablecoin contract to ensure future storage compatibility and prevent potential storage collisions.

Status

Unresolved

High

Centralized Control of Core Token Functions

The contract exhibits significant centralization (7.3 Access Control, 7.5 Governance), with the owner (a 2/4 multisig) having control over critical functions such as mint, pause, freeze accounts, setAutoMintMaxLimit, and enabling/disabling EIP-7598 features. Additionally, an autoOwner role can autoMint up to a specified limit. While a multisig mitigates some risk, a compromise of the multisig or malicious actions by its members could lead to severe consequences, including arbitrary token minting, freezing user funds, or halting operations.H-01

Issue

The contract exhibits significant centralization (7.3 Access Control, 7.5 Governance), with the owner (a 2/4 multisig) having control over critical functions such as mint, pause, freeze accounts, setAutoMintMaxLimit, and enabling/disabling EIP-7598 features. Additionally, an autoOwner role can autoMint up to a specified limit. While a multisig mitigates some risk, a compromise of the multisig or malicious actions by its members could lead to severe consequences, including arbitrary token minting, freezing user funds, or halting operations.

Fix

Evaluate if any of these highly centralized functions can be decentralized or made subject to a more robust governance mechanism (e.g., time-locks, community voting) if the protocol's roadmap allows. Clearly communicate the extent of centralized control to users.

Status

Unresolved

Medium

Front-running Risk for cancelAuthorization

The cancelAuthorization function allows an authorizer to invalidate a previously issued authorization by marking its nonce as used. However, if an attacker observes a pending cancelAuthorization transaction, they could front-run it by submitting a transferWithAuthorization or receiveWithAuthorization transaction using the same nonce before the cancellation is processed. This could lead to an unauthorized transfer of funds despite the authorizer's intent to cancel (7.2 Code Security).M-01

Issue

The cancelAuthorization function allows an authorizer to invalidate a previously issued authorization by marking its nonce as used. However, if an attacker observes a pending cancelAuthorization transaction, they could front-run it by submitting a transferWithAuthorization or receiveWithAuthorization transaction using the same nonce before the cancellation is processed. This could lead to an unauthorized transfer of funds despite the authorizer's intent to cancel (7.2 Code Security).

Fix

While inherent to signature-based systems, users should be aware of this risk. Consider implementing a mechanism where cancelAuthorization can be submitted with a higher gas price to increase its chances of being included first, or advise users to ensure their cancellation transactions are prioritized.

Status

Unresolved

Medium

Potential for autoMintMaxLimit to be Set to Zero

The setAutoMintMaxLimit function allows the owner to set the autoMintMaxLimit to any uint256 value, including zero. If the limit is set to zero, the autoMint function would become unusable, as require(autoMintMaxLimit >= amount, ...) would fail for any amount > 0. While this might be an intentional 'kill switch' for autoMint, it could also be set accidentally, disrupting operations (7.4 Economic).M-02

Issue

The setAutoMintMaxLimit function allows the owner to set the autoMintMaxLimit to any uint256 value, including zero. If the limit is set to zero, the autoMint function would become unusable, as require(autoMintMaxLimit >= amount, ...) would fail for any amount > 0. While this might be an intentional 'kill switch' for autoMint, it could also be set accidentally, disrupting operations (7.4 Economic).

Fix

Consider adding a require(limit > 0 || limit == 0) if setting to zero is intended as a disable, or require(limit > 0) if autoMint should always be available. Document the intended behavior of setting autoMintMaxLimit to zero.

Status

Unresolved

Low

block.timestamp Reliance for validAfter/validBefore

The _transferOrReceiveWithAuthorization function relies on block.timestamp for checking validAfter and validBefore. While generally acceptable, block.timestamp can be manipulated by miners within a certain range (up to 900 seconds on Ethereum, similar on BSC). This could slightly extend or shorten the validity window of an authorization, potentially allowing a transaction to be included just outside the intended window (7.2 Code Security).L-01

Issue

The _transferOrReceiveWithAuthorization function relies on block.timestamp for checking validAfter and validBefore. While generally acceptable, block.timestamp can be manipulated by miners within a certain range (up to 900 seconds on Ethereum, similar on BSC). This could slightly extend or shorten the validity window of an authorization, potentially allowing a transaction to be included just outside the intended window (7.2 Code Security).

Fix

Acknowledge this inherent EVM characteristic. For most applications, the precision of block.timestamp is sufficient. If extreme precision is required, consider alternative time sources or adjust validity windows to account for potential miner manipulation.

Status

Unresolved

Info

Unused _msgSender() in mint event

In the mint(uint256 amount) function, the Mint event is emitted with _msgSender() as both caller and to. However, the _mint function itself mints to _msgSender(). The to parameter in the event is redundant in this specific overload, as it will always be the same as caller (7.2 Code Security).I-01

Issue

In the mint(uint256 amount) function, the Mint event is emitted with _msgSender() as both caller and to. However, the _mint function itself mints to _msgSender(). The to parameter in the event is redundant in this specific overload, as it will always be the same as caller (7.2 Code Security).

Fix

Consider removing the to parameter from the Mint event in this specific overload, or ensure consistency if _msgSender() is always the recipient. This is a minor stylistic point.

Status

Unresolved

Analysis

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

The StablecoinV2 contract, an upgradeable ERC20 token, introduces EIP-7598 authorization features. The audit identified a critical upgradeability flaw in the base contract, Stablecoin, due to a missing __gap variable. High centralization of control over core token functions and potential front-running risks for authorization cancellations were also noted. The contract leverages OpenZeppelin's upgradeable patterns and includes features like autoMint and frozen accounts, managed by distinct roles.

Technical4/10Medium risk

The technical architecture (7.1) leverages OpenZeppelin's upgradeable contracts and EIP-7598 for signature-based transfers, enhancing functionality. Code security (7.2) is generally good, using Solidity 0.8.x and OpenZeppelin libraries, which mitigate common issues like integer overflows. The EIP-7598 implementation correctly uses nonces and time windows to prevent replay attacks. However, a critical upgradeability issue (C-01) exists where the Stablecoin base contract lacks a __gap variable, posing a significant risk of storage collisions in future upgrades.

Governance1/10High risk

The contract's economic model (7.4) and governance (7.5) are highly centralized, with an owner (multisig) controlling minting, pausing, freezing accounts, and setting autoMintMaxLimit (H-01). An autoOwner role can autoMint up to this limit. While a multisig enhances security over a single EOA, this centralization presents a single point of failure. The autoMintMaxLimit can also be set to zero (M-02), effectively disabling autoMint without explicit checks.

Upgrades1/10High risk

The contract utilizes OpenZeppelin's TransparentUpgradeableProxy pattern (7.7) and correctly implements initializer and reinitializer functions for Stablecoin and StablecoinV2 respectively. StablecoinV2 includes a __gap variable for future upgrades. However, the Stablecoin base contract critically lacks a __gap variable (C-01), which could lead to storage collisions if Stablecoin itself is upgraded or if StablecoinV2 adds new state variables that conflict with future Stablecoin state variables. This oversight compromises the robustness of the upgradeability pattern.

Final RecommendationWhat to do about this score

Address the critical upgradeability issue by adding a __gap variable to the Stablecoin base contract to ensure storage compatibility for future upgrades.

Review the extent of centralized control, particularly for minting and freezing functions, and consider implementing additional safeguards or decentralization measures if feasible for the protocol's long-term vision. Users should be made aware of the front-running risk associated with cancelAuthorization and advised on best practices for transaction submission.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBNB Chain
Token age7mo
Contract0xce24…6666
Deployer0xc84f…882e
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Multisig 2-of-4
ImplementationVerified source
Badge for your website
United Stables 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, 202682High

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

Frequently Asked Questions

What is the U contract address?

The United Stables (U) contract on BNB Chain is 0xce24439f2d9c6a2289f741120fe202248b666666. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is United Stables a scam?

Quantum Audit's risk score for United Stables is 82/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is U liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $24.92M.

Who holds U?

As of Sep 4, 2026, the 10 largest holders own 96.6% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
CATBNB Chain82HighVortexPadVPAD · BNB Chain82HighAIOZ NetworkAIOZ · BNB Chain82HighNEAR ProtocolNEAR · BNB Chain82HighNVIDIA CorpNVDAB · BNB Chain81HighGiggle TomTOM · BNB Chain81High

Would You Like a More Detailed Audit of United Stables?

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