Quantum Audit Logo
Launch App

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

Is CAPACITR Safe?

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 record
Chart
Medium RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical8/10Governance4/10Upgrades7/10Checks passed5 of 7Findings2 Medium · 1 Low · 2 Info5
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.

Read the full analysis
What raised the score
  • Ownership not renounced — owner is a contract
  • Top-10 concentration > 30%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 81.3%
  • LP top3 unlocked holders = 98.1%
  • 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)
  • 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

Security Checklist

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

Holders

as of audit · Sep 4, 2026
58.0%Contracts9.6%Wallets32.4%Everyone else
58.0%Contracts9.6%32.4%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
67.6%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking58.0%
  • Walletsanonymous holders, free to sell9.6%
  • Everyone elsethe rest of the supply32.4%
Effective concentrationwhat the score reads32.8%
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$111.4K across 4 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$111.2KShare of depth99.8%
Top-1 Unlocked Holder81.3%
Top-3 Unlocked98.1%
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.

Security Findings

2 Medium1 Low2 Info
Medium

Denial of Service via mintInflation Gas Limit

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

Issue

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

Fix

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

Status

Unresolved

Medium

Centralized Control by Owner

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

Issue

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

Fix

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

Status

Unresolved

Low

Vesting Precision Loss Due to Integer Division

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

Issue

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

Fix

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

Status

Unresolved

Info

PERMIT_2 Unlimited Allowance

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

Issue

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

Fix

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

Status

Unresolved

Info

Non-Upgradeability of Contract

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

Issue

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

Fix

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

Status

Unresolved

Analysis

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

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.

Technical8/10Low risk

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.

Governance4/10Medium risk

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

Upgrades7/10Low risk

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

Final RecommendationWhat to do about this score

It is recommended to implement a multi-signature wallet for the owner address to mitigate the risks associated with centralized control.

For the mintInflation function, consider implementing a gas-efficient mechanism to process inflation over long periods, such as capping iterations or allowing batch processing. While the contract is not upgradeable, for future projects, evaluating an upgradeable proxy pattern could provide flexibility. Users should be fully aware of the implications of granting unlimited allowance to PERMIT_2.

Contract & Record

1 audit on record
TypeToken
NetworkBase
Token age3mo
Contract0x65f8…9ba3
Deployer0x23b3…dffc
Badge for your website
CAPACITR 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. Aug 30, 202648Medium

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

Frequently Asked Questions

What is the CAPACITR contract address?

The CAPACITR contract on Base is 0x65f8152809dd1fc0d5d8a345c9008d37b95f9ba3. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is CAPACITR a scam?

Quantum Audit's risk score for CAPACITR is 48/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Retained; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is CAPACITR liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $111.4K.

Who holds CAPACITR?

As of Sep 4, 2026, the 10 largest holders own 67.6% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
Coinbase Wrapped Staked ETHCBETH · Base48MediumThe Innovation GameTIG · Base48MediumBasemateBase48MediumKAITOBase48MediumiPodBase48MediumA Society For AI Agents1F916 · Base48Medium

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