Is A Hunters Dream (CAW) Safe? Smart Contract Security Analysis

Security Findings

1 Low2 Info

Low

ERC20 `approve`/`transferFrom` Race Condition

L-01The standard ERC20 `approve` function is susceptible to a front-running attack where a malicious spender can exploit a pending `approve` transaction to drain funds. If a user approves an amount `X`, and then attempts to approve a new amount `Y` (where `Y < X`), a front-runner can observe the second transaction, quickly execute a `transferFrom` for amount `X`, and then the second `approve` transaction will set the allowance to `Y`. This effectively allows the front-runner to spend `X + Y`. While `increaseAllowance` and `decreaseAllowance` functions are provided to mitigate this for direct allowance modifications, the base `approve` function remains vulnerable.

IssueThe standard ERC20 `approve` function is susceptible to a front-running attack where a malicious spender can exploit a pending `approve` transaction to drain funds. If a user approves an amount `X`, and then attempts to approve a new amount `Y` (where `Y < X`), a front-runner can observe the second transaction, quickly execute a `transferFrom` for amount `X`, and then the second `approve` transaction will set the allowance to `Y`. This effectively allows the front-runner to spend `X + Y`. While `increaseAllowance` and `decreaseAllowance` functions are provided to mitigate this for direct allowance modifications, the base `approve` function remains vulnerable.

FixEducate users on the risks of directly using `approve` to change an existing allowance. It is generally recommended to set allowance to zero before setting a new non-zero allowance, or exclusively use `increaseAllowance`/`decreaseAllowance` for atomic allowance adjustments.

StatusUnresolved

Info

Unchecked Return Value of External Call in Constructor

I-01The `ServicePayer` constructor makes an external call to `IPayable(receiver).pay{value: msg.value}(serviceName)`. The return value of this external call is not checked. If `feeReceiver_` is an Externally Owned Account (EOA), the call to `pay` will silently fail. If `feeReceiver_` is a contract that implements `pay` but returns `false` without reverting, the constructor would still succeed, but the payment might not have been processed as intended. While this occurs only during deployment and does not affect the token's runtime security, it could lead to unexpected behavior for the deployer regarding the fee payment.

IssueThe `ServicePayer` constructor makes an external call to `IPayable(receiver).pay{value: msg.value}(serviceName)`. The return value of this external call is not checked. If `feeReceiver_` is an Externally Owned Account (EOA), the call to `pay` will silently fail. If `feeReceiver_` is a contract that implements `pay` but returns `false` without reverting, the constructor would still succeed, but the payment might not have been processed as intended. While this occurs only during deployment and does not affect the token's runtime security, it could lead to unexpected behavior for the deployer regarding the fee payment.

FixConsider adding a `require(success, 'Payment failed')` check after the external call if the `pay` function is expected to return a boolean indicating success. Alternatively, ensure that the `IPayable` interface guarantees reversion on failure. For EOAs, a direct `transfer` or `call` without a function signature would be more appropriate if a simple Ether transfer is intended.

StatusUnresolved

Info

Fixed Supply and Lack of Administrative Control

I-02The `StandardERC20` token is designed with a fixed initial supply, minted entirely to the deployer during construction. There are no administrative functions to mint additional tokens, burn tokens (beyond the standard `_burn` which is not exposed publicly), pause transfers, or upgrade the contract. This design choice results in a fully decentralized token with predictable supply mechanics.

IssueThe `StandardERC20` token is designed with a fixed initial supply, minted entirely to the deployer during construction. There are no administrative functions to mint additional tokens, burn tokens (beyond the standard `_burn` which is not exposed publicly), pause transfers, or upgrade the contract. This design choice results in a fully decentralized token with predictable supply mechanics.

FixThis is a design decision and not a vulnerability. Ensure this fixed supply and lack of administrative control aligns with the project's long-term vision and requirements. If future flexibility (e.g., for ecosystem grants, emergency pausing, or bug fixes) is desired, consider implementing an `Ownable` or `AccessControl` pattern with corresponding functions.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The contract demonstrates a robust technical foundation (7.1 Architecture, 7.2 Code Security). It correctly utilizes Solidity 0.8+ default overflow/underflow checks and `unchecked` blocks where appropriate, preventing common integer manipulation vulnerabilities. Standard ERC20 functions are implemented, including `_transfer`, `_mint`, `_burn`, and `_approve`, with proper zero-address checks. The `ServicePayer` constructor includes an external call to `IPayable.pay` (7.6 External), which is a minor point for deployment robustness but does not pose a runtime security risk to the token itself. Access control (7.3 Access Control) is limited to standard ERC20 permissions, with no additional administrative roles.

GovernanceMedium5/10

The token's economic model (7.4 Economic) is straightforward: a fixed supply is minted to the deployer during construction, with no further minting or burning capabilities exposed. This design choice provides predictability and decentralization. There are no governance mechanisms (7.5 Governance) implemented within the contract, meaning control over the token's core parameters is immutable post-deployment.

UpgradesLow7/10

The contract is not designed as an upgradeable proxy (7.7 Upgrades). This eliminates upgrade-specific risks such as proxy implementation mismatches, storage collisions, or insecure upgrade paths. The contract's immutability ensures its behavior remains consistent throughout its lifecycle.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

49.3% in top 10

43.8% in wallets5.4% in contracts

Effective Concentration46.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.86M across 3 pairs

Uniswap v2WETHanalysed$1.86M CurveWETH$3.0K Uniswap v3WETH$1.6K

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

LP Locked100.0% · Dead, Null Address

Key Addresses

9 addresses

Deployer

0x36b5…e005

Unlocked LP Held By

0x055c…7f5d0x5cc2…1fcb0x4d77…f6a50xb3ac…68a00x1d64…59380x2277…fe0d0x0000…8a900x2112…d4cb

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

What Raised This Score

3 factors

Ownership status UNKNOWN (owner could not be resolved)
Top-10 concentration > 30% (49.3% total → 46.0% effective; 43.8% in EOAs, 5.4% in contracts — moderate)
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

Not Signed In

Is A Hunters Dream Safe?

Security Findings

ERC20 `approve`/`transferFrom` Race Condition

Unchecked Return Value of External Call in Constructor

Fixed Supply and Lack of Administrative Control

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of A Hunters Dream?