Quantum Audit Logo
Launch App

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

Is Wrapped liquid staked Ether 2.0 Safe?

WSTETHArbitrum
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/10Governance1/10Upgrades1/10Checks passed2 of 5Findings2 Critical · 1 High · 1 Medium4
SummaryAI Copilot

The audit of the ERC20Bridged token implementation, deployed behind an OssifiableProxy, revealed critical vulnerabilities primarily stemming from incorrect handling of immutable variables and an unprotected initialization function within a proxy context.

Read the full analysis
What raised the score
  • Ownership not renounced
  • Proxy contract
  • Admin is unclassified contract
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 2 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
Exact factors
  • Ownership NOT renounced (admin/mint authority retained)
  • Proxy contract (upgradeable — admin can replace logic)
  • Admin is unclassified contract
  • Top-10 concentration > 30% (76.6% total → 32.7% effective; 3.4% in EOAs, 73.1% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 2 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 42 of 5 checks passed
Contract verifiedVerified
OwnershipRetained
MintNo mint
Liquidity lockNot locked
UpgradeabilityUpgradeable

Holders

as of audit · Sep 4, 2026
73.1%Contracts3.4%23.4%Everyone else
73.1%Contracts23.4%
ContractsWalletsEveryone elseBubble area = share of supply
76.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking73.1%
  • Walletsanonymous holders, free to sell3.4%
  • Everyone elsethe rest of the supply23.4%
Effective concentrationwhat the score reads32.7%
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.24M across 14 pairs
Show 4 more pairs

The 4 remaining pairs hold $49 between them and are not listed. 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.05MShare of depth84.5%
Top-1 Unlocked Holder46.0%
Top-3 Unlocked76.4%
Unlocked LP held by
0xb884…722c0x9e3f…b72f0x6f99…6ae50x642f…f2610x241a…e4880x185a…1d0f0xfafe…89f40xdd70…6eb50x7e6b…d4c10x8b5f…c98d

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

Security Findings

2 Critical1 High1 Medium
Critical

Critical: Immutable Variables Incompatible with Proxy Pattern

The ERC20Bridged contract declares bridge as an immutable variable, and ERC20Metadata declares decimals as immutable. When an implementation contract with immutable variables is deployed behind a proxy, these variables are set during the implementation's constructor execution and are stored in the implementation's bytecode or a special storage area, not in the proxy's delegated storage. Consequently, when calls are made through the proxy, bridge will always evaluate to address(0) and decimals will always evaluate to 0. This renders the onlyBridge modifier ineffective, allowing any non-zero address to call bridgeMint and bridgeBurn, and causes the decimals() fun…C-01

Issue

The ERC20Bridged contract declares bridge as an immutable variable, and ERC20Metadata declares decimals as immutable. When an implementation contract with immutable variables is deployed behind a proxy, these variables are set during the implementation's constructor execution and are stored in the implementation's bytecode or a special storage area, not in the proxy's delegated storage. Consequently, when calls are made through the proxy, bridge will always evaluate to address(0) and decimals will always evaluate to 0. This renders the onlyBridge modifier ineffective, allowing any non-zero address to call bridgeMint and bridgeBurn, and causes the decimals() fun…

Fix

Remove the immutable keyword from bridge and decimals. These variables should be declared as regular state variables and initialized via an access-controlled initializer function (e.g., initialize(..., address bridge_, uint8 decimals_)) that is called only once through the proxy. Ensure the initializer function is properly protected to prevent re-initialization.

Status

Unresolved

Critical

Critical: Unprotected Initialization Function

The initialize function in ERC20Bridged allows setting the token's name and symbol via _setERC20MetadataName and _setERC20MetadataSymbol. This function lacks any access control (e.g., onlyOwner or initializer modifier). When the contract is deployed as an implementation behind a proxy, the proxy's storage for name and symbol will initially be empty. This allows any external caller to invoke initialize through the proxy and set arbitrary name and symbol values for the token, leading to potential manipulation of the token's identity.C-02

Issue

The initialize function in ERC20Bridged allows setting the token's name and symbol via _setERC20MetadataName and _setERC20MetadataSymbol. This function lacks any access control (e.g., onlyOwner or initializer modifier). When the contract is deployed as an implementation behind a proxy, the proxy's storage for name and symbol will initially be empty. This allows any external caller to invoke initialize through the proxy and set arbitrary name and symbol values for the token, leading to potential manipulation of the token's identity.

Fix

Implement robust access control for the initialize function. It should be callable only once by a trusted entity (e.g., the contract owner or a dedicated deployer address) during the proxy's initialization. Consider using OpenZeppelin's Initializable base contract and its initializer modifier for secure proxy initialization.

Status

Unresolved

High

High: Centralization Risk with Bridge Address

The bridge address has absolute control over the token's supply through the bridgeMint and bridgeBurn functions. If this address is compromised, an attacker could mint an arbitrary amount of tokens or burn existing tokens, leading to severe economic instability and loss of user funds. While this is a common design for bridged tokens, the single point of failure represents a significant centralization risk.H-01

Issue

The bridge address has absolute control over the token's supply through the bridgeMint and bridgeBurn functions. If this address is compromised, an attacker could mint an arbitrary amount of tokens or burn existing tokens, leading to severe economic instability and loss of user funds. While this is a common design for bridged tokens, the single point of failure represents a significant centralization risk.

Fix

Consider implementing a multi-signature wallet (e.g., Gnosis Safe) for the bridge address to distribute control and require multiple approvals for critical operations. Alternatively, explore time-locks or governance mechanisms to introduce delays or community oversight for bridgeMint and bridgeBurn operations.

Status

Unresolved

Medium

Medium: Potential for Storage Collisions with Custom Metadata Slot

The ERC20Metadata contract uses a custom storage slot (DYNAMIC_METADATA_SLOT = keccak256("ERC20Metdata.dynamicMetadata")) for storing the token's name and symbol. While using a keccak256 hash for a storage slot is a common technique to avoid collisions with standard storage variables, it introduces a potential risk in future upgrades. If a new version of the contract or a base contract introduces a state variable that happens to occupy this specific storage slot, it could lead to a storage collision, corrupting data or causing unexpected behavior.M-01

Issue

The ERC20Metadata contract uses a custom storage slot (DYNAMIC_METADATA_SLOT = keccak256("ERC20Metdata.dynamicMetadata")) for storing the token's name and symbol. While using a keccak256 hash for a storage slot is a common technique to avoid collisions with standard storage variables, it introduces a potential risk in future upgrades. If a new version of the contract or a base contract introduces a state variable that happens to occupy this specific storage slot, it could lead to a storage collision, corrupting data or causing unexpected behavior.

Fix

Ensure that any future upgrades or modifications to the contract's storage layout are meticulously reviewed for potential collisions with this custom slot. Document this custom slot clearly in the contract's design specifications. Consider using a more explicit 'gap' array or OpenZeppelin's ERC1967Storage pattern for proxy-safe storage management, although the current approach is generally considered safer than direct slot assignment for custom data.

Status

Unresolved

Analysis

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

The audit of the ERC20Bridged token implementation, deployed behind an OssifiableProxy, revealed critical vulnerabilities primarily stemming from incorrect handling of immutable variables and an unprotected initialization function within a proxy context. These issues lead to a complete bypass of the bridge's access control, allowing unauthorized minting/burning, and enable anyone to set the token's metadata. Additionally, significant centralization risk exists with the bridge address, and potential storage collision concerns were identified. The overall risk level is Critical.

Technical4/10Medium risk

The ERC20Bridged token implements standard ERC-20 functionality with custom mint/burn capabilities controlled by a 'bridge' address. The core ERC-20 logic in ERC20Core is generally well-structured and uses Solidity 0.8+ safe math, preventing common integer overflow/underflow issues (7.2 Code Security). However, critical technical flaws arise from its deployment as a proxy implementation. Specifically, immutable variables like 'bridge' and 'decimals' are not correctly handled in the proxy's storage, leading to a complete bypass of the 'onlyBridge' access control (7.3 Access Control). Furthermore, the 'initialize' function, intended for setting metadata, lacks any access control and can be called by any external address, allowing arbitrary modification of the token's name and symbol (7.3 Access Control).

Governance1/10High risk

The economic model of the ERC20Bridged token relies heavily on the security and integrity of the designated 'bridge' address. This address holds absolute power over the token's supply through the 'bridgeMint' and 'bridgeBurn' functions (7.4 Economic). While this is a common design for bridged tokens, it introduces a significant centralization risk; compromise of this single address would lead to complete loss of control over the token's supply and severe economic consequences for holders. The current implementation exacerbates this risk by rendering the 'onlyBridge' modifier ineffective due to proxy storage issues, effectively decentralizing mint/burn control to any caller (7.3 Access Control, 7.4 Economic).

Upgrades1/10High risk

The contract is designed as an implementation for an OssifiableProxy (Transparent Proxy), which is a standard upgradeability pattern (7.7 Upgrades). However, the use of 'immutable' variables ('bridge' and 'decimals') in the implementation contract is fundamentally incompatible with proxy patterns. These variables are not stored in the proxy's delegated storage, causing them to always resolve to their default zero values when accessed through the proxy, breaking core functionality and access control (7.7 Upgrades). Additionally, the ERC20Metadata contract uses a custom storage slot for dynamic metadata, which, while using a keccak256 hash, could still pose a risk of storage collision in future upgrades if not carefully managed (7.1 Architecture, 7.7 Upgrades).

Final RecommendationWhat to do about this score

Immediate action is required to address the critical proxy implementation flaws.

The use of 'immutable' variables for 'bridge' and 'decimals' must be removed; these values should be stored as regular state variables and initialized via an access-controlled initializer function. The 'initialize' function must be protected with an appropriate access control mechanism, such as 'onlyOwner' or a dedicated 'initializer' role, to prevent unauthorized metadata changes. A thorough review of the proxy's initialization process and storage layout is essential to ensure all critical state variables are correctly managed within the proxy's context. Consider adopting a well-audited proxy standard like UUPS or Transparent Proxy with OpenZeppelin's Initializable pattern to prevent similar issues.

Contract & Record

1 audit on record
TypeOssifiableProxy
NetworkArbitrum
Token age3y
Contract0x5979…0529
Deployer0x1824…6321
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOther-Contract
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
Wrapped liquid staked Ether 2.0 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. Sep 4, 202642Medium
  2. Aug 11, 202653Medium

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

Frequently Asked Questions

What is the WSTETH contract address?

The Wrapped liquid staked Ether 2.0 (WSTETH) contract on Arbitrum is 0x5979d7b546e38e414f7e9822514be443a4800529. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is Wrapped liquid staked Ether 2.0 a scam?

Quantum Audit's risk score for Wrapped liquid staked Ether 2.0 is 42/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; 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 WSTETH liquidity locked?

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

Who holds WSTETH?

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
Aave TokenAAVE · Arbitrum42MediumSperaxSPA · Arbitrum42MediumRAINArbitrum43MediumChainLink TokenLINK · Arbitrum41MediumPepeArbitrum41MediumBoopArbitrum44Medium

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 Is this your token? Publish your own audit on this page