Quantum Audit Logo

Is Vision Safe?

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

Vision VSN
0x6fbb…b74b
Arbitrum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Critical Risk
Executive 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. 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.

1 High1 Medium1 Low3 Informational
Volume 24h
$115.4K
Liquidity
$729.0K
Price
$0.04102
Token Age
8mo
Top 10 Holders
95.8%

Security Findings

1 High1 Med1 Low3 Info
High

Centralized Control of Critical Roles

H-01The `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.
IssueThe `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.
FixTransition 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.
StatusUnresolved
Medium

Potential for Supply Inflation by MINTER_ROLE

M-01The `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.
IssueThe `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.
FixImplement 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.
StatusUnresolved
Low

Lack of Timelock for Critical Operations

L-01Critical 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.
IssueCritical 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.
FixIntroduce 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.
StatusUnresolved
Info

`_disableInitializers()` in Constructor

I-01The 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.
IssueThe 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.
FixNo action required; this is a best practice.
StatusResolved
Info

Extensive Use of OpenZeppelin Upgradeable Contracts

I-02The `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).
IssueThe `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).
FixNo action required; this is a best practice.
StatusResolved
Info

Clear and Gas-Efficient Error Handling

I-03The 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).
IssueThe 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).
FixNo action required; this is a best practice.
StatusResolved

Category Ratings

TechnicalMedium6/10

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.

GovernanceHigh1/10

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.

UpgradesHigh1/10

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

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeEip1967 Uups
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

95.8% in top 10
52.1% in wallets43.7% in contracts
Effective Concentration69.6%

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

$729.0K across 2 pairs
PancakeswapUSDCanalysed$729.0K100.0%UniswapWETH$20.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

3 addresses
Deployer
0x72f4…fba3
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.

What Raised This Score

10 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

Related Audits

6 more on the record
Catena Labs (CATE)Critical RiskOrnn Exchange (ORNN)Critical RiskUnicity Labs (UNYLA)Critical RiskCoinbase Wrapped BTC (CBBTC)Critical RiskVangrid (VAN)Critical RiskMORCritical Risk

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