Is The White Wolf (WOLF) Safe? Smart Contract Security Analysis

Security Findings

1 Crit2 Med2 Info

Critical

Incomplete Vesting Logic Source Code

C-01The provided source code for the `DopplerERC20V1` contract is truncated, specifically omitting the full implementation of the `_available`, `_releaseFor`, and `_releaseAllFor` functions. These functions are central to the contract's core vesting mechanism, responsible for calculating releasable amounts and executing token transfers. Without the complete code, a comprehensive security assessment of the vesting logic, including potential reentrancy vulnerabilities, incorrect calculations, or denial-of-service risks, cannot be performed.

IssueThe provided source code for the `DopplerERC20V1` contract is truncated, specifically omitting the full implementation of the `_available`, `_releaseFor`, and `_releaseAllFor` functions. These functions are central to the contract's core vesting mechanism, responsible for calculating releasable amounts and executing token transfers. Without the complete code, a comprehensive security assessment of the vesting logic, including potential reentrancy vulnerabilities, incorrect calculations, or denial-of-service risks, cannot be performed.

FixProvide the complete and untruncated source code for the `DopplerERC20V1` contract, especially the `_available`, `_releaseFor`, and `_releaseAllFor` functions, to allow for a thorough security review of the vesting mechanism.

StatusUnresolved

Medium

Centralized Control by Controller Role

M-01The `controller` address has the exclusive privilege to call `disableBalanceLimit()`, which permanently deactivates the token's balance limit feature. If the `controller` address is controlled by a single External Owned Account (EOA), it represents a single point of failure. A compromise of this EOA could lead to the balance limit being disabled against the protocol's intent, potentially impacting the token's economic model (7.3 Access Control, 7.5 Governance). While the owner is a multisig, the controller's status is not specified.

IssueThe `controller` address has the exclusive privilege to call `disableBalanceLimit()`, which permanently deactivates the token's balance limit feature. If the `controller` address is controlled by a single External Owned Account (EOA), it represents a single point of failure. A compromise of this EOA could lead to the balance limit being disabled against the protocol's intent, potentially impacting the token's economic model (7.3 Access Control, 7.5 Governance). While the owner is a multisig, the controller's status is not specified.

FixConsider assigning the `controller` role to a multi-signature wallet or a contract with a timelock mechanism. This would introduce a delay or require multiple approvals for critical actions, enhancing security and decentralization.

StatusUnresolved

Medium

Balance Limit Bypass for Excluded Addresses

M-02The `initialize` function explicitly excludes the `owner`, `recipient`, and all `beneficiaries` from the `isBalanceLimitActive` check by setting `isExcludedFromBalanceLimit` to `true` for these addresses. Additionally, the `lockPool` function excludes the designated `pool` address. This design choice means that these privileged addresses can hold token balances exceeding `maxBalanceLimit` even when the balance limit is active. While potentially intended, this significantly narrows the scope of the balance limit and should be clearly documented and understood as a core design decision impacting the token's economic security model (7.4 Economic).

IssueThe `initialize` function explicitly excludes the `owner`, `recipient`, and all `beneficiaries` from the `isBalanceLimitActive` check by setting `isExcludedFromBalanceLimit` to `true` for these addresses. Additionally, the `lockPool` function excludes the designated `pool` address. This design choice means that these privileged addresses can hold token balances exceeding `maxBalanceLimit` even when the balance limit is active. While potentially intended, this significantly narrows the scope of the balance limit and should be clearly documented and understood as a core design decision impacting the token's economic security model (7.4 Economic).

FixClearly document the rationale behind excluding these specific addresses from the balance limit. Ensure that this behavior aligns with the intended economic model and security assumptions. If the intent was for the balance limit to apply more broadly, reconsider these exclusions.

StatusUnresolved

Info

Potential for Front-running in `releaseFor` (Conditional)

I-01The `releaseFor(address beneficiary, uint256 scheduleId, uint256 amount)` function is `external`, allowing any address to call it to release tokens for a specified beneficiary. Depending on the exact implementation of the truncated `_available` and `_releaseFor` functions, this could potentially open a window for front-running attacks. If the calculation of available tokens or the release process has a time-sensitive component that can be exploited, a malicious actor could observe a pending transaction and submit their own transaction with a higher gas price to claim tokens before the intended beneficiary or to grief the transaction (7.2 Code Security).

IssueThe `releaseFor(address beneficiary, uint256 scheduleId, uint256 amount)` function is `external`, allowing any address to call it to release tokens for a specified beneficiary. Depending on the exact implementation of the truncated `_available` and `_releaseFor` functions, this could potentially open a window for front-running attacks. If the calculation of available tokens or the release process has a time-sensitive component that can be exploited, a malicious actor could observe a pending transaction and submit their own transaction with a higher gas price to claim tokens before the intended beneficiary or to grief the transaction (7.2 Code Security).

FixOnce the full source code for `_available` and `_releaseFor` is available, carefully review the logic for any time-sensitive dependencies or race conditions. Consider restricting `releaseFor` to only be callable by the `beneficiary` themselves, or by an authorized `controller` with appropriate safeguards, if front-running is deemed a significant risk.

StatusUnresolved

Info

Ambiguity in Vesting Duration for `duration == 0`

I-02The `initialize` function's validation for vesting schedules allows `s.duration == 0` or `s.duration >= MIN_VESTING_DURATION`. While `MIN_VESTING_DURATION` is set to 1 day, a `duration` of 0 implies immediate vesting. This dual condition is likely intended to support both immediate and time-locked vesting schedules. However, the naming `MIN_VESTING_DURATION` might suggest all vesting should have a minimum duration, which is not strictly enforced if `duration` is 0. This could lead to minor confusion or misinterpretation of the vesting schedule's behavior (7.2 Code Security).

IssueThe `initialize` function's validation for vesting schedules allows `s.duration == 0` or `s.duration >= MIN_VESTING_DURATION`. While `MIN_VESTING_DURATION` is set to 1 day, a `duration` of 0 implies immediate vesting. This dual condition is likely intended to support both immediate and time-locked vesting schedules. However, the naming `MIN_VESTING_DURATION` might suggest all vesting should have a minimum duration, which is not strictly enforced if `duration` is 0. This could lead to minor confusion or misinterpretation of the vesting schedule's behavior (7.2 Code Security).

FixClarify the intended behavior for vesting schedules with `duration == 0` in the contract's documentation. Consider renaming `MIN_VESTING_DURATION` to something like `MIN_NON_ZERO_VESTING_DURATION` or adding a comment to explicitly state that `duration == 0` signifies immediate vesting, distinct from the minimum duration for time-locked schedules.

StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages Solady libraries for ERC20, Ownable, and Initializable functionalities, which contributes to a solid architectural foundation (7.1 Architecture). Input validation in the `initialize` function is robust, preventing common setup errors like array length mismatches or invalid vesting schedules (7.2 Code Security). However, a critical portion of the vesting logic (`_available`, `_releaseFor`) is missing, preventing a comprehensive security assessment of the core token release mechanism. The `releaseFor` function, which allows external calls to release tokens for any beneficiary, could be susceptible to front-running depending on the missing logic.

GovernanceHigh3/10

The contract's economic model includes a balance limit feature intended to restrict token holdings, and vesting schedules to control token distribution over time (7.4 Economic). The `initialize` function includes checks for `maxPreMintPerAddress` and `maxTotalPreMint` to manage initial token allocation. However, the balance limit is explicitly bypassed for the owner, initial recipient, all vesting beneficiaries, and the designated pool address, significantly reducing its scope. The `controller` role has the power to disable the balance limit entirely, introducing a centralized point of control (7.5 Governance). The owner, while a multisig according to prefill, still holds critical powers like locking the pool.

UpgradesHigh1/10

The contract is not identified as an upgradeable proxy, and therefore, upgrade safety considerations (7.7 Upgrades) are not applicable. The `Initializable` pattern is used, but `_disableInitializers()` in the constructor suggests it's intended as a standalone contract or a non-upgradeable implementation.

Security Checklist

2/5 checks passed

Contract VerifiedPass

Ownership RenouncedFail

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Upgrades (30d)0 · stable

Holder Composition

69.5% in top 10

11.6% in wallets57.9% in contracts

Effective Concentration34.8%

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

$124.5K across 3 pairs

Uniswap v4WETHanalysed$124.2K Uniswap v4WETH$183 0xB0C2…9C88BG$98

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 Holder96.8%

Top-3 Unlocked99.1%

Key Addresses

7 addresses

Deployer

0x718f…3eac

Unlocked LP Held By

0xefb3…44b60x3041…a3030x9259…60a60x72e5…8efe0xe6fc…71f10xfe54…b871

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

What Raised This Score

9 factors

Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
Proxy contract (upgradeable — admin can replace logic)
Non-standard proxy storage (Etherscan-confirmed)
Top-10 concentration > 30% (69.5% total → 34.8% effective; 11.6% in EOAs, 57.9% in contracts — moderate)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 96.8% (independent LP — depth risk, pool = 100% of DEX liquidity)
LP top3 unlocked holders = 99.1% (independent LP — depth risk, pool = 100% of DEX liquidity)
1 Critical finding(s) from audit
2 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

Is The White Wolf Safe?

Security Findings

Incomplete Vesting Logic Source Code

Centralized Control by Controller Role

Balance Limit Bypass for Excluded Addresses

Potential for Front-running in `releaseFor` (Conditional)

Ambiguity in Vesting Duration for `duration == 0`

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of The White Wolf?