Quantum Audit Logo

Is CAPACITR Safe?

On-chain security analysis — is it a scam or legit?

CAPACITR CAPACITR
0x65f8…9ba3
Base Not verifiedLast checked 3d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The DERC20 token contract implements an ERC20 token with voting, permit, and Ownable functionalities, incorporating a linear vesting schedule and an inflation mechanism. The contract leverages battle-tested OpenZeppelin libraries, contributing to a solid foundation. Key features include pre-minting with caps, a configurable yearly mint rate, and a pool locking mechanism. Identified risks primarily revolve around the centralized control of the owner and potential denial-of-service for the inflation mechanism under extreme conditions. The contract is not upgradeable, which implies immutability but also a lack of flexibility for future changes or bug fixes.

2 Medium1 Low2 Informational
Volume 24h
$16.6K
Liquidity
$111.2K
Price
$0.000001924
Token Age
3mo
Top 10 Holders
67.6%

Security Findings

2 Med1 Low2 Info
Medium

Denial of Service via `mintInflation` Gas Limit

M-01The `mintInflation` function contains a `while` loop that iterates for each full year elapsed since `currentYearStart`. If the function is not called for a very long period (e.g., many years), the number of iterations in this loop could become excessively large. This could lead to the transaction exceeding the block gas limit, effectively preventing any further inflation from being minted until the gas limit is increased or the contract is upgraded (if upgradeable). This would disrupt the intended tokenomics.
IssueThe `mintInflation` function contains a `while` loop that iterates for each full year elapsed since `currentYearStart`. If the function is not called for a very long period (e.g., many years), the number of iterations in this loop could become excessively large. This could lead to the transaction exceeding the block gas limit, effectively preventing any further inflation from being minted until the gas limit is increased or the contract is upgraded (if upgradeable). This would disrupt the intended tokenomics.
FixConsider implementing a mechanism to cap the number of years processed in a single transaction, or allow the owner to manually advance `currentYearStart` in batches. Alternatively, a pull-based system where users claim their share of inflation could distribute the gas cost. Another approach is to calculate the total inflation up to `block.timestamp` directly without a loop, if feasible with the current logic.
StatusUnresolved
Medium

Centralized Control by Owner

M-02The `owner` role, controlled by a single address, possesses significant power over critical contract functionalities. This includes the ability to `updateMintRate` (directly impacting token supply), `lockPool` and `unlockPool` (controlling token transfers to the designated pool), and `burn` tokens from the owner's balance. A compromise of this single owner address could lead to severe economic manipulation, unauthorized burning of tokens, or disruption of the token's utility.
IssueThe `owner` role, controlled by a single address, possesses significant power over critical contract functionalities. This includes the ability to `updateMintRate` (directly impacting token supply), `lockPool` and `unlockPool` (controlling token transfers to the designated pool), and `burn` tokens from the owner's balance. A compromise of this single owner address could lead to severe economic manipulation, unauthorized burning of tokens, or disruption of the token's utility.
FixIt is strongly recommended to secure the `owner` address with a multi-signature wallet to reduce the risk of a single point of failure. Additionally, consider implementing time-locks or a decentralized governance mechanism for highly sensitive operations, such as significant changes to the `yearlyMintRate`.
StatusUnresolved
Low

Vesting Precision Loss Due to Integer Division

L-01The `computeAvailableVestedAmount` function calculates vested amounts using integer division: `totalAmount * (block.timestamp - vestingStart) / vestingDuration`. While common in Solidity, integer division truncates any fractional part, which can lead to minor precision loss. This effect might be more noticeable for small `totalAmount` values or when the elapsed time is not perfectly divisible by the vesting duration, potentially resulting in a slightly lower amount being released than mathematically precise.
IssueThe `computeAvailableVestedAmount` function calculates vested amounts using integer division: `totalAmount * (block.timestamp - vestingStart) / vestingDuration`. While common in Solidity, integer division truncates any fractional part, which can lead to minor precision loss. This effect might be more noticeable for small `totalAmount` values or when the elapsed time is not perfectly divisible by the vesting duration, potentially resulting in a slightly lower amount being released than mathematically precise.
FixWhile this is a common and often acceptable trade-off in Solidity, for maximum precision, consider using a fixed-point math library (e.g., ABDKMathQuad) or adjusting the calculation to minimize truncation impact, especially if the token's smallest unit is significant. However, for most use cases, the current implementation is acceptable.
StatusUnresolved
Info

PERMIT_2 Unlimited Allowance

I-01The `allowance` function explicitly returns `type(uint256).max` for the `PERMIT_2` address (0x0000…8BA3). This means that any user who approves `PERMIT_2` (e.g., via the `permit` function) implicitly grants `PERMIT_2` an unlimited allowance to spend their tokens. While this is a design feature of `PERMIT_2` to enable gasless approvals and reduce transaction costs, it represents a significant security consideration for users.
IssueThe `allowance` function explicitly returns `type(uint256).max` for the `PERMIT_2` address (). This means that any user who approves `PERMIT_2` (e.g., via the `permit` function) implicitly grants `PERMIT_2` an unlimited allowance to spend their tokens. While this is a design feature of `PERMIT_2` to enable gasless approvals and reduce transaction costs, it represents a significant security consideration for users.
FixUsers should be explicitly informed that interacting with `PERMIT_2` implies granting an unlimited allowance. Clear documentation and user interface warnings are advisable to ensure users understand the implications of approving `PERMIT_2` for their tokens.
StatusUnresolved
Info

Non-Upgradeability of Contract

I-02The `DERC20` contract is deployed as a standard, non-upgradeable contract. This design choice means that its logic is immutable once deployed to the blockchain. Consequently, any future bug fixes, security patches, or desired feature enhancements would necessitate deploying an entirely new contract and migrating all existing token holders to the new contract. This migration process can be complex, costly, and disruptive to the community.
IssueThe `DERC20` contract is deployed as a standard, non-upgradeable contract. This design choice means that its logic is immutable once deployed to the blockchain. Consequently, any future bug fixes, security patches, or desired feature enhancements would necessitate deploying an entirely new contract and migrating all existing token holders to the new contract. This migration process can be complex, costly, and disruptive to the community.
FixFor projects with long-term roadmaps or those that anticipate future changes, consider implementing an upgradeable proxy pattern (e.g., UUPS or Transparent Proxy) from the outset. This allows for future flexibility, bug fixes, and feature additions without requiring a token migration. For this specific contract, the current design implies a commitment to immutability.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract (7.1 Architecture) is well-structured, inheriting from standard OpenZeppelin ERC20, ERC20Votes, ERC20Permit, and Ownable contracts. The inflation calculation and vesting logic are clearly defined. (7.2 Code Security) Arithmetic operations are safe due to Solidity 0.8.x checked math. However, the `mintInflation` function's `while` loop could potentially lead to a denial-of-service if not called for an extended period, causing excessive gas consumption. (7.6 External) The contract integrates with PERMIT_2, granting it unlimited allowance, which is a design choice of PERMIT_2.

GovernanceMedium4/10

(7.3 Access Control) The contract uses the Ownable pattern, granting significant control to a single owner address over critical functions like `updateMintRate`, `lockPool`, `unlockPool`, and `burn`. (7.4 Economic) The yearly mint rate is capped by `MAX_YEARLY_MINT_RATE_WAD`, and pre-minting in the constructor is subject to per-address and total caps, which helps manage initial token distribution. The vesting schedule is linear and immutable, providing predictability for vested token holders. (7.5 Governance) There are no explicit governance mechanisms beyond the owner's direct control.

UpgradesLow7/10

(7.7 Upgrades) The DERC20 contract is implemented as a standard, non-upgradeable contract. This design choice means that once deployed, its logic cannot be modified. While this provides immutability and reduces upgrade-related risks, it also means that any future bug fixes or feature enhancements would require a new deployment and a token migration process, which can be complex and costly.

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

67.6% in top 10
9.6% in wallets58.0% in contracts
Effective Concentration32.8%

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

$111.4K across 4 pairs
Uniswap v4WETHanalysed$111.2K99.8%Hydrex CLAMMWETH$1540.1%Uniswap v4USDC$820.1%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 Holder81.3%
Top-3 Unlocked98.1%

Key Addresses

7 addresses
Deployer
0x23b3…dffc
Unlocked LP Held By
0x1758…8df60x0dad…d24e0xed09…77380xc6af…dec30xd8ca…fd320xfb53…326c

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

What Raised This Score

7 factors
  • Ownership NOT renounced — owner is a contract (governance/executor, not an EOA)
  • Top-10 concentration > 30% (67.6% total → 32.8% effective; 9.6% in EOAs, 58.0% in contracts — moderate)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 81.3% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • LP top3 unlocked holders = 98.1% (independent LP — depth risk, pool = 100% of DEX liquidity)
  • 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
Coinbase Wrapped Staked ETH (CBETH)High RiskThe Innovation Game (TIG)High RiskBasemateHigh RiskKAITOHigh RiskViciCoin (VCNT)High RiskAvantis (AVNT)High Risk

Would You Like a More Detailed Audit of CAPACITR?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit