Quantum Audit Logo

Is WELL Safe?

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

WELL WELL
0xa885…96ae
Base Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The audit of the xWELL token contract, deployed as an upgradeable proxy, identified a critical vulnerability related to a potential double mint in the `_mint` function due to multiple inheritance. Additionally, a high-severity issue was found where the `kickGuardian()` function allows unauthorized unpausing of the contract. The contract utilizes standard OpenZeppelin upgradeable patterns and robust access control via a multisig owner, but the identified critical and high-severity issues require immediate attention to prevent severe economic consequences and compromise of the emergency pause mechanism. The audit was limited by the truncation of dependent contract source code.

1 Critical1 High1 Medium1 Low1 Informational
Volume 24h
$339.3K
Liquidity
$1.13M
Price
$0.001812
Token Age
2y
Top 10 Holders
69.6%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Double Mint Vulnerability in `_mint` Function

C-01The `xWELL._mint` function explicitly calls `super._mint(user, amount)` and `xERC20._mint(user, amount)`. The `super._mint` call resolves to `ERC20VotesUpgradeable._mint`, which in turn calls `ERC20Upgradeable._mint` to increment `_balances` and `_totalSupply`. If `xERC20._mint` also calls `ERC20Upgradeable._mint` or directly modifies `_balances` and `_totalSupply` (a common pattern for ERC20 implementations), then the token supply will be incremented twice for every mint operation. This would lead to an uncontrolled and incorrect token supply, severely devaluing the token and breaking core economic invariants.
IssueThe `xWELL._mint` function explicitly calls `super._mint(user, amount)` and `xERC20._mint(user, amount)`. The `super._mint` call resolves to `ERC20VotesUpgradeable._mint`, which in turn calls `ERC20Upgradeable._mint` to increment `_balances` and `_totalSupply`. If `xERC20._mint` also calls `ERC20Upgradeable._mint` or directly modifies `_balances` and `_totalSupply` (a common pattern for ERC20 implementations), then the token supply will be incremented twice for every mint operation. This would lead to an uncontrolled and incorrect token supply, severely devaluing the token and breaking core economic invariants.
FixReview the `xERC20` contract's `_mint` implementation. If it calls `ERC20Upgradeable._mint` or directly modifies `_balances` and `_totalSupply`, then the `xWELL._mint` function must be refactored. A common pattern for multiple inheritance is to call `super._mint()` once (which resolves to the most derived parent's implementation, e.g., `ERC20VotesUpgradeable`) and then integrate any additional logic from `xERC20` without redundant calls to the core ERC20 state modification functions.
StatusUnresolved
High

`kickGuardian()` Function Allows Unauthorized Unpausing

H-01The `kickGuardian()` function is `public` and lacks any access control. It can be called by *anyone* if `pauseUsed()` is true and the contract is `whenNotPaused`. This function calls `_resetPauseState()`, which sets `pauseGuardian` to `address(0)` and `pauseStartTime` to `0`. This effectively removes the designated `pauseGuardian` and unpauses the contract if it was paused by the guardian. This undermines the emergency pause mechanism, allowing any malicious actor or even a confused user to bypass the guardian's control and unpause the system prematurely, potentially during an ongoing incident.
IssueThe `kickGuardian()` function is `public` and lacks any access control. It can be called by *anyone* if `pauseUsed()` is true and the contract is `whenNotPaused`. This function calls `_resetPauseState()`, which sets `pauseGuardian` to `address(0)` and `pauseStartTime` to `0`. This effectively removes the designated `pauseGuardian` and unpauses the contract if it was paused by the guardian. This undermines the emergency pause mechanism, allowing any malicious actor or even a confused user to bypass the guardian's control and unpause the system prematurely, potentially during an ongoing incident.
FixRestrict access to `kickGuardian()` to `onlyOwner` or remove the function if its intended purpose is not to allow general users to override the pause guardian. If the intent is for the owner to 'kick' a misbehaving guardian, the `ownerUnpause()` function already covers this by setting `pauseGuardian` to `address(0)`.
StatusUnresolved
Medium

High Centralization of Control

M-01The `owner` (a multisig) possesses extensive control over critical contract parameters and operations. This includes the ability to set buffer caps, rate limits, pause duration, add/remove bridges, and grant/revoke the pause guardian. While the use of a multisig mitigates the risk of a single point of failure, this high degree of centralized control means the protocol's security and economic stability heavily rely on the owner's integrity, operational security, and responsiveness.
IssueThe `owner` (a multisig) possesses extensive control over critical contract parameters and operations. This includes the ability to set buffer caps, rate limits, pause duration, add/remove bridges, and grant/revoke the pause guardian. While the use of a multisig mitigates the risk of a single point of failure, this high degree of centralized control means the protocol's security and economic stability heavily rely on the owner's integrity, operational security, and responsiveness.
FixConsider implementing a time-lock for sensitive owner operations (e.g., `setRateLimitPerSecond`, `setBufferCap`, `setPauseDuration`, `addBridge`, `removeBridge`) to introduce a delay between the owner's decision and its execution. This provides a window for review and potential intervention, enhancing transparency and security. Explore progressive decentralization for some parameters if feasible in the future.
StatusUnresolved
Low

Potential for Re-initialization in Complex Inheritance

L-01While `xWELL` correctly uses `_disableInitializers()` and the `initializer` modifier for its `initialize` function, ensuring the main contract is initialized once, complex inheritance hierarchies with upgradeable contracts always carry a subtle risk of re-initialization. Specifically, if `ConfigurablePauseGuardian` or its base contracts had their own `initialize` functions that could be called independently of `xWELL.initialize`, it could lead to state corruption. In this case, `__Pausable_init()` is called correctly, but the general principle warrants attention.
IssueWhile `xWELL` correctly uses `_disableInitializers()` and the `initializer` modifier for its `initialize` function, ensuring the main contract is initialized once, complex inheritance hierarchies with upgradeable contracts always carry a subtle risk of re-initialization. Specifically, if `ConfigurablePauseGuardian` or its base contracts had their own `initialize` functions that could be called independently of `xWELL.initialize`, it could lead to state corruption. In this case, `__Pausable_init()` is called correctly, but the general principle warrants attention.
FixEnsure that all inherited upgradeable contracts are initialized exactly once through the main `initialize` function of the most derived contract. Regularly review the initialization patterns, especially after upgrades or changes to the inheritance structure, to prevent accidental re-initialization of base contract state variables.
StatusUnresolved
Info

Incomplete Source Code for Dependencies

I-01The provided source code for the `xWELL` contract truncates the `MintLimits.sol` file and does not include the `xERC20.sol` contract. A comprehensive security audit requires access to the complete and verified source code of all directly inherited and imported contracts, especially `xERC20` given its critical role in the `_mint` override.
IssueThe provided source code for the `xWELL` contract truncates the `MintLimits.sol` file and does not include the `xERC20.sol` contract. A comprehensive security audit requires access to the complete and verified source code of all directly inherited and imported contracts, especially `xERC20` given its critical role in the `_mint` override.
FixProvide the full source code for `xERC20.sol` and `MintLimits.sol` to allow for a comprehensive security review and to fully assess the critical `_mint` vulnerability.
StatusUnresolved

Category Ratings

TechnicalMedium4/10

The xWELL contract leverages OpenZeppelin's upgradeable patterns and ERC-20 standards, demonstrating a solid architectural foundation (7.1 Architecture). However, a critical code security vulnerability (7.2 Code Security) exists in the `_mint` function, potentially leading to a double mint due to incorrect handling of multiple inheritance. Furthermore, the `kickGuardian()` function presents a high-severity access control flaw (7.3 Access Control), allowing any user to bypass the designated pause guardian and unpause the contract. While OpenZeppelin's `SafeCast` mitigates integer issues, these core logic flaws significantly elevate technical risk.

GovernanceHigh3/10

The economic model includes a `MAX_SUPPLY` and owner-configurable rate limits and buffer caps for minting, which provides flexibility and a hard cap on total supply (7.4 Economic). However, the critical double mint vulnerability would severely undermine this model, leading to uncontrolled inflation. Governance (7.5 Governance) is centralized with a multisig owner controlling all critical parameters, including pausing, rate limits, and upgrades. While a multisig enhances security over a single EOA, this centralization requires high operational security and trust in the owner.

UpgradesHigh1/10

The contract is deployed using the TransparentUpgradeableProxy pattern, adhering to OpenZeppelin's best practices for upgradeability (7.7 Upgrades). The `_disableInitializers()` in the constructor and the `initializer` modifier ensure proper initialization. However, the potential double mint issue highlights the importance of careful storage layout and function override management during upgrades, especially with complex inheritance. The owner (multisig) manages upgrades, which is a standard and secure operational practice (7.8 Operations).

Security Checklist

1/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionFail
Liquidity LockedFail
Not a ProxyFail
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

69.6% in top 10
23.6% in wallets46.0% in contracts
Effective Concentration42.0%

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

$1.15M across 13 pairs
AerodromeWETHanalysed$1.13M98.5%AerodromeAERO$6.2K0.5%AerodromeWETH$5.6K0.5%Uniswap v3WETH$4.1K0.4%0xba34…EEF9WETH$7550.1%Uniswap v2WETH$5130.0%
Show 4 more pairsShow less
PancakeswapWETH$760.0%AerodromeUSDC$200.0%PancakeswapWETH$70.0%Uniswap v4ETH$40.0%

The 3 remaining pairs hold $2 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 Holder50.0%
Top-3 Unlocked99.5%

Key Addresses

5 addresses
Deployer
0xddbf…b52a
Unlocked LP Held By
0x39f0…87e90x88f9…0c590x5ffc…87500x90dc…6621

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

What Raised This Score

10 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Mintable supply, capped at 10.4%/year
  • Proxy contract (upgradeable — admin can replace logic)
  • Top-10 concentration > 30% (69.6% total → 42.0% effective; 23.6% in EOAs, 46.0% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top3 unlocked holders = 99.5% (independent LP — depth risk, pool = 98% of DEX liquidity)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium 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
Jito Staked SOL (JITOSOL)High RiskDolphin (POD)High Risk0xAgentEVE (EVE)High RiskBittensor (TAO)High RiskVelvetHigh RiskLayerZero (ZRO)High Risk

Would You Like a More Detailed Audit of WELL?

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

Get Detailed Audit