Quantum Audit Logo

Is HandlPay Safe?

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

HandlPay HANDL
0x3bbc…4425
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

This audit covers the HandlToken and HANDLSwap contracts. The HandlToken is an OFT-compliant ERC-20 token with Ownable access control. The HANDLSwap contract provides a simple fixed-price exchange between HANDL and USDC, managed by a single administrator. Key findings include significant centralization risks in the swap contract, a potential for decimal mismatch in swap calculations, and a lack of user slippage protection. The contracts are generally well-structured, but the high degree of administrative control introduces a single point of failure.

1 High1 Medium1 Low2 Informational
Volume 24h
$80.8K
Liquidity
$44.5K
Price
$0.001978
Token Age
4mo
Top 10 Holders
68.9%

Security Findings

1 High1 Med1 Low2 Info
High

Centralized Control and Single Point of Failure in HANDLSwap

H-01The HANDLSwap contract grants extensive control to a single `admin` address, set immutably during deployment. This administrator can unilaterally set the swap price (`setPrice`), pause all trading activities (`setPaused`), and withdraw all HANDL and USDC tokens held by the contract (`withdrawHANDL`, `withdrawUSDC`). This high degree of centralization (7.3, 7.5, 7.8) creates a significant single point of failure. A compromise of the admin's private key could lead to complete loss of funds, arbitrary price manipulation, and denial of service for all users.
IssueThe HANDLSwap contract grants extensive control to a single `admin` address, set immutably during deployment. This administrator can unilaterally set the swap price (`setPrice`), pause all trading activities (`setPaused`), and withdraw all HANDL and USDC tokens held by the contract (`withdrawHANDL`, `withdrawUSDC`). This high degree of centralization (7.3, 7.5, 7.8) creates a significant single point of failure. A compromise of the admin's private key could lead to complete loss of funds, arbitrary price manipulation, and denial of service for all users.
FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the `admin` role to require multiple approvals for critical operations. For less time-sensitive actions like price updates, consider adding a timelock mechanism to allow users to react to impending changes. Explore options for progressive decentralization of control over time.
StatusUnresolved
Medium

Potential Decimal Mismatch Risk in Swap Calculations

M-01The `buyHANDL` and `sellHANDL` functions perform arithmetic operations involving `1e18` and `usdcPerHandl` to calculate swap amounts. While these calculations are mathematically sound for specific decimal assumptions (e.g., HANDL 18 decimals, USDC 6 decimals, and `usdcPerHandl` representing the price in 6-decimal USDC), these assumptions are not explicitly stated or enforced in the code (7.2). If `usdcPerHandl` is set with an incorrect decimal precision relative to USDC, or if USDC itself does not have 6 decimals, trades could result in incorrect token amounts being exchanged, leading to user losses or contract insolvency.
IssueThe `buyHANDL` and `sellHANDL` functions perform arithmetic operations involving `1e18` and `usdcPerHandl` to calculate swap amounts. While these calculations are mathematically sound for specific decimal assumptions (e.g., HANDL 18 decimals, USDC 6 decimals, and `usdcPerHandl` representing the price in 6-decimal USDC), these assumptions are not explicitly stated or enforced in the code (7.2). If `usdcPerHandl` is set with an incorrect decimal precision relative to USDC, or if USDC itself does not have 6 decimals, trades could result in incorrect token amounts being exchanged, leading to user losses or contract insolvency.
FixExplicitly document the expected decimal precision for HANDL, USDC, and `usdcPerHandl` in the contract's NatSpec comments. Consider adding a mechanism to verify or enforce the decimal places of the underlying ERC-20 tokens, if possible, or ensure robust off-chain procedures for setting `usdcPerHandl` correctly. Implement comprehensive unit tests covering various decimal scenarios.
StatusUnresolved
Low

Lack of Slippage Protection for Users

L-01The `buyHANDL` and `sellHANDL` functions execute swaps at the current `usdcPerHandl` price without any user-defined slippage tolerance (7.4). While the price is fixed by the admin, an admin could theoretically change the price between a user's transaction submission and its inclusion in a block. Without slippage protection, users could receive fewer tokens than expected if the price changes unfavorably, or their transaction could revert if the price moves too much.
IssueThe `buyHANDL` and `sellHANDL` functions execute swaps at the current `usdcPerHandl` price without any user-defined slippage tolerance (7.4). While the price is fixed by the admin, an admin could theoretically change the price between a user's transaction submission and its inclusion in a block. Without slippage protection, users could receive fewer tokens than expected if the price changes unfavorably, or their transaction could revert if the price moves too much.
FixConsider adding an optional `minHandlAmount` or `maxUsdcAmount` parameter to the `buyHANDL` and `sellHANDL` functions, respectively. This would allow users to specify their acceptable slippage, ensuring they do not receive significantly less than expected or pay significantly more due to price changes or front-running (though less critical with an admin-set price).
StatusUnresolved
Info

Hardcoded Chain ID for Initial Minting

I-01The `HandlToken` constructor includes a condition `if(block.chainid == 137)` to mint initial tokens only on Polygon (chain ID 137). This design choice (7.1) means that if the contract is deployed on any other chain, the initial minting to `msg.sender` will not occur. While this is likely an intentional deployment strategy for a multi-chain token, it's a hardcoded dependency.
IssueThe `HandlToken` constructor includes a condition `if(block.chainid == 137)` to mint initial tokens only on Polygon (chain ID 137). This design choice (7.1) means that if the contract is deployed on any other chain, the initial minting to `msg.sender` will not occur. While this is likely an intentional deployment strategy for a multi-chain token, it's a hardcoded dependency.
FixEnsure this hardcoded chain ID aligns with the intended deployment strategy across all target networks. If initial minting is desired on other chains, the condition would need to be adjusted or removed, or a separate minting mechanism implemented post-deployment.
StatusUnresolved
Info

No Emergency Stop for Admin Fund Withdrawals

I-02The `HANDLSwap` contract includes a `setPaused` function to halt trading, but the `withdrawHANDL` and `withdrawUSDC` functions, which allow the admin to drain funds, are not subject to the `whenNotPaused` modifier (7.8). This means that even if the contract is paused due to an emergency, the admin retains the ability to withdraw all funds. While the admin is trusted, this could be a concern if the admin key is compromised during a pause event.
IssueThe `HANDLSwap` contract includes a `setPaused` function to halt trading, but the `withdrawHANDL` and `withdrawUSDC` functions, which allow the admin to drain funds, are not subject to the `whenNotPaused` modifier (7.8). This means that even if the contract is paused due to an emergency, the admin retains the ability to withdraw all funds. While the admin is trusted, this could be a concern if the admin key is compromised during a pause event.
FixConsider whether `withdrawHANDL` and `withdrawUSDC` should also be subject to a `whenNotPaused` modifier, or if a separate, more secure withdrawal mechanism (e.g., requiring a multi-sig or timelock) should be implemented, especially for large amounts. This would provide an additional layer of protection even if the admin key is compromised.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The technical architecture (7.1) of both contracts is straightforward. The HandlToken leverages OpenZeppelin's Ownable and LayerZero's OFT for standard and cross-chain functionality. The HANDLSwap contract implements basic fixed-price swap logic. Code security (7.2) is generally good, with appropriate use of `require` statements and OpenZeppelin libraries. However, a potential decimal mismatch in swap calculations for USDC and HANDL could lead to incorrect trade amounts. Reentrancy is not a concern due to the absence of external ETH transfers and proper ERC-20 interaction patterns.

GovernanceMedium4/10

The economic model (7.4) of the HANDLSwap contract is a simple fixed-price exchange, entirely controlled by an administrator. The governance (7.5) is highly centralized, with a single `admin` address having immutable control over critical functions. This admin can set the swap price, pause trading, and withdraw all HANDL and USDC tokens from the contract. This creates a significant single point of failure, as a compromised admin key could lead to fund loss or market manipulation. There is no community governance or multi-signature control implemented.

UpgradesLow8/10

Neither the HandlToken nor the HANDLSwap contract implements any upgrade mechanism (7.7). Both contracts are designed to be immutable once deployed. This eliminates upgrade-related risks such as proxy misconfigurations or malicious upgrade proposals, but also means that any discovered vulnerabilities or desired feature changes would require a new contract deployment and migration.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

68.9% in top 10
11.2% in wallets57.7% in contracts
Effective Concentration34.3%

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

$44.5K across 2 pairs
AerodromeUSDCanalysed$44.5K100.0%Uniswap v4ETH$20.0%

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.2%
Top-3 Unlocked93.0%

Key Addresses

7 addresses
Deployer
0xef87…ab19
Unlocked LP Held By
0x5c3b…25af0xc3e2…7ea00x3662…ba860x73fc…1ee50xece0…b5330xd1d7…84a2

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

What Raised This Score

8 factors
  • Top-10 concentration > 30% (68.9% total → 34.3% effective; 11.2% in EOAs, 57.7% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($44,548 across 2 pairs — thin market)
  • LP top1 unlocked holder = 50.2% (independent LP — depth risk)
  • LP top3 unlocked holders = 93.0% (independent LP — depth risk)
  • 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
Horizen (ZEN)Medium RiskSquid (QUID)Medium RiskDerive (DRV)Medium RiskVenice Deity (VVVEITY)Medium Risktokenbot (CLANKER)Medium RiskAave Token (AAVE)Medium Risk

Would You Like a More Detailed Audit of HandlPay?

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

Get Detailed Audit