Quantum Audit Logo
Launch App

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

Is WELL Safe?

Base
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/10Governance3/10Upgrades1/10Checks passed3 of 7Findings1 Critical · 1 High · 1 Medium · 1 Low · 1 Info5
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.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Mintable supply, capped at 10.4%/year
  • Proxy contract
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top3 unlocked holders = 99.5%
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact 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

Security Checklist

as of audit · Sep 43 of 7 checks passed
Contract verifiedVerified
OwnershipRetained
MintMintable
Liquidity lockNot locked
UpgradeabilityUpgradeable
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
46.0%Contracts23.6%Wallets30.4%Everyone else
46.0%Contracts23.6%Wallets30.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
69.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking46.0%
  • Walletsanonymous holders, free to sell23.6%
  • Everyone elsethe rest of the supply30.4%
Effective concentrationwhat the score reads42.0%
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.15M across 13 pairs
Show 4 more pairs

The 3 remaining pairs hold $2 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.13MShare of depth98.5%
Top-1 Unlocked Holder50.0%
Top-3 Unlocked99.5%
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.

Security Findings

1 Critical1 High1 Medium1 Low1 Info
Critical

Double Mint Vulnerability in _mint Function

The 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.C-01

Issue

The 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.

Fix

Review 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.

Status

Unresolved

High

kickGuardian() Function Allows Unauthorized Unpausing

The 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.H-01

Issue

The 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.

Fix

Restrict 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).

Status

Unresolved

Medium

High Centralization of Control

The 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.M-01

Issue

The 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.

Fix

Consider 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.

Status

Unresolved

Low

Potential for Re-initialization in Complex Inheritance

While 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.L-01

Issue

While 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.

Fix

Ensure 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.

Status

Unresolved

Info

Incomplete Source Code for Dependencies

The 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.I-01

Issue

The 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.

Fix

Provide 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.

Status

Unresolved

Analysis

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

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.

Technical4/10Medium risk

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.

Governance3/10High risk

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.

Upgrades1/10High risk

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).

Final RecommendationWhat to do about this score

Immediately address the critical double mint vulnerability by thoroughly reviewing the xERC20 contract's _mint implementation and refactoring xWELL._mint to ensure token supply is incremented only once per mint operation.

Rectify the kickGuardian() function to prevent unauthorized unpausing, ideally by restricting its access to the owner or removing it if its functionality is redundant with ownerUnpause(). Consider implementing a time-lock for sensitive owner operations to enhance security and provide a window for community review.

Contract & Record

1 audit on record
TypeTransparentUpgradeableProxy
NetworkBase
Token age2y
Contract0xa885…96ae
Deployer0xddbf…b52a
Proxy Upgrade Controls
Proxy TypeEip1967 Transparent
AdminOZ ProxyAdmin → OZ_ProxyAdmin
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
WELL 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, 202662Medium

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

Related Audits

6 more on the recordAll audits
Jito Staked SOLJITOSOL · Base62MediumDolphinPOD · Base62Medium0xAgentEVEEVE · Base62MediumBittensorTAO · Base62MediumPalantir Technologies Inc.PLTRC · Base62MediumVelvetBase63Medium

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