Quantum Audit Logo
Launch App

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

Is Vision Safe?

VSNArbitrum
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 record
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance1/10Upgrades1/10Checks passed1 of 5Findings1 High · 1 Medium · 1 Low · 3 Info6
SummaryAI Copilot

The VisionToken contract is an upgradeable ERC20 token utilizing OpenZeppelin's battle-tested libraries for core functionalities, including pausing, role-based access control, and UUPS upgradeability.

Read the full analysis
What raised the score
  • Ownership status UNKNOWN
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • 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%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 50% (95.8% total → 69.6% effective; 52.1% in EOAs, 43.7% 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)
  • 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

Security Checklist

as of audit · Sep 41 of 5 checks passed
Contract verifiedVerified
OwnershipUnknown
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
43.7%Contracts52.1%Wallets4.2%Everyone else
43.7%Contracts52.1%Wallets4.2%
ContractsWalletsEveryone elseBubble area = share of supply
95.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking43.7%
  • Walletsanonymous holders, free to sell52.1%
  • Everyone elsethe rest of the supply4.2%
Effective concentrationwhat the score reads69.6%
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$729.0K across 2 pairs

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$729.0KShare of depth100.0%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0xa072…e9000xf1b2…6a19

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

Security Findings

1 High1 Medium1 Low3 Info
High

Centralized Control of Critical Roles

The DEFAULT_ADMIN_ROLE, PAUSER_ROLE, MINTER_ROLE, and UPGRADER_ROLE are assigned to single addresses during initialization. If these addresses are externally owned accounts (EOAs), they represent single points of failure. A compromise of any of these keys would grant an attacker the ability to pause the contract, mint/burn tokens, or upgrade the contract logic, leading to severe economic or operational consequences. This impacts 7.3 Access Control, 7.4 Economic, 7.5 Governance, 7.7 Upgrades, and 7.8 Operations.H-01

Issue

The DEFAULT_ADMIN_ROLE, PAUSER_ROLE, MINTER_ROLE, and UPGRADER_ROLE are assigned to single addresses during initialization. If these addresses are externally owned accounts (EOAs), they represent single points of failure. A compromise of any of these keys would grant an attacker the ability to pause the contract, mint/burn tokens, or upgrade the contract logic, leading to severe economic or operational consequences. This impacts 7.3 Access Control, 7.4 Economic, 7.5 Governance, 7.7 Upgrades, and 7.8 Operations.

Fix

Transition control of all critical roles (DEFAULT_ADMIN_ROLE, PAUSER_ROLE, MINTER_ROLE, UPGRADER_ROLE) to a robust multi-signature wallet (e.g., Gnosis Safe) or a decentralized autonomous organization (DAO) to distribute control and reduce the risk of a single point of failure.

Status

Unresolved

Medium

Potential for Supply Inflation by MINTER_ROLE

The MINTER_ROLE has the unrestricted ability to mint an arbitrary amount of new tokens to any address. While this is an intended feature for a token with a minting mechanism, it introduces a significant economic risk (7.4 Economic). If the MINTER_ROLE is compromised or misused, it could lead to uncontrolled token supply inflation, devaluing existing tokens and harming holders.M-01

Issue

The MINTER_ROLE has the unrestricted ability to mint an arbitrary amount of new tokens to any address. While this is an intended feature for a token with a minting mechanism, it introduces a significant economic risk (7.4 Economic). If the MINTER_ROLE is compromised or misused, it could lead to uncontrolled token supply inflation, devaluing existing tokens and harming holders.

Fix

Implement strict policies and procedures for the MINTER_ROLE's operation. Consider adding rate limits or caps on minting amounts, or requiring additional governance approval for large minting operations. Ensure the MINTER_ROLE is controlled by a secure, multi-signature wallet or DAO.

Status

Unresolved

Low

Lack of Timelock for Critical Operations

Critical operations such as contract upgrades, role changes, and pausing/unpausing are not subject to a timelock. This means that an entity controlling the UPGRADER_ROLE, DEFAULT_ADMIN_ROLE, or PAUSER_ROLE can execute these actions immediately (7.3 Access Control, 7.5 Governance, 7.7 Upgrades, 7.8 Operations). This lack of a delay period prevents users from reacting to potentially malicious or erroneous changes and reduces transparency.L-01

Issue

Critical operations such as contract upgrades, role changes, and pausing/unpausing are not subject to a timelock. This means that an entity controlling the UPGRADER_ROLE, DEFAULT_ADMIN_ROLE, or PAUSER_ROLE can execute these actions immediately (7.3 Access Control, 7.5 Governance, 7.7 Upgrades, 7.8 Operations). This lack of a delay period prevents users from reacting to potentially malicious or erroneous changes and reduces transparency.

Fix

Introduce a timelock mechanism for all critical administrative functions, especially contract upgrades and significant role modifications. A timelock would enforce a delay between the proposal and execution of a change, providing a window for review and community response.

Status

Unresolved

Info

_disableInitializers() in Constructor

The contract correctly calls _disableInitializers() in its constructor. This is a crucial security measure for upgradeable contracts, preventing the initialize function from being called multiple times on the implementation contract, which could lead to state corruption or re-initialization vulnerabilities. This demonstrates good practice in 7.2 Code Security.I-01

Issue

The contract correctly calls _disableInitializers() in its constructor. This is a crucial security measure for upgradeable contracts, preventing the initialize function from being called multiple times on the implementation contract, which could lead to state corruption or re-initialization vulnerabilities. This demonstrates good practice in 7.2 Code Security.

Fix

No action required; this is a best practice.

Status

Resolved

Info

Extensive Use of OpenZeppelin Upgradeable Contracts

The VisionToken contract extensively utilizes OpenZeppelin's battle-tested upgradeable contracts (ERC20Upgradeable, ERC20PausableUpgradeable, AccessControlUpgradeable, ERC20PermitUpgradeable, UUPSUpgradeable). This approach significantly reduces the risk of common vulnerabilities and improves overall code quality, reliability, and security (7.2 Code Security).I-02

Issue

The VisionToken contract extensively utilizes OpenZeppelin's battle-tested upgradeable contracts (ERC20Upgradeable, ERC20PausableUpgradeable, AccessControlUpgradeable, ERC20PermitUpgradeable, UUPSUpgradeable). This approach significantly reduces the risk of common vulnerabilities and improves overall code quality, reliability, and security (7.2 Code Security).

Fix

No action required; this is a best practice.

Status

Resolved

Info

Clear and Gas-Efficient Error Handling

The contract defines and uses custom error types ZeroAmount() and ZeroAddress() for specific failure conditions. This practice improves code clarity, provides more specific error messages to users, and is generally more gas-efficient than using generic require statements with string messages (7.2 Code Security).I-03

Issue

The contract defines and uses custom error types ZeroAmount() and ZeroAddress() for specific failure conditions. This practice improves code clarity, provides more specific error messages to users, and is generally more gas-efficient than using generic require statements with string messages (7.2 Code Security).

Fix

No action required; this is a best practice.

Status

Resolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The VisionToken contract is an upgradeable ERC20 token utilizing OpenZeppelin's battle-tested libraries for core functionalities, including pausing, role-based access control, and UUPS upgradeability. While the technical implementation is robust and follows best practices for upgradeable contracts, the primary risks stem from the highly centralized control over critical functions such as minting, pausing, and upgrades. These roles, if compromised or misused, could lead to significant economic and operational issues for the protocol. Recommendations focus on decentralizing control and implementing timelocks for sensitive operations.

Technical6/10Medium risk

The VisionToken contract demonstrates strong technical security by inheriting from OpenZeppelin's upgradeable contracts (ERC20, Pausable, AccessControl, Permit, UUPS). This approach leverages well-audited and widely adopted code, significantly reducing the likelihood of common vulnerabilities (7.2 Code Security). Custom logic for minting, burning, pausing, and unpausing is minimal, straightforward, and includes explicit checks for zero addresses and amounts, enhancing robustness. The architecture (7.1 Architecture) is standard for an upgradeable ERC20, but the centralized nature of access control (7.3 Access Control) for critical roles like MINTER_ROLE and UPGRADER_ROLE introduces a single point of failure.

Governance1/10High risk

The economic model (7.4 Economic) relies on a MINTER_ROLE with the ability to mint an arbitrary amount of tokens, posing a significant risk of supply inflation if compromised. Governance (7.5 Governance) is highly centralized, with the DEFAULT_ADMIN_ROLE having ultimate control over all other roles, including PAUSER_ROLE and MINTER_ROLE. This centralization means a single entity or small group controls the token's supply, pausability, and administrative functions, which could lead to economic manipulation or operational halts if these roles are not managed securely, ideally by a robust multisig or DAO.

Upgrades1/10High risk

The contract utilizes the UUPS proxy pattern for upgradeability (7.7 Upgrades), which is a secure and widely accepted standard. The _authorizeUpgrade function correctly restricts upgrade permissions to the UPGRADER_ROLE. However, the absence of a timelock for upgrade operations means that an entity controlling the UPGRADER_ROLE can instantly deploy new, potentially malicious, contract logic without community oversight or a grace period for users to react. This immediate upgrade capability, combined with centralized control, presents a high operational risk (7.8 Operations).

Final RecommendationWhat to do about this score

To mitigate the identified risks, it is strongly recommended to implement a robust multi-signature wallet or a decentralized autonomous organization (DAO) for managing all critical roles, including DEFAULT_ADMIN_ROLE, PAUSER_ROLE, MINTER_ROLE, and UPGRADER_ROLE.

Additionally, consider integrating a timelock mechanism for sensitive operations such as contract upgrades and significant role changes. This would introduce a delay before execution, allowing for community review and providing a window for intervention in case of malicious or erroneous actions, thereby enhancing the overall security and decentralization of the protocol.

Contract & Record

1 audit on record
TypeERC1967Proxy
NetworkArbitrum
Token age8mo
Contract0x6fbb…b74b
Deployer0x72f4…fba3
Proxy Upgrade Controls
Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Vision security record badge

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
  1. Jul 23, 202679High
  2. Jul 23, 202666High

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

Frequently Asked Questions

What is the VSN contract address?

The Vision (VSN) contract on Arbitrum is 0x6fbbbd8bfb1cd3986b1d05e7861a0f62f87db74b. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Vision a scam?

Quantum Audit's risk score for Vision is 79/100 (High risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Mint: Mintable; Liquidity lock: Not locked; Upgradeability: Upgradeable. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is VSN liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $729.0K.

Who holds VSN?

As of Sep 4, 2026, the 10 largest holders own 95.8% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Catena LabsCATE · Arbitrum80HighOrnn ExchangeORNN · Arbitrum78HighCubedCUBE · Arbitrum80HighVangridVANG · Arbitrum80HighUnicity LabsUNYLA · Arbitrum81HighAXIS RoboticsAXROB · Arbitrum77High

Would You Like a More Detailed Audit of Vision?

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

Get Detailed Audit Is this your token? Publish your own audit on this page