Quantum Audit Logo

Is VANRY a Scam?

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

VANRY VANRY
0x0784…8b63
Base Not verifiedLast checked 3d ago 1 audit on record New Launch · 20h old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The audit focuses on the provided Solidity code snippets for an ERC20 token, incorporating burnable and pausable functionalities, largely based on OpenZeppelin standards. A critical vulnerability was identified regarding the absence of explicit access control mechanisms for core administrative functions within the provided contracts. This necessitates careful implementation in the final inheriting contract to prevent unauthorized operations. Other findings include potential centralization risks and a known ERC20 `approve` race condition.

1 Critical1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (20h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$12.9K
Liquidity
$185.9K
Price
$0.0006045
Token Age
20h
Top 10 Holders
94.6%

Security Findings

1 Crit1 Low1 Info
Critical

Missing Access Control Implementation for Core Functions

C-01The provided `ERC20Burnable` and `ERC20Pausable` contracts define `internal virtual` functions (`_mint`, `_burn`, `_pause`, `_unpause`) and `public virtual` functions (`burn`, `burnFrom`) that are critical for token management. However, these contracts themselves do not implement any access control mechanisms (e.g., `onlyOwner`, `onlyRole`) to restrict who can call these functions. While these are intended to be overridden by an inheriting contract, if the final token contract fails to implement proper access control, these functions could be callable by unauthorized addresses. This could lead to arbitrary minting, burning, or pausing of the token, severely compromising its integrity and va…
IssueThe provided `ERC20Burnable` and `ERC20Pausable` contracts define `internal virtual` functions (`_mint`, `_burn`, `_pause`, `_unpause`) and `public virtual` functions (`burn`, `burnFrom`) that are critical for token management. However, these contracts themselves do not implement any access control mechanisms (e.g., `onlyOwner`, `onlyRole`) to restrict who can call these functions. While these are intended to be overridden by an inheriting contract, if the final token contract fails to implement proper access control, these functions could be callable by unauthorized addresses. This could lead to arbitrary minting, burning, or pausing of the token, severely compromising its integrity and va…
FixThe inheriting token contract MUST implement robust access control for all administrative functions. For `_mint`, `_burn`, `_pause`, and `_unpause`, ensure that the overriding functions are protected by appropriate modifiers (e.g., `onlyOwner`, `onlyMinterRole`, `onlyPauserRole`). For `burn` and `burnFrom`, ensure that the `_msgSender()` has the necessary permissions or that these functions are only callable by authorized roles if they are not intended for general public use. Consider using Ope…
StatusUnresolved
Low

Centralization Risk

L-01Assuming proper access control is implemented in the final token contract (not provided), it is highly probable that a single address or a small set of addresses will hold significant control over token operations, such as pausing transfers, minting new tokens, or burning tokens. This introduces a centralization risk where a compromised private key or a malicious actor with control over these addresses could manipulate the token supply or halt operations. This relates to 7.3 Access Control and 7.4 Economic.
IssueAssuming proper access control is implemented in the final token contract (not provided), it is highly probable that a single address or a small set of addresses will hold significant control over token operations, such as pausing transfers, minting new tokens, or burning tokens. This introduces a centralization risk where a compromised private key or a malicious actor with control over these addresses could manipulate the token supply or halt operations. This relates to 7.3 Access Control and 7.4 Economic.
FixTo mitigate centralization risks, consider implementing a multi-signature wallet for the addresses controlling critical administrative roles. For long-term decentralization, explore integrating a governance mechanism that allows token holders or a decentralized autonomous organization (DAO) to manage these privileged functions.
StatusUnresolved
Info

ERC20 `approve` Race Condition

I-01The standard ERC20 `approve` function is susceptible to a known front-running vulnerability. If a user first approves an amount, then decides to decrease it, a malicious spender could observe the transaction, front-run the decrease, spend the original allowance, and then the decrease transaction would go through, potentially allowing the spender to spend more than the intended final allowance. While OpenZeppelin's `increaseAllowance` and `decreaseAllowance` functions are provided to mitigate this specific scenario, the base `approve` function itself remains vulnerable. This is a general ERC20 design consideration rather than a flaw in this specific implementation. This relates to 7.2 Code S…
IssueThe standard ERC20 `approve` function is susceptible to a known front-running vulnerability. If a user first approves an amount, then decides to decrease it, a malicious spender could observe the transaction, front-run the decrease, spend the original allowance, and then the decrease transaction would go through, potentially allowing the spender to spend more than the intended final allowance. While OpenZeppelin's `increaseAllowance` and `decreaseAllowance` functions are provided to mitigate this specific scenario, the base `approve` function itself remains vulnerable. This is a general ERC20 design consideration rather than a flaw in this specific implementation. This relates to 7.2 Code S…
FixUsers should be advised to use `increaseAllowance` and `decreaseAllowance` instead of directly calling `approve` when modifying an existing allowance. If `approve` must be used to change an existing allowance, it is best practice to first set the allowance to zero before setting the new allowance, although this requires two transactions.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract utilizes well-regarded OpenZeppelin libraries for ERC20, Pausable, and Burnable functionalities, which generally ensures robust and audited implementations for common token operations (7.2 Code Security). The use of `unchecked` blocks is appropriately guarded by `require` statements, preventing integer underflows in critical balance updates. However, a significant concern (7.3 Access Control) is the lack of explicit access control for administrative functions like `_mint`, `_burn`, `_pause`, and `_unpause` within the provided code, which are marked as `virtual` and require proper implementation in the inheriting contract to prevent unauthorized execution.

GovernanceHigh1/10

The provided contracts do not implement complex economic models or governance mechanisms (7.4 Economic, 7.5 Governance). It represents a standard ERC20 token with basic functionalities. The primary economic risk stems from the potential for centralized control over minting, burning, and pausing, which could impact token supply and transferability if not properly managed by the final token contract's access control.

UpgradesMedium4/10

The contract is not identified as a proxy and does not implement any upgradeability patterns (7.7 Upgrades). Therefore, its code is immutable once deployed. Any future changes would require a new deployment and migration of assets, which is a standard approach for non-upgradeable contracts.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyPass

Holder Composition

94.6% in top 10
24.9% in wallets69.6% in contracts
Effective Concentration52.8%

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

$185.9K

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

2 addresses
Deployer
0x6e5c…ad0c
Unlocked LP Held By
0x375f…9491

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, but capped at 0.0%/year
  • Top-10 concentration > 50% (94.6% total → 52.8% effective; 24.9% in EOAs, 69.6% in contracts — heavy)
  • 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)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 24h (brand new — bot activity, unproven)
  • 1 Critical 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
RecallCritical RiskXMAQUINA (DEUS)Critical RiskTownsCritical RiskICPCritical RiskGAME by Virtuals (GAME)Critical RiskThe White Wolf (WOLF)Critical Risk

Would You Like a More Detailed Audit of VANRY?

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

Get Detailed Audit