Quantum Audit Logo

Is OpenUSDT Safe?

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

OpenUSDT OUSDT
0x1217…e189
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The XERC20 contract, an upgradeable ERC-20 token, was audited for security vulnerabilities. A critical vulnerability was identified where the `mint` function is publicly accessible, allowing any caller to create new tokens, leading to uncontrolled supply inflation. Other findings include potential rate limit bypasses, immutability concerns for a critical operational address, and minor issues related to naming conventions and hardcoded values.

1 Critical1 High1 Medium1 Low1 Informational
Volume 24h
$179.4K
Liquidity
$119.4K
Price
$1.0001
Token Age
1y
Top 10 Holders
92.4%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Public `mint` function allows arbitrary token creation

C-01The `mint(address _user, uint256 _amount)` function is declared `public`, allowing any external caller to mint new tokens to any specified address. This bypasses typical access control mechanisms for token creation, leading to uncontrolled inflation and potential devaluation of the token. While the `_mintWithCaller` function applies a rate limit based on `msg.sender`, this only limits the rate of minting per individual caller, not the overall ability to inflate the supply.
IssueThe `mint(address _user, uint256 _amount)` function is declared `public`, allowing any external caller to mint new tokens to any specified address. This bypasses typical access control mechanisms for token creation, leading to uncontrolled inflation and potential devaluation of the token. While the `_mintWithCaller` function applies a rate limit based on `msg.sender`, this only limits the rate of minting per individual caller, not the overall ability to inflate the supply.
FixRestrict the `mint` function to authorized roles (e.g., `onlyOwner` or a dedicated minter role) or remove it if minting is only intended via cross-chain mechanisms.
StatusUnresolved
High

Rate limit bypass via multiple addresses

H-01The rate limiting mechanism in `_depleteBuffer` and `_replenishBuffer` is applied per `_caller` address. If the `mint` function remains public, an attacker could use multiple distinct addresses to bypass the individual rate limits, effectively minting a large amount of tokens quickly by distributing the minting operations across many accounts. This undermines the intended purpose of the rate limits for controlling overall token supply.
IssueThe rate limiting mechanism in `_depleteBuffer` and `_replenishBuffer` is applied per `_caller` address. If the `mint` function remains public, an attacker could use multiple distinct addresses to bypass the individual rate limits, effectively minting a large amount of tokens quickly by distributing the minting operations across many accounts. This undermines the intended purpose of the rate limits for controlling overall token supply.
FixIf the `mint` function is intended to be public (which is highly discouraged), consider implementing a global rate limit in addition to or instead of the per-caller rate limit, or restrict the `mint` function to a single, trusted entity.
StatusUnresolved
Medium

Immutability of `lockbox` address

M-01The `lockbox` address is declared `immutable` and set in the constructor. This address is used to bypass rate limits for internal minting/burning operations. If the `lockbox` address needs to be changed in the future due to compromise, operational changes, or system evolution, it cannot be updated without a full contract upgrade, which is a more complex and risky operation than a simple parameter change.
IssueThe `lockbox` address is declared `immutable` and set in the constructor. This address is used to bypass rate limits for internal minting/burning operations. If the `lockbox` address needs to be changed in the future due to compromise, operational changes, or system evolution, it cannot be updated without a full contract upgrade, which is a more complex and risky operation than a simple parameter change.
FixRe-evaluate the necessity of `lockbox` being `immutable`. If it represents a critical operational address that might need to change, consider making it a mutable `onlyOwner` configurable variable.
StatusUnresolved
Low

Hardcoded `decimals` value

L-01The `decimals()` function is hardcoded to return `6`. While this is a valid design choice, it means the token will always have 6 decimal places. If there's a future need to change the decimal precision (e.g., for integration with other systems that expect a different standard like 18), it would require a contract upgrade.
IssueThe `decimals()` function is hardcoded to return `6`. While this is a valid design choice, it means the token will always have 6 decimal places. If there's a future need to change the decimal precision (e.g., for integration with other systems that expect a different standard like 18), it would require a contract upgrade.
FixDocument this design choice clearly. If flexibility is desired, consider making `decimals` an `immutable` variable set in the constructor or an `onlyOwner` configurable variable, though changing decimals for an existing token is generally not recommended due to ecosystem impact.
StatusUnresolved
Info

Ambiguous `burn` function naming

I-01The `burn(address _user, uint256 _amount)` function is public and allows `msg.sender` to burn tokens from `_user` if `msg.sender` has an allowance from `_user`. This behavior is typically associated with a `burnFrom` function in ERC20 standards, while a `burn` function usually implies burning tokens owned by `msg.sender`. The current naming might lead to confusion for integrators or users.
IssueThe `burn(address _user, uint256 _amount)` function is public and allows `msg.sender` to burn tokens from `_user` if `msg.sender` has an allowance from `_user`. This behavior is typically associated with a `burnFrom` function in ERC20 standards, while a `burn` function usually implies burning tokens owned by `msg.sender`. The current naming might lead to confusion for integrators or users.
FixRename the function to `burnFrom(address _user, uint256 _amount)` to align with common ERC20 naming conventions if it's intended to allow burning on behalf of others. If it's only intended for users to burn their own tokens, then the allowance check should be removed, and `_user` should be `msg.sender`.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The contract leverages OpenZeppelin's upgradeable ERC20 and Ownable patterns, providing a solid foundation for token functionality and access control (7.2 Code Security). It implements a rate limiting mechanism for minting and burning operations, intended to control token flow (7.1 Architecture). However, a critical flaw exists in the `mint` function's access control, allowing any external caller to mint tokens, which severely compromises the token's integrity (7.3 Access Control). Additionally, the per-caller rate limits could be circumvented by an attacker using multiple addresses (7.2 Code Security).

GovernanceHigh2/10

The contract's ownership is secured by a Timelock with a 24-hour delay, which is a strong governance practice for administrative functions like setting rate limits and adding/removing bridges (7.5 Governance). However, the public `mint` function introduces a critical economic risk of unlimited token inflation by any actor, rendering any governance control over token supply ineffective (7.4 Economic). This fundamental flaw undermines the economic stability of the token.

UpgradesHigh1/10

The contract utilizes the Transparent Upgradeable Proxy pattern, with the proxy admin owned by a Timelock, ensuring a secure and controlled upgrade path (7.7 Upgrades). The `initialize` function is correctly implemented to prevent re-initialization. The immutability of the `lockbox` address, while a design choice, means it cannot be altered without an upgrade, which could be a minor operational constraint (7.8 Operations).

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
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

92.4% in top 10
3.3% in wallets89.0% in contracts
Effective Concentration38.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

$261.9K across 6 pairs
AerodromeUSDCanalysed$119.4K45.6%AerodromecbBTC$77.5K29.6%AerodromeWETH$42.4K16.2%PancakeswapUSDC$17.6K6.7%Uniswap v3USDC$5.0K1.9%AerodromeUSDC$00.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 Holder52.7%
Top-3 Unlocked98.8%

Key Addresses

6 addresses
Deployer
0xa7ec…d9ba
Unlocked LP Held By
0x84cd…984e0xf883…4aa50x5457…f5fa0x120d…33b50x5a01…a692

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 — Timelock 24h delay
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (92.4% total → 38.9% effective; 3.3% in EOAs, 89.0% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 52.7% (independent LP — depth risk, pool = 46% of DEX liquidity)
  • LP top3 unlocked holders = 98.8% (independent LP — depth risk, pool = 46% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 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
Metronome Synth ETH (MSETH)High RiskPingHigh RiskVenice Token (VVV)High RiskAvantis (AVNT)High RiskSupergemma4-26b-multimodal (SUPERGEMMA)High RiskACUHigh Risk

Would You Like a More Detailed Audit of OpenUSDT?

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

Get Detailed Audit