Quantum Audit Logo

Is Wrapped BTC Safe?

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

Wrapped BTC WBTC
0x2f2a…5b0f
Arbitrum
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.
Last checked 18d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The audited system comprises a `BeaconProxyFactory` for deploying `ClonableBeaconProxy` instances, which derive their implementation from an `UpgradeableBeacon`. While leveraging well-audited OpenZeppelin components, a critical access control vulnerability in the factory's initialization function allows any caller to set the beacon, potentially leading to a full compromise of all deployed proxies. Additionally, the implementation contract is not source-verified, significantly hindering transparency and trust. Centralized upgrade control via the beacon owner also presents a high single point of failure risk.

1 Critical2 High1 Medium1 Informational
Volume 24h
$25.85M
Liquidity
$39.06M
Price
$80979.3400
Token Age
4y
Top 10 Holders
63.1%

Security Findings

1 Crit2 High1 Med1 Info
Critical

BeaconProxyFactory.initialize Lacks Access Control

C-01The `initialize` function in `BeaconProxyFactory` is designed to set the crucial `beacon` address, which dictates the implementation logic for all proxies deployed by the factory. However, this function lacks any access control, meaning any external address can call it. If an attacker calls `initialize` before the legitimate owner, they can set a malicious beacon address, effectively compromising all future proxies deployed by this factory to point to an attacker-controlled implementation. This leads to a complete loss of control over the system's core logic.
IssueThe `initialize` function in `BeaconProxyFactory` is designed to set the crucial `beacon` address, which dictates the implementation logic for all proxies deployed by the factory. However, this function lacks any access control, meaning any external address can call it. If an attacker calls `initialize` before the legitimate owner, they can set a malicious beacon address, effectively compromising all future proxies deployed by this factory to point to an attacker-controlled implementation. This leads to a complete loss of control over the system's core logic.
FixImplement robust access control for the `initialize` function. It should only be callable once by a trusted entity, preferably the deployer or a designated owner/governance contract. Consider using OpenZeppelin's `Ownable` or a multi-signature wallet for this critical setup function.
StatusUnresolved
High

Unverified Implementation Contract

H-01The implementation contract (0x3f77…ad46) that the `UpgradeableBeacon` points to is not source-verified on Etherscan. This lack of transparency makes it impossible for users, auditors, or the community to inspect the actual code that the `ClonableBeaconProxy` instances will execute. Without verified source code, there is no way to confirm the contract's intended functionality, security, or absence of malicious logic, posing a significant trust and security risk.
IssueThe implementation contract () that the `UpgradeableBeacon` points to is not source-verified on Etherscan. This lack of transparency makes it impossible for users, auditors, or the community to inspect the actual code that the `ClonableBeaconProxy` instances will execute. Without verified source code, there is no way to confirm the contract's intended functionality, security, or absence of malicious logic, posing a significant trust and security risk.
FixImmediately verify the source code of the implementation contract on all relevant block explorers (e.g., Etherscan, Arbiscan). This is a fundamental step for transparency and user trust in any proxy-based system.
StatusUnresolved
High

Centralized Control Over Upgrades

H-02The `UpgradeableBeacon` contract, which dictates the implementation for all deployed proxies, is controlled by a single owner via the `Ownable` pattern. This centralized control means that if the owner's private key is compromised, a malicious actor could upgrade all associated proxies to a harmful implementation, potentially leading to a complete loss of user funds or system manipulation. This represents a single point of failure for the entire system's upgradeability.
IssueThe `UpgradeableBeacon` contract, which dictates the implementation for all deployed proxies, is controlled by a single owner via the `Ownable` pattern. This centralized control means that if the owner's private key is compromised, a malicious actor could upgrade all associated proxies to a harmful implementation, potentially leading to a complete loss of user funds or system manipulation. This represents a single point of failure for the entire system's upgradeability.
FixConsider decentralizing or enhancing the security of the upgrade mechanism. Options include transferring ownership to a multi-signature wallet (e.g., Gnosis Safe), implementing a time-lock contract for upgrade delays, or integrating a more robust governance mechanism to approve upgrades.
StatusUnresolved
Medium

No Initialization Data Passed to ClonableBeaconProxy

M-01The `ClonableBeaconProxy` constructor calls `BeaconProxy(ProxySetter(msg.sender).beacon(), "")`, passing an empty `data` parameter. This means that if the underlying implementation contract has an `initialize` function (a common pattern for upgradeable contracts), it will not be called automatically during the proxy's deployment. If the implementation requires initialization for proper functioning or to set critical parameters, it must be initialized separately after proxy deployment. Failure to do so could leave the implementation in an uninitialized or vulnerable state.
IssueThe `ClonableBeaconProxy` constructor calls `BeaconProxy(ProxySetter(msg.sender).beacon(), "")`, passing an empty `data` parameter. This means that if the underlying implementation contract has an `initialize` function (a common pattern for upgradeable contracts), it will not be called automatically during the proxy's deployment. If the implementation requires initialization for proper functioning or to set critical parameters, it must be initialized separately after proxy deployment. Failure to do so could leave the implementation in an uninitialized or vulnerable state.
FixEnsure that the implementation contract is designed to either be immutable (not requiring initialization) or that a robust and secure process is in place to call its `initialize` function immediately after the proxy's deployment. Document this initialization requirement clearly for operators.
StatusUnresolved
Info

Use of CREATE2 for Deterministic Proxy Addresses

I-01The `BeaconProxyFactory` utilizes the `CREATE2` opcode via OpenZeppelin's `Create2` library to deploy `ClonableBeaconProxy` instances. This allows for deterministic address generation, meaning the address of a proxy can be calculated in advance using the factory address, a salt, and the proxy's creation bytecode. While a powerful feature, it implies that if a specific salt is reused, deployment will fail. The factory mitigates this by generating a unique salt based on `msg.sender` and `userSalt`.
IssueThe `BeaconProxyFactory` utilizes the `CREATE2` opcode via OpenZeppelin's `Create2` library to deploy `ClonableBeaconProxy` instances. This allows for deterministic address generation, meaning the address of a proxy can be calculated in advance using the factory address, a salt, and the proxy's creation bytecode. While a powerful feature, it implies that if a specific salt is reused, deployment will fail. The factory mitigates this by generating a unique salt based on `msg.sender` and `userSalt`.
FixNo direct recommendation for a vulnerability, as this is an intended feature. However, ensure that the implications of deterministic addresses (e.g., potential for 'counterfactual interactions' or pre-funding addresses) are fully understood and align with the project's design goals.
StatusUnresolved

Category Ratings

TechnicalMedium5/10

The technical architecture (7.1 Architecture) utilizes the OpenZeppelin Beacon Proxy pattern, enabling efficient deployment of multiple proxies pointing to a single upgradeable beacon. The `BeaconProxyFactory` uses `CREATE2` for deterministic proxy address generation, a robust feature. However, a critical flaw exists in the `initialize` function of `BeaconProxyFactory` (7.3 Access Control), which lacks any access control, allowing any external caller to set the crucial beacon address. This vulnerability could lead to a complete compromise of the factory and all proxies it deploys. The `ClonableBeaconProxy` constructor correctly interacts with the factory to retrieve the beacon address.

GovernanceHigh2/10

The system's governance (7.5 Governance) relies on a centralized `Ownable` pattern for the `UpgradeableBeacon` contract. The owner of this beacon has the sole authority to upgrade the implementation contract for all associated proxies. This single point of control introduces a high economic risk (7.4 Economic) as a compromise of the owner's private key would allow a malicious actor to deploy a rogue implementation, potentially leading to a loss of user funds or system manipulation. There are no explicit economic mechanisms or fees within the factory or proxy contracts themselves.

UpgradesHigh1/10

The upgradeability mechanism (7.7 Upgrades) is based on the Beacon Proxy pattern, where all `ClonableBeaconProxy` instances delegate calls to an implementation address managed by a single `UpgradeableBeacon`. This allows for efficient upgrades across many proxies by simply updating the beacon's implementation. However, the `UpgradeableBeacon` is controlled by a single owner, making the upgrade process highly centralized. Furthermore, the current implementation contract is not source-verified, which severely impacts the transparency and auditability of any future upgrades.

Security Checklist

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

Proxy Upgrade Controls

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

Holder Composition

63.1% in top 10
0.0% in wallets63.1% in contracts
Effective Concentration25.2%

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

$45.41M across 30 pairs
UniswapWETHanalysed$39.06M86.0%UniswapUSD₮0$4.82M10.6%UniswapWETH$767.6K1.7%UniswapUSD₮0$239.3K0.5%Camelot v3WETH$91.0K0.2%Sushiswap v3WETH$85.4K0.2%
Show 4 more pairsShow less
DeltaswapWETH$76.0K0.2%UniswapUSDC$70.4K0.2%PancakeswapUSD₮0$46.0K0.1%UniswapWETH$33.9K0.1%

The 20 remaining pairs hold $119.6K 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 Holder22.6%
Top-3 Unlocked42.1%

Key Addresses

11 addresses
Deployer
0x3fe3…000f
Unlocked LP Held By
0x3e4f…0b160x5437…57850x7873…9aa10xd668…77fc0x6286…f2fc0xf809…42590x9ce4…4c890x9c16…4a6f0xaa5c…6e240xb8c7…4c7f

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

What Raised This Score

8 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Proxy contract (upgradeable — admin can replace logic)
  • Complex proxy pattern (BEACON)
  • Top-10 concentration > 20% (63.1% total → 25.2% effective; 0.0% in EOAs, 63.1% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • 1 Critical finding(s) from audit
  • 2 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

Related Audits

6 more on the record
NOXCAT (NOX)High RiskMAGICHigh Riskether.fi governance token (ETHFI)High RiskEquilibria Token (EQB)High RiskCoW Protocol Token (COW)High RiskNolaHigh Risk

Would You Like a More Detailed Audit of Wrapped BTC?

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

Get Detailed Audit