Quantum Audit Logo
Launch App

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

Is defi-native a Scam?

DEFI-NATIVEBase
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 recordNew Launch · 2d old
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance2/10Upgrades1/10Checks passed4 of 7Findings1 Critical · 1 Medium · 1 Low · 2 Info5
SummaryAI Copilot

The DopplerERC20V1 contract implements an ERC20 token with vesting capabilities and a balance limit mechanism.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Proxy contract
  • Non-standard proxy storage
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 52.4%
  • LP top3 unlocked holders = 94.7%
  • Token age < 7 days
  • 1 Critical 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)
  • 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

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.

Security Checklist

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

Holders

as of audit · Sep 4, 2026
57.5%Contracts8.3%34.1%Everyone else
57.5%Contracts8.3%34.1%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
65.9%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking57.5%
  • Walletsanonymous holders, free to sell8.3%
  • Everyone elsethe rest of the supply34.1%
Effective concentrationwhat the score reads31.4%
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$80.0K across 7 pairs
Show 1 more pair

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$79.7KShare of depth99.6%
Top-1 Unlocked Holder52.4%
Top-3 Unlocked94.7%
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.

Security Findings

1 Critical1 Medium1 Low2 Info
Critical

Missing _beforeTokenTransfer Override for Balance Limit Enforcement

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

Issue

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

Fix

Implement the _beforeTokenTransfer hook to include the necessary checks for isBalanceLimitActive, balanceLimitEnd, maxBalanceLimit, and isExcludedFromBalanceLimit for the to address before allowing any token transfer.

Status

Unresolved

Medium

Centralized Control by Owner/Controller

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

Issue

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

Fix

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

Status

Unresolved

Low

Potential Gas Cost for computeAvailableVestedAmount with Many Schedules

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

Issue

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

Fix

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

Status

Unresolved

Info

Truncated Code Prevents Full Vesting Logic Review

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

Issue

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

Fix

Provide the complete source code for all relevant functions to enable a thorough security review of the vesting mechanism.

Status

Unresolved

Info

pool Address Excluded from Balance Limit

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical6/10Medium risk

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

Governance2/10High risk

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.

Upgrades1/10High risk

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.

Final RecommendationWhat to do about this score

Prioritize the immediate implementation of the _beforeTokenTransfer override to correctly enforce the balance limit mechanism, as its current state renders it ineffective.

Enhance access control by implementing a multi-signature wallet for the owner and controller roles to mitigate risks associated with centralized control. Ensure that the complete source code for all vesting-related functions is available for a comprehensive security review to validate the integrity of the token distribution logic.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age2d
Contract0xad46…2ba3
Deployer0x2915…1465
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
defi-native 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, 202676High
  2. Aug 31, 202685Critical

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

Related Audits

6 more on the recordAll audits
ChipBase76HighXRP (Universal)UXRP · Base76HighVCATBase76HighMEGA YACHT CULTMYC · Base76HighWrapped PROSPROS · Base77HighCortexCX · Base77High

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