Is VANRY Safe? Smart Contract Security Analysis

Security Findings

3 Info

Info

Standard ERC20 `approve` Race Condition

I-01The ERC20 `approve` function is susceptible to a known race condition. If a user approves an allowance for a spender, and then attempts to change that allowance to a different value, a malicious spender could potentially exploit the time window between the two transactions to spend both the old and new allowances. This is a design limitation of the ERC20 standard, not an implementation flaw in OpenZeppelin's code, which even includes a warning about it.

IssueThe ERC20 `approve` function is susceptible to a known race condition. If a user approves an allowance for a spender, and then attempts to change that allowance to a different value, a malicious spender could potentially exploit the time window between the two transactions to spend both the old and new allowances. This is a design limitation of the ERC20 standard, not an implementation flaw in OpenZeppelin's code, which even includes a warning about it.

FixUsers should be advised to use `increaseAllowance` and `decreaseAllowance` functions (if available in a derived contract) instead of directly calling `approve` to modify an existing allowance. If only `approve` is available, users should first set the allowance to zero and wait for that transaction to confirm before setting the new desired allowance.

StatusUnresolved

Info

Base ERC20 Implementation Lacks Minting Mechanism

I-02The provided `ERC20` contract is a base implementation from OpenZeppelin. It includes state variables for `_totalSupply` and `_balances` but lacks any `_mint` function or other mechanism to increase `_totalSupply` or assign initial balances. As a result, `totalSupply()` will always return 0, and `balanceOf()` will always return 0 for all accounts, rendering the token unusable as a standalone asset. A derived contract is expected to implement the token creation logic.

IssueThe provided `ERC20` contract is a base implementation from OpenZeppelin. It includes state variables for `_totalSupply` and `_balances` but lacks any `_mint` function or other mechanism to increase `_totalSupply` or assign initial balances. As a result, `totalSupply()` will always return 0, and `balanceOf()` will always return 0 for all accounts, rendering the token unusable as a standalone asset. A derived contract is expected to implement the token creation logic.

FixEnsure that a derived contract implements a proper minting mechanism (e.g., using `_mint` from OpenZeppelin's `ERC20` or a custom minting function) to set the initial supply and distribute tokens, making the token functional.

StatusUnresolved

Info

Hardcoded Decimals

I-03The `decimals()` function is hardcoded to return `18`. While 18 decimals is a common standard for ERC20 tokens, imitating Ether, this value cannot be changed after deployment. If a different decimal precision is ever required, the contract would need to be redeployed.

IssueThe `decimals()` function is hardcoded to return `18`. While 18 decimals is a common standard for ERC20 tokens, imitating Ether, this value cannot be changed after deployment. If a different decimal precision is ever required, the contract would need to be redeployed.

FixIf flexibility in decimal precision is desired, consider making the `decimals` value configurable during contract construction, though this is rarely necessary for standard tokens. For most use cases, hardcoding to 18 is acceptable.

StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract utilizes the well-audited OpenZeppelin ERC20 implementation, providing a strong foundation for code security (7.2) and architecture (7.1). It adheres strictly to the ERC20 standard, ensuring broad compatibility and minimizing custom logic. The absence of complex features reduces the attack surface. A key observation is the lack of an explicit minting mechanism in this base contract, which means it requires a derived contract to become a functional token (I-02).

GovernanceHigh1/10

As a basic ERC20 token, the contract has no inherent governance (7.5) or complex economic (7.4) mechanisms. There are no custom fees, special roles, or rebase functionalities. The primary economic consideration for users is the well-known ERC20 `approve` race condition (I-01), which is a standard limitation of the ERC20 specification rather than an implementation flaw.

UpgradesMedium5/10

The contract is not designed to be upgradeable (7.7), as it does not implement any proxy patterns. This means its logic is immutable once deployed, providing certainty but requiring a new deployment for any future modifications. This design choice eliminates upgrade-related risks such as proxy initialization flaws or storage collisions.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionFail

Liquidity LockedFail

Not a ProxyPass

Holder Composition

89.6% in top 10

19.9% in wallets69.7% in contracts

Effective Concentration47.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

$1.3K across 2 pairs

Uniswap v4USDCanalysed$907 Uniswap v4USDT$409

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

0x6caf…21a9

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

7 factors

Ownership status UNKNOWN (owner could not be resolved)
Mintable supply, but capped at 2.7%/year
Top-10 concentration > 30% (89.6% total → 47.8% effective; 19.9% in EOAs, 69.7% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
Liquidity < $10k ($1,316 across 2 pairs — easily drained)
LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 69% of DEX liquidity)
LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 69% of DEX liquidity)

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

Is VANRY Safe?

Security Findings

Standard ERC20 `approve` Race Condition

Base ERC20 Implementation Lacks Minting Mechanism

Hardcoded Decimals

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Frequently Asked Questions

Related Audits

Would You Like a More Detailed Audit of VANRY?