Is United Stables (U) Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 High2 Med1 Low1 Info

Critical

Missing `__gap` in Base Contract for Upgradeability

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

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

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

StatusUnresolved

High

Centralized Control of Core Token Functions

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

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

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

StatusUnresolved

Medium

Front-running Risk for `cancelAuthorization`

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

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

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

StatusUnresolved

Medium

Potential for `autoMintMaxLimit` to be Set to Zero

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

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

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

StatusUnresolved

Low

`block.timestamp` Reliance for `validAfter`/`validBefore`

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

IssueThe `_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).

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

StatusUnresolved

Info

Unused `_msgSender()` in `mint` event

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

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

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

StatusUnresolved

Category Ratings

TechnicalMedium4/10

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.

GovernanceHigh1/10

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.

UpgradesHigh1/10

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.

Security Checklist

1/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent

AdminOZ ProxyAdmin → Multisig 2-of-4

ImplementationVerified source

Holder Composition

96.6% in top 10

90.5% in wallets6.0% in contracts

Effective Concentration93.0%

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

$24.92M across 5 pairs

Pancakeswap v3USDTanalysed$21.01M Pancakeswap v3WBNB$3.71M Pancakeswap v2WBNB$166.7K Pancakeswap v3USDC$27.3K Pancakeswap v2USDT$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 Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

5 addresses

Deployer

0xc84f…882e

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.

What Raised This Score

11 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

Is United Stables Safe?

Security Findings

Missing `__gap` in Base Contract for Upgradeability

Centralized Control of Core Token Functions

Front-running Risk for `cancelAuthorization`

Potential for `autoMintMaxLimit` to be Set to Zero

`block.timestamp` Reliance for `validAfter`/`validBefore`

Unused `_msgSender()` in `mint` event

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of United Stables?