Quantum Audit Logo

Is Vision Safe?

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

Is this your token? Publish your own audit on this page →

Vision VSN
0x699c…f753
Ethereum Not verifiedLast checked 3d ago 1 audit on record
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The VisionToken contract is an upgradeable ERC-20 token utilizing OpenZeppelin's battle-tested libraries for core functionalities, access control, pausing, and UUPS upgradeability. The contract demonstrates good adherence to established patterns for upgradeable tokens and includes basic input validation. However, the design centralizes significant power in specific roles (minting, pausing, upgrading, and overall administration), which, if compromised or misused, could lead to severe economic or operational consequences. Recommendations focus on decentralizing control through multi-signature wallets and implementing time-locks for critical operations.

1 Critical2 High1 Medium1 Informational
Volume 24h
$27.1K
Liquidity
$3.42M
Price
$0.04135
Token Age
1y
Top 10 Holders
97.3%

Security Findings

Critical

Centralized Control of Critical Roles

C-01The `VisionToken` contract relies on several highly privileged roles: `DEFAULT_ADMIN_ROLE` (can grant/revoke any role), `MINTER_ROLE` (unlimited token minting), `PAUSER_ROLE` (can halt all transfers), and `UPGRADER_ROLE` (can change contract logic). All these roles are initially assigned in the `initialize` function. If the addresses assigned to these roles, particularly the `roleAdmin` for `DEFAULT_ADMIN_ROLE`, are single Externally Owned Accounts (EOAs), they represent single points of failure. A compromise of any of these keys could lead to complete system control, economic manipulation, or operational shutdown (7.3 Access Control, 7.8 Operations).
IssueThe `VisionToken` contract relies on several highly privileged roles: `DEFAULT_ADMIN_ROLE` (can grant/revoke any role), `MINTER_ROLE` (unlimited token minting), `PAUSER_ROLE` (can halt all transfers), and `UPGRADER_ROLE` (can change contract logic). All these roles are initially assigned in the `initialize` function. If the addresses assigned to these roles, particularly the `roleAdmin` for `DEFAULT_ADMIN_ROLE`, are single Externally Owned Accounts (EOAs), they represent single points of failure. A compromise of any of these keys could lead to complete system control, economic manipulation, or operational shutdown (7.3 Access Control, 7.8 Operations).
FixImplement multi-signature wallets (e.g., Gnosis Safe) for all critical roles, especially `DEFAULT_ADMIN_ROLE`, `MINTER_ROLE`, and `UPGRADER_ROLE`. This distributes control and requires multiple approvals for sensitive actions, significantly reducing the risk of a single point of failure. For `PAUSER_ROLE`, a multi-sig is also recommended.
StatusUnresolved
High

Unlimited Minting Capability

H-01The `MINTER_ROLE` has the ability to mint an arbitrary amount of tokens to any address via the `mint` function. This unlimited minting capability poses a significant economic risk (7.4 Economic). If the `MINTER_ROLE` is compromised or misused, it could lead to hyperinflation, devaluing the token for all holders and undermining the protocol's economic stability.
IssueThe `MINTER_ROLE` has the ability to mint an arbitrary amount of tokens to any address via the `mint` function. This unlimited minting capability poses a significant economic risk (7.4 Economic). If the `MINTER_ROLE` is compromised or misused, it could lead to hyperinflation, devaluing the token for all holders and undermining the protocol's economic stability.
FixIf unlimited minting is not strictly necessary for the protocol's design, consider implementing safeguards. This could include setting a maximum total supply, implementing a minting rate limit, or requiring a timelock for large minting operations. Ensure the `MINTER_ROLE` is controlled by a robust multi-signature wallet with strict governance procedures.
StatusUnresolved
High

Upgradeability Risk

H-02The contract utilizes the UUPS proxy pattern, allowing its implementation logic to be upgraded by the `UPGRADER_ROLE`. While upgradeability offers flexibility for bug fixes and feature enhancements, it introduces inherent risk (7.7 Upgrades). A malicious or buggy upgrade could introduce new vulnerabilities, freeze user funds, or alter tokenomics, potentially leading to a complete system compromise. The `UPGRADER_ROLE` holds significant power over the contract's future behavior.
IssueThe contract utilizes the UUPS proxy pattern, allowing its implementation logic to be upgraded by the `UPGRADER_ROLE`. While upgradeability offers flexibility for bug fixes and feature enhancements, it introduces inherent risk (7.7 Upgrades). A malicious or buggy upgrade could introduce new vulnerabilities, freeze user funds, or alter tokenomics, potentially leading to a complete system compromise. The `UPGRADER_ROLE` holds significant power over the contract's future behavior.
FixEnsure the `UPGRADER_ROLE` is controlled by a highly secure multi-signature wallet with a robust governance process. Implement a timelock for upgrade proposals to allow community review and reaction time before an upgrade is executed. Thoroughly audit and test all new implementation contracts before deployment to the production environment.
StatusUnresolved
Medium

Pausing Mechanism Centralization

M-01The `PAUSER_ROLE` has the ability to pause and unpause all token transfers and approvals via the `pause()` and `unpause()` functions. While this feature can be valuable for emergency situations (e.g., mitigating an exploit), it also centralizes significant operational control (7.8 Operations). A malicious or compromised `PAUSER_ROLE` could halt legitimate user activity, disrupt liquidity, and cause market instability.
IssueThe `PAUSER_ROLE` has the ability to pause and unpause all token transfers and approvals via the `pause()` and `unpause()` functions. While this feature can be valuable for emergency situations (e.g., mitigating an exploit), it also centralizes significant operational control (7.8 Operations). A malicious or compromised `PAUSER_ROLE` could halt legitimate user activity, disrupt liquidity, and cause market instability.
FixControl the `PAUSER_ROLE` with a multi-signature wallet to prevent a single point of failure. Clearly define and document the specific conditions under which pausing is permissible. Consider implementing a timelock for the `unpause()` function to prevent immediate re-enablement after a malicious pause, allowing time for intervention.
StatusUnresolved
Info

Lack of Time-locks for Critical Operations

I-01The contract does not implement time-locks for critical operations such as contract upgrades, significant token minting, or changes to privileged roles. While the use of multi-signature wallets mitigates some risk, a time-lock would provide an additional layer of security by introducing a delay between the initiation and execution of a sensitive action (7.5 Governance, 7.8 Operations). This delay allows for community review, detection of malicious intent, and potential intervention.
IssueThe contract does not implement time-locks for critical operations such as contract upgrades, significant token minting, or changes to privileged roles. While the use of multi-signature wallets mitigates some risk, a time-lock would provide an additional layer of security by introducing a delay between the initiation and execution of a sensitive action (7.5 Governance, 7.8 Operations). This delay allows for community review, detection of malicious intent, and potential intervention.
FixConsider implementing time-locks for all highly sensitive operations, including contract upgrades, large token mints, and changes to critical roles (e.g., `DEFAULT_ADMIN_ROLE`, `MINTER_ROLE`, `UPGRADER_ROLE`). This enhances transparency and provides a crucial window for the community or governance to react to potentially harmful actions.
StatusUnresolved

Category Ratings

TechnicalHigh3/10

The contract leverages well-audited OpenZeppelin upgradeable libraries, enhancing code security and adherence to established patterns (7.2 Code Security). Input validations for zero amounts and addresses are correctly implemented, reducing common error vectors. However, the reliance on a single `UPGRADER_ROLE` for contract logic changes introduces a significant technical risk (7.7 Upgrades), as a compromised key could lead to arbitrary code execution. The `_authorizeUpgrade` function correctly restricts upgrade permissions to this role.

GovernanceHigh1/10

The contract implements a robust role-based access control system using OpenZeppelin's `AccessControlUpgradeable` (7.3 Access Control), defining distinct roles for administration, pausing, minting, and upgrading. However, this design centralizes significant power in specific roles, particularly the `MINTER_ROLE` which can mint unlimited tokens, posing a high economic risk (7.4 Economic) due to potential inflation. The `PAUSER_ROLE` also holds considerable power to halt all token transfers (7.8 Operations), which could disrupt liquidity.

UpgradesHigh1/10

The contract correctly utilizes the UUPS proxy pattern for upgradeability, allowing future enhancements and bug fixes (7.7 Upgrades). The `_authorizeUpgrade` function is properly secured by the `UPGRADER_ROLE`, ensuring only authorized entities can initiate upgrades. However, the inherent nature of upgradeability, coupled with the centralized control of the `UPGRADER_ROLE`, presents a high risk, as a compromised role could lead to malicious contract logic deployment without sufficient time for community review or intervention.

Security Checklist

Contract VerifiedPass
Ownership Renounced?
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

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

Holder Composition

32.6% in wallets64.8% in contracts
Effective Concentration58.5%

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

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 Holder98.7%
Top-3 Unlocked100.0%

Key Addresses

Deployer
0x85c5…a688
Unlocked LP Held By
0xa1e2…58400xa072…e9000x1cf0…50df

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

What Raised This Score

  • 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% (97.3% total → 58.5% effective; 32.6% in EOAs, 64.8% in contracts — heavy)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 98.7% (independent LP — depth risk, pool = 67% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 67% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 2 High finding(s) from audit
  • 1 Medium 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

tapCritical RiskHumanity (H)Critical RiskPunkStrategy (PNKSTR)Critical RiskusocksCritical RiskSpaceX xStock (SPCXX)Critical RiskCaldera (ERA)Critical 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