Quantum Audit Logo

Is SETZ a Scam?

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

SETZ SETZ
0x020e…1ba3
Base Not verifiedLast checked 3d ago 1 audit on record New Launch · 1d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

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.

1 High2 Medium1 Low1 Informational
! 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.
Volume 24h
$152.4K
Liquidity
$120.5K
Price
$0.000002983
Token Age
1d
Top 10 Holders
49.3%

Security Findings

1 High2 Med1 Low1 Info
High

Centralized Control of Balance Limit

H-01The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Medium

Immutability of Key Economic and Vesting Parameters

M-01Several 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.
IssueSeveral 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.
FixEvaluate 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.
StatusUnresolved
Medium

Unrestricted `releaseFor` Function Access

M-02The `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.
IssueThe `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.
FixConsider 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.
StatusUnresolved
Low

Misleading `BalanceLimitDisabled` Event Parameter

L-01The `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.
IssueThe `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.
FixRename 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.
StatusUnresolved
Info

`computeAvailableVestedAmount` Overload Clarity

I-01The 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.
IssueThe 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.
FixTo enhance clarity for integrators and users, consider renaming the function that sums across all schedules to `computeTotalAvailableVestedAmount` or similar.
StatusUnresolved

Category Ratings

TechnicalMedium6/10

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.

GovernanceHigh3/10

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.

UpgradesHigh2/10

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.

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

49.3% in top 10
4.3% in wallets45.0% in contracts
Effective Concentration22.3%

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

$120.7K across 5 pairs
Uniswap v4WETHanalysed$120.5K99.9%Uniswap v4USDC$1240.1%Uniswap v4USDC$290.0%Uniswap v4USDC$140.0%Uniswap v4USDC$20.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 Holder54.3%
Top-3 Unlocked85.8%

Key Addresses

9 addresses
Deployer
0x2891…bc4c
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.

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

Related Audits

6 more on the record
Metronome Synth USD (MSUSD)High RiskCoW Protocol Token (COW)High RiskEthy AI by Virtuals (ETHY)High RiskResearchCoin (RSC)High RiskFren PetHigh RiskRIZEHigh Risk

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