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

Is VANRY a Scam?

Base

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 recordNew Launch · 20h old

Chart

72/ 100

High RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical6/10 Governance1/10 Upgrades4/10 Checks passed2 of 5 Findings1 Critical · 1 Low · 1 Info3

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.

Read the full analysis

What raised the score

Ownership status UNKNOWN
Mintable supply, but capped at 0.0%/year
Top-10 concentration > 50%
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 100.0%
LP top3 unlocked holders = 100.0%
Token age < 24h
1 Critical finding(s) from audit
1 Low finding(s) from audit

Exact 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

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.

Security Checklist

as of audit · Sep 42 of 5 checks passed

Contract verifiedVerified

OwnershipUnknown

MintMintable

Liquidity lockNot locked

UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

94.6%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking69.6%
Walletsanonymous holders, free to sell24.9%
Everyone elsethe rest of the supply5.4%

Effective concentrationwhat the score reads52.8%

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$185.9K

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$185.9KShare of depth100.0%

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

Unlocked LP held by

0x375f…9491

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

Security Findings

1 Critical1 Low1 Info

Critical

Missing Access Control Implementation for Core Functions

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

Issue

Fix

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

Status

Unresolved

Low

Centralization Risk

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

Issue

Fix

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

Status

Unresolved

Info

ERC20 `approve` Race Condition

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

Issue

Fix

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

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

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.

Technical6/10Medium risk

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.

Governance1/10High risk

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.

Upgrades4/10Medium risk

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.

Final RecommendationWhat to do about this score

It is crucial to ensure that the final token contract inheriting from these base contracts implements robust access control for all administrative functions, including _mint, _burn, _pause, _unpause, burn, and burnFrom.

Consider using a multi-signature wallet or a well-defined role-based access control system (e.g., OpenZeppelin's AccessControl contract) for these critical operations to mitigate centralization risks and enhance security. Thoroughly review the complete token contract implementation to confirm all privileged functions are adequately protected.

Contract & Record

1 audit on record

TypeToken

NetworkBase

Token age20h

Contract0x0784…8b63

Deployer0x6e5c…ad0c

Badge for your website

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

Sep 4, 202672High
Aug 12, 202679High

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

Frequently Asked Questions

What is the VANRY contract address?

The VANRY contract on Base is 0x07848a7b542a9cd856122c6c4ab9ec87c44f8b63. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.