Quantum Audit Logo

Is defi-native a Scam?

Early-stage security check — honeypot & rug-pull analysis

defi-native DEFI-NATIVE
0xad46…2ba3
Base Not verifiedLast checked 3d ago 1 audit on record New Launch · 2d old
DexScreener ↗
How is this score calculated? → Critical Risk
Executive SummaryAI Copilot

The DopplerERC20V1 contract implements an ERC20 token with vesting capabilities and a balance limit mechanism. The audit identified a critical vulnerability where the intended balance limit mechanism is not enforced due to a missing override of the `_beforeTokenTransfer` hook. This renders the balance limit ineffective. Additionally, the contract exhibits centralized control by the owner and controller roles. The core vesting logic could not be fully assessed due to truncated code. Addressing the critical functional flaw is paramount to ensure the intended security properties of the token.

1 Critical1 Medium1 Low2 Informational
! Early-stage analysis. This token has limited on-chain history (2d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$22.3K
Liquidity
$79.7K
Price
$0.000001473
Token Age
2d
Top 10 Holders
65.9%

Security Findings

1 Crit1 Med1 Low2 Info
Critical

Missing `_beforeTokenTransfer` Override for Balance Limit Enforcement

C-01The contract defines a balance limit mechanism (`isBalanceLimitActive`, `maxBalanceLimit`, `balanceLimitEnd`, `isExcludedFromBalanceLimit`) and related access control (`disableBalanceLimit` by controller). However, the provided code snippet does not include an override of the `_beforeTokenTransfer` hook from the inherited `ERC20` (Solady) contract. Without this override, the `maxBalanceLimit` and `balanceLimitEnd` checks are not enforced during token transfers, rendering the entire balance limit mechanism ineffective for its primary purpose.
IssueThe contract defines a balance limit mechanism (`isBalanceLimitActive`, `maxBalanceLimit`, `balanceLimitEnd`, `isExcludedFromBalanceLimit`) and related access control (`disableBalanceLimit` by controller). However, the provided code snippet does not include an override of the `_beforeTokenTransfer` hook from the inherited `ERC20` (Solady) contract. Without this override, the `maxBalanceLimit` and `balanceLimitEnd` checks are not enforced during token transfers, rendering the entire balance limit mechanism ineffective for its primary purpose.
FixImplement the `_beforeTokenTransfer` hook to include the necessary checks for `isBalanceLimitActive`, `balanceLimitEnd`, `maxBalanceLimit`, and `isExcludedFromBalanceLimit` for the `to` address before allowing any token transfer.
StatusUnresolved
Medium

Centralized Control by Owner/Controller

M-01The contract utilizes the `Ownable` pattern, granting the `owner` significant administrative privileges, including `lockPool`, `unlockPool`, and `updateTokenURI`. Additionally, a `controller` role is introduced with the ability to `disableBalanceLimit`. While common for initial deployment phases, this centralization of power introduces a single point of failure and potential for malicious or compromised control.
IssueThe contract utilizes the `Ownable` pattern, granting the `owner` significant administrative privileges, including `lockPool`, `unlockPool`, and `updateTokenURI`. Additionally, a `controller` role is introduced with the ability to `disableBalanceLimit`. While common for initial deployment phases, this centralization of power introduces a single point of failure and potential for malicious or compromised control.
FixConsider implementing a multi-signature wallet for the `owner` and `controller` roles to enhance security and decentralization. For critical functions, explore time-locks or community governance mechanisms if the project matures.
StatusUnresolved
Low

Potential Gas Cost for `computeAvailableVestedAmount` with Many Schedules

L-01The `computeAvailableVestedAmount(address beneficiary)` function iterates through all schedule IDs associated with a beneficiary via `_scheduleIdsOf[beneficiary]`. If a beneficiary accumulates a very large number of individual vesting schedules, this array could grow significantly, leading to increased gas costs for calling this view function. While view functions don't directly cost the caller gas on-chain, they can impact off-chain queries and potentially on-chain calls if another contract were to query it.
IssueThe `computeAvailableVestedAmount(address beneficiary)` function iterates through all schedule IDs associated with a beneficiary via `_scheduleIdsOf[beneficiary]`. If a beneficiary accumulates a very large number of individual vesting schedules, this array could grow significantly, leading to increased gas costs for calling this view function. While view functions don't directly cost the caller gas on-chain, they can impact off-chain queries and potentially on-chain calls if another contract were to query it.
FixFor beneficiaries expected to have a very high number of vesting schedules, consider alternative data structures or aggregation methods to reduce iteration costs. For typical use cases, the current implementation is likely acceptable.
StatusUnresolved
Info

Truncated Code Prevents Full Vesting Logic Review

I-01The provided contract snippet is truncated, specifically omitting the full implementation of the `_available`, `_releaseFor`, and `_releaseAllFor` internal functions. These functions are central to the core vesting mechanism, calculating releasable amounts and handling token transfers. Without their complete code, a comprehensive security assessment of the vesting logic cannot be performed.
IssueThe provided contract snippet is truncated, specifically omitting the full implementation of the `_available`, `_releaseFor`, and `_releaseAllFor` internal functions. These functions are central to the core vesting mechanism, calculating releasable amounts and handling token transfers. Without their complete code, a comprehensive security assessment of the vesting logic cannot be performed.
FixProvide the complete source code for all relevant functions to enable a thorough security review of the vesting mechanism.
StatusUnresolved
Info

`pool` Address Excluded from Balance Limit

I-02The `lockPool` function, callable by the owner, sets a `pool` address and then explicitly excludes this address from the balance limit checks by setting `isExcludedFromBalanceLimit[pool_] = true`. This design choice allows the designated pool contract to hold an unlimited amount of tokens, bypassing the `maxBalanceLimit`.
IssueThe `lockPool` function, callable by the owner, sets a `pool` address and then explicitly excludes this address from the balance limit checks by setting `isExcludedFromBalanceLimit[pool_] = true`. This design choice allows the designated pool contract to hold an unlimited amount of tokens, bypassing the `maxBalanceLimit`.
FixEnsure that the `pool` contract is thoroughly audited and trusted, as its exclusion from the balance limit could be exploited if the pool contract itself is compromised or contains vulnerabilities. Document the rationale for this exclusion clearly.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

The contract leverages well-audited Solady libraries for its ERC20 and Ownable functionalities, contributing to a solid foundation (7.1 Architecture). It utilizes custom errors for clear error handling and implements pre-mint limits to control initial allocations (7.2 Code Security). However, a critical flaw exists where the balance limit mechanism, a key security feature, is not enforced during token transfers due to a missing `_beforeTokenTransfer` override (7.2 Code Security). The core vesting logic could not be fully reviewed due to truncated code (7.2 Code Security).

GovernanceHigh2/10

The economic model incorporates vesting schedules with cliff and duration periods, along with pre-mint limits to manage initial token distribution effectively (7.4 Economic). The `initialize` function includes robust checks for vesting parameters and allocation limits. However, the contract relies on a centralized `owner` for critical administrative actions like `lockPool` and `unlockPool`, and a `controller` for `disableBalanceLimit` (7.5 Governance, 7.3 Access Control). This centralization introduces a single point of failure.

UpgradesHigh1/10

The contract incorporates the `Initializable` pattern from Solady and correctly calls `_disableInitializers()` in its constructor, preventing re-initialization in a non-proxy deployment (7.7 Upgrades). While the provided information indicates it is not a proxy, the code is structured to be compatible with proxy patterns if future upgradeability is desired. This demonstrates foresight in design.

Security Checklist

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

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable

Holder Composition

65.9% in top 10
8.3% in wallets57.5% in contracts
Effective Concentration31.4%

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

$80.0K across 7 pairs
Uniswap v4WETHanalysed$79.7K99.6%Uniswap v4USDC$2800.3%Uniswap v4USDC$50.0%Uniswap v4USDC$30.0%Uniswap v4ETH$20.0%Uniswap v4USDC$10.0%
Show 1 more pairShow less
Uniswap v4USDC$10.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 Holder52.4%
Top-3 Unlocked94.7%

Key Addresses

10 addresses
Deployer
0x2915…1465
Unlocked LP Held By
0x0792…b0810x0f44…33860x5c9b…0a8b0x789f…f2520x8a22…6c400x1c58…dc490xb63d…04c50xff59…adea0xd8ca…fd32

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

What Raised This Score

11 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% (65.9% total → 31.4% effective; 8.3% in EOAs, 57.5% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 52.4% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 94.7% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 1 Critical 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
ChipCritical RiskWrapped PROS (PROS)Critical RiskThe White Wolf (WOLF)Critical RiskSport.fun (FUN)Critical RiskREPPOCritical RiskRecallCritical Risk

Would You Like a More Detailed Audit of defi-native?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit