Quantum Audit Logo

Is Uniswap Safe?

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

Is this your token? Publish your own audit on this page →

Uniswap UNI
0xbf51…e9b1
BNB Chain
Not verifiedThis 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 today 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The audited contract is a BEP20 token implementation designed for upgradeability via a proxy. It correctly utilizes `SafeMath` for arithmetic safety and adheres to standard patterns for upgradeable contracts. The primary risk identified is the centralized control over token minting, which allows the owner to increase the total supply, posing a significant economic and governance risk. Other findings include the use of an older Solidity version and the standard ERC-20 `approve` front-running vulnerability.

1 High1 Medium1 Low1 Informational
Volume 24h
$112.7K
Liquidity
$1.56M
Price
$10.1900
Token Age
11mo
Top 10 Holders
53.8%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Minting Capability

H-01The `mint` function, protected by the `onlyOwner` modifier and an `_mintable` flag, allows the contract owner to create an arbitrary amount of new tokens. If `_mintable` is true, this capability grants the owner significant power to inflate the token supply, leading to potential devaluation for existing token holders. This introduces a high economic risk and centralizes control over the token's monetary policy.
IssueThe `mint` function, protected by the `onlyOwner` modifier and an `_mintable` flag, allows the contract owner to create an arbitrary amount of new tokens. If `_mintable` is true, this capability grants the owner significant power to inflate the token supply, leading to potential devaluation for existing token holders. This introduces a high economic risk and centralizes control over the token's monetary policy.
FixClearly define and communicate the token's minting policy. If a fixed supply is intended, ensure the `_mintable` flag is set to `false` during initialization and consider removing or disabling the `mint` function permanently. If minting is a desired feature, implement robust governance mechanisms (e.g., a multi-signature wallet or DAO) to control the `owner` address and the minting process, distributing control and increasing transparency.
StatusUnresolved
Medium

Older Solidity Compiler Version

M-01The contract uses `pragma solidity ^0.6.0`. While `SafeMath` is used to mitigate integer overflow/underflow, using an older compiler version means the contract does not benefit from security enhancements, optimizations, and built-in safety features (like default overflow checks for `uint256` in 0.8.x) present in newer Solidity versions. This can lead to increased technical debt and potentially missed security improvements.
IssueThe contract uses `pragma solidity ^0.6.0`. While `SafeMath` is used to mitigate integer overflow/underflow, using an older compiler version means the contract does not benefit from security enhancements, optimizations, and built-in safety features (like default overflow checks for `uint256` in 0.8.x) present in newer Solidity versions. This can lead to increased technical debt and potentially missed security improvements.
FixConsider upgrading the contract to a more recent and actively maintained Solidity version (e.g., 0.8.x). This would allow the contract to leverage modern compiler features, potentially simplify code by removing explicit `SafeMath` calls, and benefit from ongoing security improvements in the language.
StatusUnresolved
Low

Standard ERC-20 `approve` Front-Running Vulnerability

L-01The `approve` function, as implemented in the ERC-20 standard, is susceptible to a known front-running attack. If a user attempts to change an allowance from a non-zero value to another non-zero value, a malicious spender could front-run the transaction, spend the original allowance, and then allow the new allowance to be set, effectively spending more than intended. While `increaseAllowance` and `decreaseAllowance` functions are provided to mitigate this, the base `approve` function remains.
IssueThe `approve` function, as implemented in the ERC-20 standard, is susceptible to a known front-running attack. If a user attempts to change an allowance from a non-zero value to another non-zero value, a malicious spender could front-run the transaction, spend the original allowance, and then allow the new allowance to be set, effectively spending more than intended. While `increaseAllowance` and `decreaseAllowance` functions are provided to mitigate this, the base `approve` function remains.
FixAdvise users and integrated protocols to prefer using `increaseAllowance` and `decreaseAllowance` over direct `approve` calls when modifying existing allowances. If `approve` must be used, recommend setting the allowance to zero first, then to the desired new value, in two separate transactions.
StatusUnresolved
Info

Truncated Internal Function `_burnFrom`

I-01The provided source code for the internal function `_burnFrom` is truncated. While this function is internal and not directly exposed via the public interface, a complete security assessment would ideally require the full and untruncated code to ensure its logic is sound and free of vulnerabilities.
IssueThe provided source code for the internal function `_burnFrom` is truncated. While this function is internal and not directly exposed via the public interface, a complete security assessment would ideally require the full and untruncated code to ensure its logic is sound and free of vulnerabilities.
FixEnsure that all source code, including internal helper functions, is fully available and verified for comprehensive auditing and transparency.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract demonstrates good technical practices, including the consistent use of `SafeMath` (7.2 Code Security) to prevent integer overflows/underflows. It correctly implements the `Initializable` pattern for proxy compatibility, ensuring proper state initialization (7.1 Architecture). However, the use of Solidity `^0.6.0` (7.2 Code Security) is an older version, which might lack modern compiler optimizations and built-in safety features. Additionally, the standard ERC-20 `approve` function remains susceptible to front-running (7.2 Code Security), although `increaseAllowance` and `decreaseAllowance` functions are provided to mitigate this.

GovernanceHigh3/10

The contract features a centralized ownership model where a single `_owner` address controls critical functions (7.3 Access Control). Specifically, the `mint` function allows the owner to create an unlimited supply of tokens if the `_mintable` flag is set to true during initialization (7.4 Economic). This introduces significant inflationary risk and centralizes control over the token's supply, which can severely impact its economic stability and trust (7.5 Governance). The `transferOwnership` function allows the owner to transfer this power, but it remains a single point of control.

UpgradesHigh1/10

The contract is designed as an implementation for an upgradeable proxy, correctly inheriting from `Initializable` and having an empty constructor (7.7 Upgrades). The state variables are declared in a manner consistent with upgradeability best practices, minimizing storage layout conflicts during future upgrades. The `initialize` function ensures proper setup of token parameters and ownership upon deployment or upgrade, preventing re-initialization.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminEOA (single key controls upgrades)
ImplementationVerified source

Holder Composition

53.8% in top 10
25.2% in wallets28.7% in contracts
Effective Concentration36.6%

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

$4.80M across 30 pairs
Pancakeswap v2VINanalysed$1.56M32.5%Uniswap v2ZEC$1.30M27.1%Pancakeswap v2YFSX$459.1K9.6%Pancakeswap v2WBNB$454.4K9.5%UniswapWBNB$201.2K4.2%Pancakeswap v3WBNB$194.5K4.1%
Show 4 more pairsShow less
Pancakeswap v3USDC$146.3K3.1%UniswapUSDT$131.1K2.7%UniswapWBNB$99.4K2.1%Pancakeswap v3USDT$57.6K1.2%

The 20 remaining pairs hold $194.4K between them and are not listed.

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 Holder49.1%
Top-3 Unlocked74.9%

Key Addresses

11 addresses
Deployer
0x81b7…3cce
Unlocked LP Held By
0x73fe…e24e0xa5f8…76520x81ff…cb730xae1c…57110x5a1f…a0cd0x9a2c…f69e0x5f91…ba860x1609…9d210x7b55…75bd0x5334…a6ca

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

What Raised This Score

9 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Admin is EOA (single key controls upgrades)
  • Top-10 concentration > 30% (53.8% total → 36.6% effective; 25.2% in EOAs, 28.7% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 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
Billions Network Token (BILL)High RiskHemiHigh RiskAntFunHigh RiskQuack AI Token (Q)High RiskHoloworld AI (HOLO)High RiskPowerHigh Risk

Would You Like a More Detailed Audit of Uniswap?

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

Get Detailed Audit