Quantum Audit Logo
Launch App

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

Is OpenUSDT Safe?

OUSDTBase
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
Technical4/10Governance2/10Upgrades1/10Checks passed1 of 5Findings1 Critical · 1 High · 1 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The XERC20 contract, an upgradeable ERC-20 token, was audited for security vulnerabilities.

Read the full analysis
What raised the score
  • Ownership not renounced — Timelock 24h delay
  • 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 = 52.7%
  • LP top3 unlocked holders = 98.8%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

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
89.0%Contracts3.3%7.6%
89.0%Contracts3.3%7.6%
ContractsWalletsEveryone elseBubble area = share of supply
92.4%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking89.0%
  • Walletsanonymous holders, free to sell3.3%
  • Everyone elsethe rest of the supply7.6%
Effective concentrationwhat the score reads38.9%
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$261.9K across 6 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$119.4KShare of depth45.6%
Top-1 Unlocked Holder52.7%
Top-3 Unlocked98.8%
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.

Security Findings

1 Critical1 High1 Medium1 Low1 Info
Critical

Public mint function allows arbitrary token creation

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

Issue

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

Fix

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

Status

Unresolved

High

Rate limit bypass via multiple addresses

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

Issue

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

Fix

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

Status

Unresolved

Medium

Immutability of lockbox address

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

Issue

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

Fix

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

Status

Unresolved

Low

Hardcoded decimals value

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

Issue

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

Fix

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

Status

Unresolved

Info

Ambiguous burn function naming

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical4/10Medium risk

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

Governance2/10High risk

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.

Upgrades1/10High risk

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

Final RecommendationWhat to do about this score

The primary recommendation is to immediately address the critical vulnerability in the mint function by restricting its access to authorized roles only.

This is paramount to prevent uncontrolled token inflation and maintain the token's economic integrity. Additionally, review the rate limiting mechanism to ensure it effectively controls overall token supply, especially if multiple actors can trigger minting. Consider making the lockbox address configurable by the owner to allow for future operational flexibility without requiring a full contract upgrade.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBase
Token age1y
Contract0x1217…e189
Deployer0xa7ec…d9ba
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → Timelock
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
OpenUSDT 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, 202650Medium

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

Frequently Asked Questions

What is the OUSDT contract address?

The OpenUSDT (OUSDT) contract on Base is 0x1217bfe6c773eec6cc4a38b5dc45b92292b6e189. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is OpenUSDT a scam?

Quantum Audit's risk score for OpenUSDT is 50/100 (Medium 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 OUSDT liquidity locked?

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

Who holds OUSDT?

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

Related Audits

6 more on the recordAll audits
Metronome Synth ETHMSETH · Base50MediumPingBase50MediumCATALYSTBase50MediumGROOVEBase50MediumVenice TokenVVV · Base51MediumAvantisAVNT · Base49Medium

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