Quantum Audit Logo

Is Wrapped liquid staked Ether 2.0 Safe?

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

Wrapped liquid staked Ether 2.0 WSTETH
0xc1cb…e452
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The ERC20Bridged token, deployed via an OssifiableProxy, implements standard ERC20 functionality with additional bridge-specific minting and burning capabilities. The core logic for token transfers and allowances appears robust, utilizing Solidity 0.8.10's default overflow/underflow checks and explicit `unchecked` blocks where appropriate. However, critical design flaws exist in the contract's interaction with the proxy pattern, specifically regarding state variable initialization and the use of `immutable` variables, leading to an uninitialized bridge address and an ineffective `initialize` function. These issues severely impact the token's intended functionality and upgradeability.

1 Critical1 High1 Low
Volume 24h
$2.46M
Liquidity
$3.32M
Price
$3132.0500
Token Age
1y
Top 10 Holders
76.7%

Security Findings

1 Crit1 High1 Low
Critical

Critical Proxy Initialization Flaw & Uninitialized Bridge Address

C-01The `ERC20Bridged` implementation contract's constructor sets critical state variables (`decimals`, `name`, `symbol`, and crucially, the `bridge` address) using `immutable` for `bridge`. When deployed behind a proxy (like `OssifiableProxy`), the constructor is only executed once during the implementation's deployment, not during the proxy's initialization. Consequently, the `bridge` address in the proxy's storage will remain `address(0)`, rendering the `bridgeMint` and `bridgeBurn` functions unusable as they are protected by `onlyBridge`. This fundamentally breaks the core functionality of a bridged token (7.1 Architecture, 7.7 Upgrades).
IssueThe `ERC20Bridged` implementation contract's constructor sets critical state variables (`decimals`, `name`, `symbol`, and crucially, the `bridge` address) using `immutable` for `bridge`. When deployed behind a proxy (like `OssifiableProxy`), the constructor is only executed once during the implementation's deployment, not during the proxy's initialization. Consequently, the `bridge` address in the proxy's storage will remain `address(0)`, rendering the `bridgeMint` and `bridgeBurn` functions unusable as they are protected by `onlyBridge`. This fundamentally breaks the core functionality of a bridged token (7.1 Architecture, 7.7 Upgrades).
FixAll state-modifying logic, especially for critical parameters like the `bridge` address, `name`, `symbol`, and `decimals`, must be moved from the constructor to an initializer function (e.g., `initialize`). The `bridge` variable should not be `immutable` but a regular state variable set by the initializer. The initializer must then be called *once* on the proxy contract after deployment.
StatusUnresolved
High

Unprotected and Ineffective `initialize` Function

H-01The `initialize` function in `ERC20Bridged` is intended for proxy initialization but lacks access control, allowing any external caller to execute it (7.3 Access Control). Furthermore, it attempts to set `name` and `symbol`, which are already set by the `ERC20Metadata` constructor. The `_setERC20MetadataName` and `_setERC20MetadataSymbol` functions revert if the metadata is already set, making `initialize` ineffective and prone to reverting if called. This design flaw prevents proper initialization of metadata via the proxy (7.7 Upgrades, 7.8 Operations).
IssueThe `initialize` function in `ERC20Bridged` is intended for proxy initialization but lacks access control, allowing any external caller to execute it (7.3 Access Control). Furthermore, it attempts to set `name` and `symbol`, which are already set by the `ERC20Metadata` constructor. The `_setERC20MetadataName` and `_setERC20MetadataSymbol` functions revert if the metadata is already set, making `initialize` ineffective and prone to reverting if called. This design flaw prevents proper initialization of metadata via the proxy (7.7 Upgrades, 7.8 Operations).
FixImplement robust access control (e.g., `onlyOwner` or `onlyInitializer`) for the `initialize` function to ensure it can only be called once by an authorized entity. Refactor the `ERC20Metadata` constructor logic into the `initialize` function to avoid conflicts and ensure proper proxy initialization.
StatusUnresolved
Low

Custom Storage Slot Usage for Metadata

L-01The `ERC20Metadata` contract uses a custom storage slot (`DYNAMIC_METADATA_SLOT`) for storing `name` and `symbol`. While this is a valid technique, it introduces a dependency on this specific slot for future upgrades. Any change in the storage layout of `ERC20Metadata` or its base contracts must carefully account for this custom slot to prevent storage collisions or data corruption (7.7 Upgrades).
IssueThe `ERC20Metadata` contract uses a custom storage slot (`DYNAMIC_METADATA_SLOT`) for storing `name` and `symbol`. While this is a valid technique, it introduces a dependency on this specific slot for future upgrades. Any change in the storage layout of `ERC20Metadata` or its base contracts must carefully account for this custom slot to prevent storage collisions or data corruption (7.7 Upgrades).
FixDocument the custom storage slot usage clearly. During future upgrades, ensure that the storage layout of the new implementation contract is compatible with the existing proxy's storage, paying particular attention to this custom slot to avoid overwriting or misinterpreting data.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The ERC20Bridged contract implements standard ERC20 functionalities (7.2 Code Security) with custom `_mint` and `_burn` methods protected by an `onlyBridge` modifier (7.3 Access Control). The use of Solidity 0.8.10 provides built-in overflow/underflow protection, and `unchecked` blocks are correctly used after explicit boundary checks. The `ERC20Metadata` component uses a custom storage slot for dynamic metadata, which is a valid but less common pattern. However, the technical architecture suffers from critical flaws related to proxy initialization and state variable management (7.1 Architecture), particularly the `immutable bridge` address, which will be `address(0)` in the proxy's storage.

GovernanceHigh1/10

The economic model of the ERC20Bridged token is straightforward, functioning as a standard ERC20 with controlled minting and burning capabilities (7.4 Economic). The `bridgeMint` and `bridgeBurn` functions are appropriately restricted to a designated `bridge` address, preventing unauthorized supply manipulation. There is no explicit governance mechanism (7.5 Governance) within the token contract itself, relying on the external bridge for supply control. The primary economic risk stems from the technical flaw preventing the `bridge` address from being correctly initialized in the proxy, rendering the bridge functions unusable.

UpgradesHigh1/10

The contract is deployed behind an OssifiableProxy, indicating an intention for upgradeability (7.7 Upgrades). However, the current implementation has critical upgrade safety issues. The `ERC20Bridged` constructor initializes state variables like `decimals`, `name`, `symbol`, and the `bridge` address. For proxy contracts, these should be set via an initializer function, not the constructor. The `immutable bridge` variable in the implementation means the `bridge` address in the proxy's storage will remain `address(0)`. Additionally, the `initialize` function, intended for proxy setup, conflicts with the constructor's actions and lacks access control, making it ineffective and potentially exploitable if it were to set critical parameters (7.8 Operations). The custom storage slot for metadata also requires careful management during upgrades.

Security Checklist

2/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOther-Contract
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

76.7% in top 10
6.1% in wallets70.6% in contracts
Effective Concentration34.3%

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

$4.87M across 23 pairs
AerodromeWETHanalysed$3.32M68.3%AerodromeWETH$848.1K17.4%Quickswap v4WETH$270.4K5.6%AerodromefBOMB$161.9K3.3%AerodromeAERO$114.9K2.4%Uniswap v3WETH$91.3K1.9%
Show 4 more pairsShow less
Uniswap v4cbETH$24.6K0.5%Uniswap v3WETH$21.6K0.4%SwapbasedWETH$2.6K0.1%Uniswap v4cbBTC$2.6K0.1%

The 13 remaining pairs hold $6.7K between them and are not listed.

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 Holder57.0%
Top-3 Unlocked70.5%

Key Addresses

11 addresses
Deployer
0xfa81…4ed2
Unlocked LP Held By
0x3c34…fb710xfbf5…cd2d0x781d…47890x51cc…59130x0c2d…2ad50x799c…9cf80x88ad…7e760x24f3…51a10xfb2b…37470x24b0…94a6

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

What Raised This Score

9 factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Proxy contract (upgradeable — admin can replace logic)
  • Admin is unclassified contract
  • Top-10 concentration > 30% (76.7% total → 34.3% effective; 6.1% in EOAs, 70.6% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 57.0% (independent LP — depth risk, pool = 68% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 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
ViciCoin (VCNT)High RiskgitlawbHigh RiskSuperform (UP)High RiskaeonHigh RiskCoinbase Wrapped Staked ETH (CBETH)High RiskThe Innovation Game (TIG)High Risk

Would You Like a More Detailed Audit of Wrapped liquid staked Ether 2.0?

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

Get Detailed Audit