Quantum Audit Logo
Launch App

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

Is SETZ a Scam?

Base
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 · 1d old
Chart
High RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical6/10Governance3/10Upgrades2/10Checks passed4 of 7Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The DopplerERC20V1 contract implements an ERC20 token with vesting functionalities and a temporary 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 > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 54.3%
  • LP top3 unlocked holders = 85.8%
  • Token age < 7 days
  • 1 High finding(s) from audit
  • 2 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 > 20% (49.3% total → 22.3% effective; 4.3% in EOAs, 45.0% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 54.3% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 85.8% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • Token age < 7 days (early, volatile)
  • 1 High finding(s) from audit
  • 2 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 (1d 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
45.0%Contracts4.3%50.7%Everyone else
45.0%Contracts4.3%50.7%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
49.3%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking45.0%
  • Walletsanonymous holders, free to sell4.3%
  • Everyone elsethe rest of the supply50.7%
Effective concentrationwhat the score reads22.3%
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$120.7K across 5 pairs

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$120.5KShare of depth99.9%
Top-1 Unlocked Holder54.3%
Top-3 Unlocked85.8%
Unlocked LP held by
0x0792…b0810x106f…6a890x789f…f2520x5c9b…0a8b0x36cd…2e920x87d8…d0db0x30be…31180x3d25…8d99

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

Security Findings

1 High2 Medium1 Low1 Info
High

Centralized Control of Balance Limit

The controller address has the unilateral ability to disable the token's balance limit at any time via disableBalanceLimit(). This grants a single entity significant power over a core economic parameter, which, if compromised or misused, could drastically alter token distribution dynamics and market stability. This impacts 7.3 Access Control and 7.4 Economic.H-01

Issue

The controller address has the unilateral ability to disable the token's balance limit at any time via disableBalanceLimit(). This grants a single entity significant power over a core economic parameter, which, if compromised or misused, could drastically alter token distribution dynamics and market stability. This impacts 7.3 Access Control and 7.4 Economic.

Fix

Consider implementing a multi-signature wallet or a time-locked governance mechanism for the controller role, or introduce a timelock for the disableBalanceLimit function itself to provide a window for community review or intervention.

Status

Unresolved

Medium

Immutability of Key Economic and Vesting Parameters

Several critical parameters, including MAX_PRE_MINT_PER_ADDRESS_WAD, MAX_TOTAL_PRE_MINT_WAD, MIN_VESTING_DURATION, maxBalanceLimit, and balanceLimitEnd, are set as immutable constants or during the initialize function and cannot be modified post-deployment. While this provides certainty, it removes flexibility to adapt to unforeseen market conditions or evolving project requirements without a full contract upgrade. This impacts 7.4 Economic and 7.8 Operations.M-01

Issue

Several critical parameters, including MAX_PRE_MINT_PER_ADDRESS_WAD, MAX_TOTAL_PRE_MINT_WAD, MIN_VESTING_DURATION, maxBalanceLimit, and balanceLimitEnd, are set as immutable constants or during the initialize function and cannot be modified post-deployment. While this provides certainty, it removes flexibility to adapt to unforeseen market conditions or evolving project requirements without a full contract upgrade. This impacts 7.4 Economic and 7.8 Operations.

Fix

Evaluate whether these parameters truly need to be immutable. For parameters that might require future adjustments, consider making them configurable by the owner or through a governance mechanism, potentially with timelocks.

Status

Unresolved

Medium

Unrestricted releaseFor Function Access

The releaseFor(address beneficiary, uint256 scheduleId, uint256 amount) and releaseFor(address beneficiary, uint256 amount) functions are external and lack access control. This allows any external address to call these functions and trigger the release of vested tokens for any beneficiary. While tokens are transferred *to* the beneficiary, this design choice could lead to unexpected gas costs for beneficiaries if malicious actors repeatedly call these functions, or it might not align with the project's intended user experience for claiming tokens. This impacts 7.3 Access Control and 7.2 Code Security.M-02

Issue

The releaseFor(address beneficiary, uint256 scheduleId, uint256 amount) and releaseFor(address beneficiary, uint256 amount) functions are external and lack access control. This allows any external address to call these functions and trigger the release of vested tokens for any beneficiary. While tokens are transferred *to* the beneficiary, this design choice could lead to unexpected gas costs for beneficiaries if malicious actors repeatedly call these functions, or it might not align with the project's intended user experience for claiming tokens. This impacts 7.3 Access Control and 7.2 Code Security.

Fix

Consider restricting the releaseFor functions to only allow the beneficiary themselves or a specifically authorized address (e.g., the owner or controller) to initiate a release. Alternatively, if the current design is intentional, document this behavior clearly to manage user expectations.

Status

Unresolved

Low

Misleading BalanceLimitDisabled Event Parameter

The BalanceLimitDisabled event is emitted with a hardcoded false value for its expired parameter when disableBalanceLimit() is called. This parameter name is misleading, as the limit is being disabled by the controller, not due to expiration. This impacts 7.2 Code Security and 7.8 Operations.L-01

Issue

The BalanceLimitDisabled event is emitted with a hardcoded false value for its expired parameter when disableBalanceLimit() is called. This parameter name is misleading, as the limit is being disabled by the controller, not due to expiration. This impacts 7.2 Code Security and 7.8 Operations.

Fix

Rename the expired parameter in the event to something more generic like byExpiration or isExpired, and pass false when disabled by the controller and true if the limit naturally expires (though there's no explicit expiration check in the current code for this event). Alternatively, add a new parameter to indicate the reason for disabling.

Status

Unresolved

Info

computeAvailableVestedAmount Overload Clarity

The contract provides two computeAvailableVestedAmount functions: one that takes a scheduleId and one that does not (which sums across all schedules). While functional, the overloaded name for the latter might be ambiguous for integrators. This impacts 7.2 Code Security.I-01

Issue

The contract provides two computeAvailableVestedAmount functions: one that takes a scheduleId and one that does not (which sums across all schedules). While functional, the overloaded name for the latter might be ambiguous for integrators. This impacts 7.2 Code Security.

Fix

To enhance clarity for integrators and users, consider renaming the function that sums across all schedules to computeTotalAvailableVestedAmount or similar.

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 functionalities and a temporary balance limit mechanism. The contract is deployed as an upgradeable proxy, leveraging Solady libraries for efficiency and security. Key features include owner-controlled pool locking, controller-managed balance limit disabling, and a robust vesting schedule system. While the codebase demonstrates high quality and adherence to best practices, the audit identified a high-severity access control issue related to the balance limit, medium-severity concerns regarding parameter immutability and unrestricted release functions, and minor informational findings.

Technical6/10Medium risk

The contract exhibits strong technical foundations (7.2 Code Security), utilizing audited Solady libraries for ERC20, Ownable, Initializable, and ERC20Votes functionalities. The vesting mechanism, including the use of LibTransient for storage optimization, is well-implemented. However, a high-severity access control flaw (7.3 Access Control) was identified where the 'controller' can unilaterally disable the balance limit, posing a significant centralization risk. The releaseFor functions also lack specific access controls, allowing anyone to trigger token releases for beneficiaries.

Governance3/10High risk

The economic model (7.4 Economic) incorporates a balance limit and vesting schedules, with initial parameters set during deployment. The owner has control over pool locking and token URI updates, while a designated controller can disable the balance limit. A key concern (7.5 Governance) is the centralized power of the controller to disable the balance limit without checks, and the immutability of critical economic parameters like maxBalanceLimit and balanceLimitEnd, which limits adaptability to future market conditions.

Upgrades2/10High risk

The contract is designed for upgradeability (7.7 Upgrades) using the Initializable pattern from Solady, with _disableInitializers() in the constructor and the initializer modifier. This setup is standard for proxy implementations, ensuring that the initialize function can only be called once. Storage layout considerations for future upgrades should be carefully managed, especially with the use of LibTransient for specific mappings.

Final RecommendationWhat to do about this score

To enhance the security and decentralization of the DopplerERC20V1 contract, it is recommended to implement a multi-signature wallet or a time-locked governance mechanism for the controller role, particularly for sensitive actions like disabling the balance limit.

Additionally, consider making key economic parameters configurable by the owner or through governance, allowing for greater flexibility in adapting to future project needs. Review the access control for releaseFor functions to align with the intended user experience for claiming vested tokens.

Contract & Record

1 audit on record
TypeProxy, Token
NetworkBase
Token age1d
Contract0x020e…1ba3
Deployer0x2891…bc4c
Proxy Upgrade Controls
Proxy TypeEtherscan Detected Custom
ImplementationVerified source
Upgrades (30d)0 · stable
Badge for your website
SETZ 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, 202668High
  2. Sep 3, 202657Medium

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

Related Audits

6 more on the recordAll audits
Metronome Synth USDMSUSD · Base68HighCoW Protocol TokenCOW · Base68HighBaseBase68HighPaperBase68HighEthy AI by VirtualsETHY · Base69HighLingoBase69High

Would You Like a More Detailed Audit of SETZ?

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