Quantum Audit Logo
Launch App

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

Is Solana (Universal) Safe?

USOLBase
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
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical4/10Governance4/10Upgrades1/10Checks passed1 of 5Findings1 Critical · 1 High · 1 Medium · 3 Info6
SummaryAI Copilot

The audit of the WrappedAssetV2 contract, serving as the implementation for a BeaconProxy, revealed a robust ERC20 token implementation utilizing OpenZeppelin's upgradeable contracts and access control.

Read the full analysis
What raised the score
  • Ownership not renounced — Multisig
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract
  • Complex proxy pattern
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact factors
  • Ownership NOT renounced — Multisig (2-of-4)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 30% (76.6% total → 37.6% effective; 11.6% in EOAs, 65.0% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 Critical finding(s) from audit
  • 1 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

Security Checklist

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

Holders

as of audit · Sep 4, 2026
65.0%Contracts11.6%Wallets23.4%Everyone else
65.0%Contracts11.6%23.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
76.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking65.0%
  • Walletsanonymous holders, free to sell11.6%
  • Everyone elsethe rest of the supply23.4%
Effective concentrationwhat the score reads37.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$1.84M across 6 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$1.29MShare of depth70.1%
Top-1 Unlocked Holder35.3%
Top-3 Unlocked65.4%
Unlocked LP held by
0x7bc6…31e60x7d27…fd550x4701…7cfd0x97e9…f3330x6671…a1390x8809…288c0xaece…1ee10xa2f0…cba70x24d7…ac520xb53d…dc5a

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

Security Findings

1 Critical1 High1 Medium3 Info
Critical

Critical: Custom Storage Pattern Poses Upgrade Risk

The WrappedAssetV2 contract uses a custom storage pattern where WrappedAssetV2Storage is explicitly mapped to a fixed bytes32 slot (WrappedAssetV2StorageLocation) using inline assembly. This approach deviates from standard upgradeable contract storage management (e.g., using OpenZeppelin's ERC1967Upgrade or explicit storage gaps). If a future upgrade introduces new state variables or if OpenZeppelin's internal storage layout changes in a way that conflicts with this hardcoded slot, it could lead to storage collisions, data corruption, or loss of funds for users. This is a severe upgrade safety issue (7.1, 7.7).C-01

Issue

The WrappedAssetV2 contract uses a custom storage pattern where WrappedAssetV2Storage is explicitly mapped to a fixed bytes32 slot (WrappedAssetV2StorageLocation) using inline assembly. This approach deviates from standard upgradeable contract storage management (e.g., using OpenZeppelin's ERC1967Upgrade or explicit storage gaps). If a future upgrade introduces new state variables or if OpenZeppelin's internal storage layout changes in a way that conflicts with this hardcoded slot, it could lead to storage collisions, data corruption, or loss of funds for users. This is a severe upgrade safety issue (7.1, 7.7).

Fix

Refactor the storage to use OpenZeppelin's recommended upgradeable storage patterns. This typically involves inheriting from UUPSUpgradeable or TransparentUpgradeableProxy and defining storage variables directly in the contract, allowing the compiler to manage storage slots. If custom storage is absolutely necessary, ensure it is placed within an explicit storage gap to prevent future collisions.

Status

Unresolved

High

High: Centralized Control Over Token Supply and User Funds

The mint and burn functions are restricted to the MERCHANT_CONTROLLER, granting this single address complete control over the token's supply. Additionally, the setUserBlacklist function, restricted to the RESPONDER_ROLE, allows blacklisting any user, effectively freezing their funds or preventing them from receiving tokens. This high degree of centralization (7.3, 7.4) introduces significant economic risk, as a compromise or malicious action by these privileged roles could lead to arbitrary minting, burning, or censorship of user funds.H-01

Issue

The mint and burn functions are restricted to the MERCHANT_CONTROLLER, granting this single address complete control over the token's supply. Additionally, the setUserBlacklist function, restricted to the RESPONDER_ROLE, allows blacklisting any user, effectively freezing their funds or preventing them from receiving tokens. This high degree of centralization (7.3, 7.4) introduces significant economic risk, as a compromise or malicious action by these privileged roles could lead to arbitrary minting, burning, or censorship of user funds.

Fix

Ensure that the MERCHANT_CONTROLLER and RESPONDER_ROLE are controlled by robust, multi-signature wallets with high thresholds and strict operational procedures. Clearly document the scope, responsibilities, and limitations of these roles. Consider implementing time locks or additional governance checks for critical actions like large mints or widespread blacklisting.

Status

Unresolved

Medium

Medium: Immutable MERCHANT_CONTROLLER Address

The MERCHANT_CONTROLLER address is set as immutable in the constructor. This means that if the MERCHANT_CONTROLLER address needs to be changed in the future (e.g., due to compromise, operational changes, or an upgrade of the controller itself), it cannot be updated without deploying an entirely new implementation contract and performing an upgrade. This limits operational flexibility and introduces a single point of failure (7.3, 7.8).M-01

Issue

The MERCHANT_CONTROLLER address is set as immutable in the constructor. This means that if the MERCHANT_CONTROLLER address needs to be changed in the future (e.g., due to compromise, operational changes, or an upgrade of the controller itself), it cannot be updated without deploying an entirely new implementation contract and performing an upgrade. This limits operational flexibility and introduces a single point of failure (7.3, 7.8).

Fix

Consider making the MERCHANT_CONTROLLER address configurable via an access-controlled function, allowing it to be updated by the contract's admin role (e.g., the multisig). This would provide greater operational flexibility and resilience without requiring a full contract upgrade for a simple address change.

Status

Unresolved

Info

Informational: Blacklist Logic Clarity

The _update function checks $.userBlacklist[msg.sender] || $.userBlacklist[from] || $.userBlacklist[to]. While functionally correct, the check for msg.sender is often redundant when msg.sender is also from (as in a direct transfer). This does not introduce a vulnerability but could be slightly optimized for clarity or gas if desired (7.2).I-01

Issue

The _update function checks $.userBlacklist[msg.sender] || $.userBlacklist[from] || $.userBlacklist[to]. While functionally correct, the check for msg.sender is often redundant when msg.sender is also from (as in a direct transfer). This does not introduce a vulnerability but could be slightly optimized for clarity or gas if desired (7.2).

Fix

No change is strictly required as the logic is correct. For minor optimization, one could consider if msg.sender is always from in the context of _update calls from transfer and transferFrom, and potentially simplify the condition. However, the current implementation is safe.

Status

Unresolved

Info

Informational: Use of AccessControlDefaultAdminRulesUpgradeable with Delay

The contract correctly utilizes AccessControlDefaultAdminRulesUpgradeable with a ADMIN_TRANSFER_DELAY of 1 day. This is a good security practice (7.3, 7.5) as it introduces a time delay for critical administrative role changes, providing a window for detection and potential mitigation of malicious or erroneous actions.I-02

Issue

The contract correctly utilizes AccessControlDefaultAdminRulesUpgradeable with a ADMIN_TRANSFER_DELAY of 1 day. This is a good security practice (7.3, 7.5) as it introduces a time delay for critical administrative role changes, providing a window for detection and potential mitigation of malicious or erroneous actions.

Fix

Maintain this security feature. Ensure the ADMIN_TRANSFER_DELAY is appropriate for the operational security requirements of the protocol.

Status

Unresolved

Info

Informational: Correct Initialization Prevention

The WrappedAssetV2 constructor correctly calls _disableInitializers(). This prevents the implementation contract from being initialized directly, which is a crucial security measure for upgradeable contracts deployed behind a proxy (7.7).I-03

Issue

The WrappedAssetV2 constructor correctly calls _disableInitializers(). This prevents the implementation contract from being initialized directly, which is a crucial security measure for upgradeable contracts deployed behind a proxy (7.7).

Fix

No action required. This is a best practice and correctly implemented.

Status

Unresolved

Analysis

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

The audit of the WrappedAssetV2 contract, serving as the implementation for a BeaconProxy, revealed a robust ERC20 token implementation utilizing OpenZeppelin's upgradeable contracts and access control. Key features include centralized minting/burning and a user blacklist. A critical vulnerability was identified in the custom storage pattern, which poses a significant risk during future upgrades. High centralization of control for token operations and an immutable merchant controller also present notable risks.

Technical4/10Medium risk

The contract leverages battle-tested OpenZeppelin libraries for ERC20 and access control, enhancing code security (7.2). The custom blacklist logic within _update is correctly implemented to restrict transfers for blacklisted addresses. However, the use of a custom storage slot (WrappedAssetV2StorageLocation) for WrappedAssetV2Storage deviates from standard upgradeable contract patterns and introduces a high risk of storage collisions in future upgrades (7.1).

Governance4/10Medium risk

The contract implements strong access control (7.3) using AccessControlDefaultAdminRulesUpgradeable with a 1-day delay for admin role transfers, which is a good security practice. However, the mint and burn functions are highly centralized, controlled by an immutable MERCHANT_CONTROLLER address, which poses a significant economic risk (7.4) due to its power over token supply. The RESPONDER_ROLE also has the power to blacklist any user, effectively freezing their funds (7.5). The immutability of the MERCHANT_CONTROLLER limits operational flexibility (7.8).

Upgrades1/10High risk

The contract is designed as an upgradeable implementation for a BeaconProxy, correctly using Initializable and calling _disableInitializers() in its constructor. This setup generally supports safe upgrades (7.7). However, the custom storage pattern using WrappedAssetV2StorageLocation for WrappedAssetV2Storage creates a critical risk of storage collisions if future versions or OpenZeppelin library updates introduce conflicting storage variables at that specific slot, potentially leading to data corruption or loss of funds.

Final RecommendationWhat to do about this score

It is strongly recommended to address the critical storage collision vulnerability by refactoring the custom storage pattern to align with standard upgradeable storage practices, such as using explicit storage gaps or OpenZeppelin's ERC1967Upgrade storage layout.

Additionally, consider implementing a mechanism to update the MERCHANT_CONTROLLER address through a controlled, multi-signature process to enhance operational flexibility and reduce single points of failure. Ensure robust operational procedures and multi-signature controls are in place for all privileged roles, especially the MERCHANT_CONTROLLER and RESPONDER_ROLE.

Contract & Record

1 audit on record
TypeBeaconProxy
NetworkBase
Token age1y
Contract0x9b8d…db55
Deployer0x693c…47a2
Proxy Upgrade Controls
Proxy TypeBeacon
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Solana (Universal) 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. Aug 11, 202645Medium

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

Frequently Asked Questions

What is the USOL contract address?

The Solana (Universal) (USOL) contract on Base is 0x9b8df6e244526ab5f6e6400d331db28c8fdddb55. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Solana (Universal) a scam?

Quantum Audit's risk score for Solana (Universal) is 45/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; 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 USOL liquidity locked?

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

Who holds USOL?

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

Related Audits

6 more on the recordAll audits
NockchainNOCK · Base45MediumElsaBase45MediumLil Finder GuyLFG · Base45MediumAerodrome FinanceAERO · Base44MediumaeonBase46MediumSapienBase44Medium

Would You Like a More Detailed Audit of Solana (Universal)?

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