Quantum Audit Logo

Is Coinbase Wrapped Staked ETH Safe?

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

Coinbase Wrapped Staked ETH CBETH
0x2ae3…ec22
Base Not verifiedLast checked 3d ago 1 audit on record
Executive SummaryAI Copilot

This audit covers an upgradeable ERC20 token, `UpgradeableOptimismMintableERC20`, deployed on the Base network via an EIP-1967 Transparent Proxy. The contract utilizes OpenZeppelin's `Initializable` and `ERC20Upgradeable` patterns, providing a solid foundation. Key risks identified include the centralized control over token supply through a minting function and the inherent complexities associated with upgradeable contracts, despite being managed by a multisig.

1 High2 Medium1 Informational
Volume 24h
$5.24M
Liquidity
$2.82M
Price
$2857.7000
Token Age
1y
Top 10 Holders
91.7%

Security Findings

High

Centralized Control over Token Supply (Minting)

H-01The `UpgradeableOptimismMintableERC20` contract, as indicated by `has_mint: true` in the prefill, includes a minting function. This grants a privileged role (likely an owner or minter) the ability to create new tokens, introducing a significant economic risk due to potential arbitrary inflation of the token supply. This centralizes control over the token's economic model, which could devalue existing tokens if misused.
IssueThe `UpgradeableOptimismMintableERC20` contract, as indicated by `has_mint: true` in the prefill, includes a minting function. This grants a privileged role (likely an owner or minter) the ability to create new tokens, introducing a significant economic risk due to potential arbitrary inflation of the token supply. This centralizes control over the token's economic model, which could devalue existing tokens if misused.
FixClearly document the role responsible for minting, the conditions under which minting can occur, and any governance processes required. Consider implementing a timelock for minting operations to provide transparency and allow for community oversight. If possible, explore mechanisms to decentralize or restrict minting capabilities over time.
StatusUnresolved
Medium

Upgradeability via Multisig Admin

M-01The contract is upgradeable via an EIP-1967 Transparent Proxy, with administration controlled by a 3/6 multisig. While the multisig provides a layer of security by requiring multiple approvals, any upgrade introduces inherent risks such as potential for logic errors, storage collisions, or malicious changes if the multisig signers are compromised or collude. Upgrades always carry a non-zero risk of introducing new vulnerabilities.
IssueThe contract is upgradeable via an EIP-1967 Transparent Proxy, with administration controlled by a 3/6 multisig. While the multisig provides a layer of security by requiring multiple approvals, any upgrade introduces inherent risks such as potential for logic errors, storage collisions, or malicious changes if the multisig signers are compromised or collude. Upgrades always carry a non-zero risk of introducing new vulnerabilities.
FixImplement a robust upgrade process including comprehensive testing on a staging environment before deployment to production. Conduct independent audits of all proposed upgrade logic. Consider adding a timelock to the proxy admin to allow for a delay between an upgrade proposal and its execution, providing a window for review and potential intervention.
StatusUnresolved
Medium

Potential for Reentrancy in Derived Contracts via `_beforeTokenTransfer` Hook

M-02The `_transfer` function in `ERC20Upgradeable` includes a call to `_beforeTokenTransfer`, which is an internal virtual function. While the base OpenZeppelin implementation is safe, if the `UpgradeableOptimismMintableERC20` contract (or any future derived contract) overrides this hook with external calls or state-changing logic before updating balances, it could introduce reentrancy vulnerabilities. This is a common pattern for custom logic but requires careful implementation to avoid security pitfalls.
IssueThe `_transfer` function in `ERC20Upgradeable` includes a call to `_beforeTokenTransfer`, which is an internal virtual function. While the base OpenZeppelin implementation is safe, if the `UpgradeableOptimismMintableERC20` contract (or any future derived contract) overrides this hook with external calls or state-changing logic before updating balances, it could introduce reentrancy vulnerabilities. This is a common pattern for custom logic but requires careful implementation to avoid security pitfalls.
FixWhen overriding `_beforeTokenTransfer` in `UpgradeableOptimismMintableERC20` or any derived contract, ensure that no external calls are made before all state changes related to the transfer are finalized. Follow the Checks-Effects-Interactions pattern strictly. If external calls are necessary, implement reentrancy guards.
StatusUnresolved
Info

Dependency on External Multisig Security

I-01The overall security of the system, particularly regarding upgrades and administrative actions, is highly dependent on the security practices and trustworthiness of the 3/6 multisig signers controlling the proxy admin. Compromise of the required number of keys (3 out of 6) could lead to unauthorized control over the contract, including malicious upgrades or administrative actions.
IssueThe overall security of the system, particularly regarding upgrades and administrative actions, is highly dependent on the security practices and trustworthiness of the 3/6 multisig signers controlling the proxy admin. Compromise of the required number of keys (3 out of 6) could lead to unauthorized control over the contract, including malicious upgrades or administrative actions.
FixEnsure that the multisig signers are diverse, geographically distributed, and employ strong key management practices (e.g., hardware wallets, secure offline storage). Regularly review and update multisig signers as personnel or security requirements change. Consider implementing a robust incident response plan for potential multisig key compromises.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages OpenZeppelin's battle-tested `ERC20Upgradeable` and `Initializable` patterns, providing a robust and secure foundation (7.1 Architecture, 7.2 Code Security). Solidity 0.8.15 mitigates integer overflow/underflow by default, and the `AddressUpgradeable` library is standard. However, the `_beforeTokenTransfer` hook, if overridden in the full `UpgradeableOptimismMintableERC20` contract, could introduce reentrancy risks if not carefully implemented (7.2 Code Security).

GovernanceHigh3/10

The prefill indicates the presence of a minting function, which implies a centralized authority can control the token supply (7.4 Economic). This introduces a significant economic risk due to potential arbitrary inflation. The proxy administration is secured by a 3/6 multisig, enhancing governance security for upgrades (7.5 Governance), but the power to mint new tokens represents a critical economic control point.

UpgradesHigh1/10

The contract is deployed behind an EIP-1967 Transparent Proxy, managed by a 3/6 multisig (7.7 Upgrades). This setup allows for secure future upgrades, reducing single points of failure for administrative actions. The `Initializable` pattern is correctly used to prevent re-initialization, but careful management of storage slots during upgrades is crucial to avoid potential issues.

Security Checklist

Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminMultisig · 3-of-6
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

0.7% in wallets90.9% in contracts
Effective Concentration37.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

Show 4 more pairsShow less

The 20 remaining pairs hold $335.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 Holder32.3%
Top-3 Unlocked61.5%

Key Addresses

Deployer
0x0cf9…aca1
Unlocked LP Held By
0xf8cd…1a740x9abb…27e70x0ba0…c30b0x752c…751d0xc004…785d0x0fdc…40cd0xbcc1…777f0x34cc…9a600x9e5b…d9230x245f…c5c9

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

What Raised This Score

  • Ownership NOT renounced (admin/mint authority retained)
  • Mintable supply — no cap found, dilution unbounded
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (91.7% total → 37.1% effective; 0.7% in EOAs, 90.9% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 High finding(s) from audit
  • 2 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

Related Audits

The Innovation Game (TIG)High RiskBasemateHigh RiskCAPACITRHigh RiskKAITOHigh RiskViciCoin (VCNT)High RiskAvantis (AVNT)High Risk

Would You Like a More Detailed Audit of Coinbase Wrapped Staked ETH?

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

Get Detailed Audit