Quantum Audit Logo

Is Wrapped liquid staked Ether 2.0 Safe?

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

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

Wrapped liquid staked Ether 2.0 WSTETH
0x7f39…2ca0
Ethereum Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Low Risk
Executive SummaryAI Copilot

The audited contract is a standard ERC20 token implementation, likely based on OpenZeppelin's well-vetted libraries. It utilizes SafeMath for arithmetic safety and adheres to common security practices. The primary findings are informational, related to the base contract's non-functional state without further implementation (e.g., initial supply minting) and the presence of the ECDSA library without a corresponding permit function. One low-severity finding notes the potential for misuse of the `_beforeTokenTransfer` hook if overridden by a derived contract. Overall, the technical risk is low, reflecting a robust and secure foundation.

1 Low3 Informational
Volume 24h
$2.65M
Liquidity
$6.42M
Price
$3129.5300
Token Age
3y
Top 10 Holders
65.4%

Security Findings

1 Low3 Info
Low

Potential for Misuse of `_beforeTokenTransfer` Hook

L-01The `_beforeTokenTransfer` hook is an `internal virtual` function that is called before any token transfer, mint, or burn operation. While it is empty in the base `ERC20` contract, a derived contract could override this function to introduce complex logic, reentrancy vectors, or other vulnerabilities if not implemented carefully. Improperly implemented custom logic in this hook could lead to unexpected behavior or security exploits.
IssueThe `_beforeTokenTransfer` hook is an `internal virtual` function that is called before any token transfer, mint, or burn operation. While it is empty in the base `ERC20` contract, a derived contract could override this function to introduce complex logic, reentrancy vectors, or other vulnerabilities if not implemented carefully. Improperly implemented custom logic in this hook could lead to unexpected behavior or security exploits.
FixAny contract inheriting from `ERC20` and overriding `_beforeTokenTransfer` must ensure that the custom logic is thoroughly audited for reentrancy, gas limits, and other potential side effects. Avoid external calls within this hook or ensure they are protected against reentrancy if necessary.
StatusUnresolved
Info

Token Non-Functional As-Is

I-01The `ERC20` contract, as provided, initializes `_totalSupply` to 0 and does not expose any public or external functions for minting new tokens. This means that upon deployment, the token will have a total supply of zero, rendering it non-functional for transfers unless a derived contract implements minting logic (e.g., in its constructor or via an external function). This is a design choice for a base contract but makes it unusable as a standalone token.
IssueThe `ERC20` contract, as provided, initializes `_totalSupply` to 0 and does not expose any public or external functions for minting new tokens. This means that upon deployment, the token will have a total supply of zero, rendering it non-functional for transfers unless a derived contract implements minting logic (e.g., in its constructor or via an external function). This is a design choice for a base contract but makes it unusable as a standalone token.
FixEnsure that the inheriting contract (e.g., `WstETH`) properly implements initial token supply minting or provides controlled minting mechanisms to make the token functional. This typically involves calling the internal `_mint` function in the constructor of the derived token contract or through an externally callable function with appropriate access control.
StatusUnresolved
Info

`ECDSA` Library Present but `permit` Not Implemented

I-02The `ECDSA` library and `IERC20Permit` interface are included in the codebase, suggesting an intention to implement the ERC-2612 `permit` functionality. However, the `ERC20` contract itself does not implement the `permit` function, which allows users to approve token transfers via a signed message rather than an on-chain transaction.
IssueThe `ECDSA` library and `IERC20Permit` interface are included in the codebase, suggesting an intention to implement the ERC-2612 `permit` functionality. However, the `ERC20` contract itself does not implement the `permit` function, which allows users to approve token transfers via a signed message rather than an on-chain transaction.
FixIf `permit` functionality is desired for the `WstETH` token, ensure it is correctly implemented in the derived contract, leveraging the `ECDSA` library for signature verification and adhering to the ERC-2612 standard. Pay close attention to nonce management and signature validation to prevent replay attacks.
StatusUnresolved
Info

Use of Older Solidity Version

I-03The contract uses Solidity version `0.6.12`. While this version is generally stable and widely used, newer versions (e.g., `0.8.x`) include built-in overflow/underflow checks, removing the explicit need for `SafeMath` and potentially simplifying the code. Newer compilers also offer various optimizations and bug fixes.
IssueThe contract uses Solidity version `0.6.12`. While this version is generally stable and widely used, newer versions (e.g., `0.8.x`) include built-in overflow/underflow checks, removing the explicit need for `SafeMath` and potentially simplifying the code. Newer compilers also offer various optimizations and bug fixes.
FixConsider upgrading to Solidity `0.8.x` or later for new deployments to benefit from native overflow checks and other compiler improvements. If upgrading, ensure all code is compatible with the new compiler version and thoroughly re-audited, as syntax and behavior changes may exist.
StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture is based on a well-established OpenZeppelin ERC20 standard, leveraging `SafeMath` for robust arithmetic operations (7.1 Architecture, 7.2 Code Security). The contract demonstrates strong adherence to common security practices for token implementations. A minor concern is the `_beforeTokenTransfer` hook, which, if overridden in a derived contract, could introduce new vulnerabilities (7.2 Code Security).

GovernanceMedium4/10

The contract implements standard ERC20 token economics, focusing on transfers and allowances without complex economic models or governance mechanisms (7.4 Economic, 7.5 Governance). The base contract does not define an initial token supply or minting functions, which means it is not functional as a standalone token (7.4 Economic). There are no specific governance roles or voting mechanisms (7.5 Governance).

UpgradesMedium6/10

The contract is not designed with an upgradeability pattern (e.g., proxy) (7.7 Upgrades). This simplifies the deployment model by eliminating upgrade-related risks such as storage collisions or logic inconsistencies. However, it means that any future changes to the token's core logic would require a new deployment and migration, which is a standard approach for non-upgradeable tokens.

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

65.4% in top 10
1.1% in wallets64.4% in contracts
Effective Concentration26.8%

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

$18.63M across 19 pairs
Uniswap v3WETHanalysed$6.42M34.5%Curve tricrvUSD$3.26M17.5%Curve tritBTC$3.12M16.7%Uniswap v4WBTC$2.82M15.2%Curve stblpufETH$1.84M9.9%Uniswap v4ETH$480.6K2.6%
Show 4 more pairsShow less
Curve trirETH$191.8K1.0%CurverETH$188.0K1.0%Uniswap v4WBTC$161.1K0.9%Uniswap v4USDC$83.4K0.4%

The 9 remaining pairs hold $64.3K 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 Holder56.4%
Top-3 Unlocked78.6%

Key Addresses

11 addresses
Deployer
0xe19f…f57b
Unlocked LP Held By
0x9c7f…053a0xe8dc…daa60x91b2…d6eb0x25dc…4cee0xaf40…aec60x9510…54c60xc704…d55a0xb80c…23ac0x16a7…67cc0xc441…f196

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

What Raised This Score

5 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 20% (65.4% total → 26.8% effective; 1.1% in EOAs, 64.4% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 56.4% (independent LP — depth risk, pool = 34% of DEX liquidity)
  • 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
ManyuLow RiskHEXLow RiskRektLow RiskXEN Crypto (XEN)Low RiskEthereumcat (ETHCAT)Low RiskUnity Software (UNITY)Low 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