Quantum Audit Logo

Is Wrapped SOL Safe?

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

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

Wrapped SOL SOL
0xd31a…b89c
Ethereum
Not verifiedThis 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 today 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit covers the implementation contract (TokenImplementation) for the BridgeToken proxy. The contract utilizes a UUPS proxy pattern with `ERC1967Upgrade` and `Ownable` for access control. Key findings include critical vulnerabilities related to upgrade authorization and proper initialization, which could lead to unauthorized contract upgrades or an unowned state. The contract employs good practices for storage management with a dedicated `TokenStorage` struct, but the core ERC-20 functionality is not fully provided for review.

2 High1 Low1 Informational
Volume 24h
$120.0K
Liquidity
$1.01M
Price
$118.0026
Token Age
4y
Top 10 Holders
21.2%

Security Findings

2 High1 Low1 Info
High

Missing `_authorizeUpgrade` Implementation in UUPS

H-01The `ERC1967Upgrade` abstract contract is included, indicating a UUPS proxy pattern. However, the critical `_authorizeUpgrade` function, which is responsible for restricting who can initiate an upgrade via `_upgradeTo`, is not provided in the given code. Without a proper implementation of `_authorizeUpgrade` (e.g., using `onlyOwner`), any address could potentially call `_upgradeTo` and change the contract's logic, leading to a complete loss of control over the contract and potential manipulation of assets.
IssueThe `ERC1967Upgrade` abstract contract is included, indicating a UUPS proxy pattern. However, the critical `_authorizeUpgrade` function, which is responsible for restricting who can initiate an upgrade via `_upgradeTo`, is not provided in the given code. Without a proper implementation of `_authorizeUpgrade` (e.g., using `onlyOwner`), any address could potentially call `_upgradeTo` and change the contract's logic, leading to a complete loss of control over the contract and potential manipulation of assets.
FixImplement the `_authorizeUpgrade` function within the `TokenImplementation` contract. This function should enforce strict access control, typically allowing only the contract owner or a designated governance mechanism to authorize upgrades. For example: ```solidity function _authorizeUpgrade(address newImplementation) internal override onlyOwner {} ```
StatusUnresolved
High

Improper Initialization of Owner and State in UUPS

H-02In a UUPS proxy setup, the `constructor` of the implementation contract is executed only once upon its initial deployment, not when the proxy is initialized. The `Ownable` constructor attempts to set the `_owner` variable to `msg.sender`. However, this assignment affects the implementation's storage, not the proxy's storage, which is where the actual state resides. Consequently, the `_owner` variable within the `TokenStorage.State` struct (which is the proxy's storage) will remain unset. An explicit `initialize` function, protected by an `initialized` flag (which exists in `TokenStorage.State`), is required to correctly set the owner and other initial state variables (e.g., `name`, `symbol`…
IssueIn a UUPS proxy setup, the `constructor` of the implementation contract is executed only once upon its initial deployment, not when the proxy is initialized. The `Ownable` constructor attempts to set the `_owner` variable to `msg.sender`. However, this assignment affects the implementation's storage, not the proxy's storage, which is where the actual state resides. Consequently, the `_owner` variable within the `TokenStorage.State` struct (which is the proxy's storage) will remain unset. An explicit `initialize` function, protected by an `initialized` flag (which exists in `TokenStorage.State`), is required to correctly set the owner and other initial state variables (e.g., `name`, `symbol`…
FixImplement an `initialize` function that sets the owner and all other necessary initial state variables. This function must be callable only once and protected by the `initialized` flag. For example: ```solidity function initialize(string memory name_, string memory symbol_, uint8 decimals_, address owner_) public initializer { require(!_state.initialized, "Already initialized"); _state.name = name_; _state.symbol = symbol_; _state.decimals = decimals_; _setOwner(owner_); //…
StatusUnresolved
Low

Incomplete ERC-20 Implementation Provided

L-01The contract defines state variables typical for an ERC-20 token (e.g., `balances`, `allowances`, `totalSupply`, `name`, `symbol`, `decimals`). However, the core functions for ERC-20 operations such as `transfer`, `transferFrom`, `approve`, `mint`, and `burn` are not included in the provided source code. While this is not a direct vulnerability in the provided snippet, it means the full functionality and security implications of the token's operations cannot be assessed. Any unreviewed token logic could introduce vulnerabilities.
IssueThe contract defines state variables typical for an ERC-20 token (e.g., `balances`, `allowances`, `totalSupply`, `name`, `symbol`, `decimals`). However, the core functions for ERC-20 operations such as `transfer`, `transferFrom`, `approve`, `mint`, and `burn` are not included in the provided source code. While this is not a direct vulnerability in the provided snippet, it means the full functionality and security implications of the token's operations cannot be assessed. Any unreviewed token logic could introduce vulnerabilities.
FixEnsure that the complete ERC-20 implementation, including all transfer, approval, minting, and burning logic, adheres to the ERC-20 standard and best security practices. If these functions are implemented elsewhere or inherited, verify their correctness and security. Consider using battle-tested libraries like OpenZeppelin for standard token functionality.
StatusUnresolved
Info

Explicit Storage Management with `TokenStorage` Struct

I-01The contract utilizes a `TokenStorage.State` struct to define all its state variables. This is a robust and recommended pattern for upgradeable contracts, particularly in UUPS proxies. By centralizing storage definition, it helps manage the storage layout and prevent storage collisions when upgrading to new implementation versions, provided the struct is only appended to and existing fields are not reordered or removed.
IssueThe contract utilizes a `TokenStorage.State` struct to define all its state variables. This is a robust and recommended pattern for upgradeable contracts, particularly in UUPS proxies. By centralizing storage definition, it helps manage the storage layout and prevent storage collisions when upgrading to new implementation versions, provided the struct is only appended to and existing fields are not reordered or removed.
FixContinue to use this explicit storage management pattern. When performing upgrades, ensure that any changes to the `TokenStorage.State` struct are strictly additive (new variables are appended to the end) and that existing variable types or order are not modified to prevent storage collisions and data corruption.
StatusResolved

Category Ratings

TechnicalMedium5/10

The contract's architecture (7.1) follows a UUPS proxy pattern, utilizing `TokenStorage` for explicit state management and `Ownable` for access control. Code security (7.2) generally appears robust, with `Counters` library handling unchecked arithmetic safely. However, significant vulnerabilities exist in the upgrade mechanism (7.7) and initialization, posing a high technical risk. The absence of a proper `_authorizeUpgrade` function and incorrect owner initialization are critical concerns.

GovernanceMedium5/10

The contract implements a centralized ownership model (7.5) via the `Ownable` pattern, allowing the owner to manage critical functions like `transferOwnership` and `renounceOwnership`. No complex economic mechanisms (7.4) are present in the provided code snippet beyond standard token properties. The primary governance risk stems from the centralized control, which is standard for many token contracts but requires trust in the owner.

UpgradesHigh1/10

The contract uses `ERC1967Upgrade` for UUPS upgradeability (7.7). However, two critical issues were identified: the `_authorizeUpgrade` function, essential for restricting who can initiate an upgrade, is not implemented, potentially allowing unauthorized upgrades. Additionally, the `Ownable` constructor's owner assignment is ineffective for UUPS proxies, requiring a dedicated `initialize` function to set the owner and other initial state variables correctly, which is also missing. These flaws introduce significant upgrade safety risks.

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeBeacon
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

21.2% in top 10
2.7% in wallets18.5% in contracts
Effective Concentration10.1%

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

$1.56M across 7 pairs
Uniswap v3WETHanalysed$1.01M65.2%Uniswap v4ETH$496.9K32.0%Uniswap v3USDT$33.7K2.2%Uniswap v4ZIK$7.1K0.5%Uniswap v4ZIK$3.2K0.2%Uniswap v4USDC$3300.0%
Show 1 more pairShow less
Uniswap v4sUSDe$2600.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 Holder14.7%
Top-3 Unlocked37.2%

Key Addresses

11 addresses
Deployer
0x3ee1…a585
Unlocked LP Held By
0x72f0…90830x87f2…414c0x05a7…70200xb569…ac7c0x5be0…5c5d0x341b…091c0x7901…e6570xb2e4…8f960x3da1…5a1e0x0521…9ad6

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

What Raised This Score

7 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 2 High 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
PendleMedium RiskStarmanMedium RiskSPX6900 (SPX)Medium RiskPrometheusMedium RiskVERA (VRA)Medium RiskTRIAMedium Risk

Would You Like a More Detailed Audit of Wrapped SOL?

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

Get Detailed Audit