Quantum Audit Logo

Is Umia a Scam?

Early-stage security check — honeypot & rug-pull analysis

Umia UMIA
0x56ab…ba7d
Base Not verifiedLast checked 3d ago 1 audit on record New Launch · 21h old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The VentureToken contract is an ERC-20 compliant token with pausable and ownable functionalities, built upon battle-tested OpenZeppelin libraries. The primary risks identified are related to the high degree of centralization of power vested in the contract owner, who can mint, burn, pause transfers, and transfer ownership. While the code quality is high due to OpenZeppelin's robust implementation, the extensive owner privileges introduce significant governance and economic risks.

1 High1 Medium2 Informational
! Early-stage analysis. This token has limited on-chain history (21h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$1.40M
Liquidity
$3.06M
Price
$0.5638
Token Age
21h
Top 10 Holders
64.0%

Security Findings

1 High1 Med2 Info
High

Centralized Control by Owner

H-01The `owner` address has exclusive control over several critical functions, including `mint(address to, uint256 amount)`, `burn(address from, uint256 amount)`, `pause()`, `unpause()`, and `transferOwnership(address newOwner)`. This grants the owner the ability to arbitrarily increase or decrease the token supply, halt all token transfers, and transfer this extensive control to any other address. A compromise of the owner's private key or malicious intent by the owner could lead to severe economic manipulation or a complete denial of service for token holders (7.3 Access Control, 7.4 Economic, 7.5 Governance).
IssueThe `owner` address has exclusive control over several critical functions, including `mint(address to, uint256 amount)`, `burn(address from, uint256 amount)`, `pause()`, `unpause()`, and `transferOwnership(address newOwner)`. This grants the owner the ability to arbitrarily increase or decrease the token supply, halt all token transfers, and transfer this extensive control to any other address. A compromise of the owner's private key or malicious intent by the owner could lead to severe economic manipulation or a complete denial of service for token holders (7.3 Access Control, 7.4 Economic, 7.5 Governance).
FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the owner address to require multiple approvals for critical operations. Alternatively, consider integrating a decentralized governance mechanism to distribute control over these sensitive functions among token holders or a council. Clearly document the owner's capabilities and the security measures in place for the owner's address.
StatusUnresolved
Medium

Pausability as a Denial of Service Vector

M-01The `pause()` function, callable only by the owner, can halt all token transfers (excluding minting and burning, as per the custom `_update` logic). While intended for emergency situations, this functionality allows the owner to unilaterally freeze user funds and prevent any token movement. This represents a significant denial of service risk for token holders if the owner acts maliciously or is compromised (7.3 Access Control, 7.8 Operations).
IssueThe `pause()` function, callable only by the owner, can halt all token transfers (excluding minting and burning, as per the custom `_update` logic). While intended for emergency situations, this functionality allows the owner to unilaterally freeze user funds and prevent any token movement. This represents a significant denial of service risk for token holders if the owner acts maliciously or is compromised (7.3 Access Control, 7.8 Operations).
FixDefine clear criteria and a transparent process for when the `pause()` function can be invoked. Consider implementing a time-locked pause or a multi-signature requirement for pausing to introduce a delay or additional checks before activation. Communicate the purpose and implications of pausability to users.
StatusUnresolved
Info

Minting and Burning Unaffected by Pause State

I-01The custom `_update` function in `VentureToken` includes a condition `if (paused() && from != address(0) && to != address(0)) revert EnforcedPause();`. This specific logic means that while regular transfers are paused, operations involving `address(0)` (i.e., `_mint` where `from` is `address(0)` and `_burn` where `to` is `address(0)`) are not affected by the `paused()` state. The owner can still mint and burn tokens even when the token is paused (7.1 Architecture, 7.2 Code Security).
IssueThe custom `_update` function in `VentureToken` includes a condition `if (paused() && from != address(0) && to != address(0)) revert EnforcedPause();`. This specific logic means that while regular transfers are paused, operations involving `address(0)` (i.e., `_mint` where `from` is `address(0)` and `_burn` where `to` is `address(0)`) are not affected by the `paused()` state. The owner can still mint and burn tokens even when the token is paused (7.1 Architecture, 7.2 Code Security).
FixThis is a deliberate design choice. Ensure this behavior is clearly documented and understood by all stakeholders. If the intention was for minting and burning to also be paused, the `_update` logic would need to be adjusted to remove the `from != address(0) && to != address(0)` conditions from the pause check.
StatusUnresolved
Info

Reliance on OpenZeppelin Libraries

I-02The `VentureToken` contract extensively utilizes well-audited and widely adopted OpenZeppelin contracts (ERC20, ERC20Pausable, Ownable, ERC165). This practice significantly enhances the security posture of the contract by building upon battle-tested and community-vetted codebases, reducing the surface area for novel vulnerabilities (7.1 Architecture, 7.2 Code Security).
IssueThe `VentureToken` contract extensively utilizes well-audited and widely adopted OpenZeppelin contracts (ERC20, ERC20Pausable, Ownable, ERC165). This practice significantly enhances the security posture of the contract by building upon battle-tested and community-vetted codebases, reducing the surface area for novel vulnerabilities (7.1 Architecture, 7.2 Code Security).
FixContinue to monitor OpenZeppelin's security advisories and updates. Ensure that the specific versions of OpenZeppelin contracts used are compatible and do not contain known vulnerabilities. Regularly review dependencies for any security patches.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The VentureToken contract demonstrates strong technical foundations by inheriting from well-audited OpenZeppelin contracts (ERC20, ERC20Pausable, Ownable, ERC165). This significantly reduces the likelihood of common coding vulnerabilities (7.2 Code Security). The contract correctly implements the ERC-20 standard and custom interfaces (7.1 Architecture). However, the `_update` override in VentureToken deviates from standard ERC20Pausable behavior, allowing minting and burning even when the token is paused, which is a specific design choice (7.2 Code Security).

GovernanceHigh2/10

The contract exhibits a high degree of centralization, with the `owner` address possessing extensive control over critical functions (7.3 Access Control). The owner can `mint` new tokens, `burn` existing tokens, `pause` all token transfers, and `transferOwnership` to any address (7.4 Economic). This concentration of power means that a compromise of the owner's private key or malicious action by the owner could lead to severe economic consequences, including inflation, deflation, or a complete halt of token utility (7.5 Governance).

UpgradesMedium4/10

The VentureToken contract is implemented as a standard, non-upgradeable contract. There are no proxy patterns or upgrade mechanisms in place (7.7 Upgrades). This eliminates upgrade-related risks such as proxy initialization errors, storage collisions, or logic inconsistencies between implementation versions. The contract's logic is immutable once deployed.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

64.0% in top 10
6.9% in wallets57.1% in contracts
Effective Concentration29.7%

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

$3.17M across 12 pairs
Uniswap v4USDCanalysed$3.06M96.6%Uniswap v4USDC$93.1K2.9%Uniswap v4USDC$9.1K0.3%Uniswap v4USDC$2.4K0.1%Uniswap v4ETH$1.7K0.1%Uniswap v3WETH$4010.0%
Show 4 more pairsShow less
Uniswap v3USDC$940.0%Uniswap v4USDC$680.0%Uniswap v4ETH$520.0%Uniswap v3USDC$300.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 Holder62.9%
Top-3 Unlocked91.2%

Key Addresses

11 addresses
Deployer
0x81a1…5fde
Unlocked LP Held By
0x575e…fe980x4dd2…29560x73e3…93d50xe33c…b16d0x8df3…c1020x2992…2ffd0x670e…2dfe0x189d…1e630xff4a…3f450xd7a4…3bfb

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 NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Top-10 concentration > 20% (64.0% total → 29.7% effective; 6.9% in EOAs, 57.1% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 62.9% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • LP top3 unlocked holders = 91.2% (independent LP — depth risk, pool = 97% of DEX liquidity)
  • Token age < 24h (brand new — bot activity, unproven)
  • 1 High finding(s) from audit
  • 1 Medium 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
VelvetHigh RiskDiemHigh RiskjesseHigh RiskRipe DAO Governance Token (RIPE)High RiskJito Staked SOL (JITOSOL)High RiskDolphin (POD)High Risk

Would You Like a More Detailed Audit of Umia?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit