Quantum Audit Logo

Is ChipWorks a Scam?

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

ChipWorks CHIP
0x75af…1ba3
Base
Not verifiedThis 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.
Last checked 10d ago 1 audit on record New Launch · 3d old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The DopplerERC20V1 contract implements an upgradeable ERC20 token with vesting schedules and a balance limit mechanism. The audit identified a High-severity issue related to centralized control of the `controller` role, which can disable critical economic parameters. Medium-severity findings include a highly restrictive pool locking mechanism and automatic exclusion of vesting beneficiaries from balance limits, potentially impacting operational flexibility and distribution control. Several Low and Informational findings were also noted, primarily concerning operational resilience and initial token distribution design.

1 High2 Medium2 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (3d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$301.7K
Liquidity
$129.4K
Price
$0.00000333
Token Age
3d
Top 10 Holders
43.8%

Security Findings

1 High2 Med2 Low1 Info
High

Centralized Control of `controller` Role

H-01The `controller` role, a single address, has the sole authority to call `disableBalanceLimit()`, which can permanently deactivate the `isBalanceLimitActive` flag. This flag is a critical economic parameter designed to control token distribution. While the `owner` role is managed by an OZ ProxyAdmin (implying a multisig), the `controller` is a single point of failure. If the `controller` key is compromised, an attacker could disable the balance limit, potentially leading to unintended token accumulation by malicious actors.
IssueThe `controller` role, a single address, has the sole authority to call `disableBalanceLimit()`, which can permanently deactivate the `isBalanceLimitActive` flag. This flag is a critical economic parameter designed to control token distribution. While the `owner` role is managed by an OZ ProxyAdmin (implying a multisig), the `controller` is a single point of failure. If the `controller` key is compromised, an attacker could disable the balance limit, potentially leading to unintended token accumulation by malicious actors.
FixConsider implementing a multisig or a time-lock mechanism for the `disableBalanceLimit()` function, similar to the owner's upgrade capabilities. Alternatively, if the `controller` is intended to be a single entity, ensure robust key management practices are in place. Clearly document the responsibilities and security implications of the `controller` role.
StatusUnresolved
Medium

Restrictive `pool` Locking Mechanism

M-01The `lockPool` function, when activated by the owner, sets `isPoolLocked` to true and designates a `pool` address. Subsequently, the `_beforeTokenTransfer` hook restricts all transfers *from* this `pool` address to *only* the `DopplerERC20V1` contract itself. This highly restrictive condition could cripple the functionality of an external `pool` (e.g., an AMM, liquidity pool, or staking contract) if it is intended to distribute tokens to users, leading to operational issues or denial of service for that component of the ecosystem.
IssueThe `lockPool` function, when activated by the owner, sets `isPoolLocked` to true and designates a `pool` address. Subsequently, the `_beforeTokenTransfer` hook restricts all transfers *from* this `pool` address to *only* the `DopplerERC20V1` contract itself. This highly restrictive condition could cripple the functionality of an external `pool` (e.g., an AMM, liquidity pool, or staking contract) if it is intended to distribute tokens to users, leading to operational issues or denial of service for that component of the ecosystem.
FixRe-evaluate the intended purpose and operational flow of the `pool` locking mechanism. If the `pool` is meant to distribute tokens, consider relaxing the transfer restrictions when locked, or provide a clear mechanism for the `pool` to operate under specific conditions. Document the exact scenarios where `pool` locking is intended and its implications for integrated protocols.
StatusUnresolved
Medium

Automatic Balance Limit Exclusion for Vesting Beneficiaries

M-02In the `initialize` function, all addresses designated as `beneficiaries` for vesting schedules are automatically added to the `isExcludedFromBalanceLimit` mapping. This means these beneficiaries are not subject to the `maxBalanceLimit` check. While this might be an intentional design choice to ensure vested tokens can be received, it reduces the effectiveness of the balance limit for a potentially large group of token holders, potentially undermining the overall purpose of controlling token distribution.
IssueIn the `initialize` function, all addresses designated as `beneficiaries` for vesting schedules are automatically added to the `isExcludedFromBalanceLimit` mapping. This means these beneficiaries are not subject to the `maxBalanceLimit` check. While this might be an intentional design choice to ensure vested tokens can be received, it reduces the effectiveness of the balance limit for a potentially large group of token holders, potentially undermining the overall purpose of controlling token distribution.
FixConfirm if the automatic exclusion of all vesting beneficiaries from the balance limit is the desired economic strategy. If not, consider implementing a more granular control mechanism, such as allowing the owner or controller to explicitly include/exclude beneficiaries from the balance limit after initialization, or applying the balance limit to beneficiaries after their vesting period concludes.
StatusUnresolved
Low

Lack of Emergency Pause/Withdrawal Mechanism

L-01The contract lacks a mechanism to pause token transfers or to withdraw tokens held by the contract (e.g., `vestedTokens` minted to `address(this)`) in an emergency. In the event of a critical vulnerability, a market exploit, or a severe bug in the vesting logic, the owner or controller would have no immediate way to halt operations or recover funds, potentially leading to unrecoverable losses or continued exploitation.
IssueThe contract lacks a mechanism to pause token transfers or to withdraw tokens held by the contract (e.g., `vestedTokens` minted to `address(this)`) in an emergency. In the event of a critical vulnerability, a market exploit, or a severe bug in the vesting logic, the owner or controller would have no immediate way to halt operations or recover funds, potentially leading to unrecoverable losses or continued exploitation.
FixConsider implementing an emergency pause mechanism (e.g., using OpenZeppelin's `Pausable` contract) that allows the owner to temporarily halt token transfers. Additionally, evaluate if a controlled emergency withdrawal function for tokens held by the contract is necessary, perhaps with a time-lock or multisig requirement, to safeguard funds in extreme scenarios.
StatusUnresolved
Low

Controller Address Can Be `address(0)`

L-02The `controller` address is set during the `initialize` function. There is no explicit check to prevent `controller_` from being set to `address(0)`. If `controller_` is initialized as `address(0)`, the `disableBalanceLimit` function, which uses the `onlyController` modifier, would become permanently inaccessible, as `msg.sender` can never be `address(0)`. This would lead to an unchangeable state for the balance limit, potentially locking it active indefinitely.
IssueThe `controller` address is set during the `initialize` function. There is no explicit check to prevent `controller_` from being set to `address(0)`. If `controller_` is initialized as `address(0)`, the `disableBalanceLimit` function, which uses the `onlyController` modifier, would become permanently inaccessible, as `msg.sender` can never be `address(0)`. This would lead to an unchangeable state for the balance limit, potentially locking it active indefinitely.
FixAdd a `require(controller_ != address(0), InvalidControllerAddress())` check within the `initialize` function to ensure the `controller` role is always assigned to a valid address. This prevents accidental misconfiguration that could render critical functionality unusable.
StatusUnresolved
Info

High `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` Values

I-01Both `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` constants are set to `0.8 ether`. When used in calculations like `initialSupply * MAX_PRE_MINT_PER_ADDRESS_WAD / WAD`, this effectively allows up to 80% of the `initialSupply` to be pre-minted per address and in total during initialization. This design choice permits a highly concentrated initial distribution of tokens, which might have significant economic implications for decentralization, market liquidity, and price stability.
IssueBoth `MAX_PRE_MINT_PER_ADDRESS_WAD` and `MAX_TOTAL_PRE_MINT_WAD` constants are set to `0.8 ether`. When used in calculations like `initialSupply * MAX_PRE_MINT_PER_ADDRESS_WAD / WAD`, this effectively allows up to 80% of the `initialSupply` to be pre-minted per address and in total during initialization. This design choice permits a highly concentrated initial distribution of tokens, which might have significant economic implications for decentralization, market liquidity, and price stability.
FixReview and confirm that the high pre-mint limits (80% of initial supply) align with the project's intended token distribution strategy and decentralization goals. Document the rationale behind these limits and their potential impact on the token's economic model.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract is built on Solady libraries, demonstrating good code quality and gas efficiency. It implements standard ERC20 and ERC20Votes functionalities, along with a custom vesting system and a balance limit. The architecture (7.1) is clear, with distinct roles for owner and controller. However, the `pool` locking mechanism (7.2 Code Security, 7.8 Operations) is overly restrictive, potentially hindering legitimate operations. The absence of an emergency pause (7.2 Code Security) also presents an operational risk.

GovernanceHigh3/10

The contract incorporates vesting schedules and a balance limit to manage token distribution (7.4 Economic). The `initialize` function includes checks for vesting schedule validity and pre-mint limits. Access control (7.3) is managed by `Ownable` and a `controller` role. A High-severity issue was identified where the `controller` (a single address) can disable the balance limit, posing a centralization risk to economic parameters (7.5 Governance). Additionally, all vesting beneficiaries are automatically excluded from the balance limit, which could impact the intended distribution control (7.4 Economic).

UpgradesLow7/10

The contract is designed as an upgradeable proxy using the `Initializable` pattern (7.7 Upgrades), correctly disabling initializers in the constructor and using the `initializer` modifier. This allows for future logic updates without redeploying the token. The owner of the proxy is an OZ ProxyAdmin, indicating a multisig setup for upgrades, which enhances security. No specific vulnerabilities were found in the upgrade mechanism itself.

Security Checklist

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

Holder Composition

43.8% in top 10
2.6% in wallets41.2% in contracts
Effective Concentration19.1%

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

$129.5K across 8 pairs
Uniswap v4WETHanalysed$129.4K99.9%Uniswap v4USDC$650.0%Uniswap v3WETH$190.0%Uniswap v4USDC$90.0%Uniswap v4USDC$20.0%Uniswap v4USDC$00.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 Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x1d53…c613
Unlocked LP Held By
0xc1ea…f421

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

What Raised This Score

8 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 7 days (early, volatile)
  • 1 High finding(s) from audit
  • 2 Medium finding(s) from audit
  • 2 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
Venice Token (VVV)High RiskACUHigh RiskRainbow (RNBW)High RiskHOMEHigh RiskCTRHigh RiskMetronome Synth ETH (MSETH)High Risk

Would You Like a More Detailed Audit of ChipWorks?

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

Get Detailed Audit