Quantum Audit Logo

Is Basemate Safe?

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

Basemate BASEMATE
0x07e6…2ba3
Base Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The DERC20 token contract implements ERC20, ERC20Votes, ERC20Permit, and Ownable functionalities, featuring a vesting mechanism and an inflation-based minting system. While the contract utilizes OpenZeppelin libraries for standard token operations and access control, several critical and medium-severity issues were identified, primarily related to the inflation minting mechanism's gas consumption and potential for arithmetic errors, as well as a division-by-zero vulnerability in the vesting calculation. The owner, a 3/6 multisig, holds significant control over key parameters.

1 High2 Medium1 Low3 Informational
Volume 24h
$20.1K
Liquidity
$104.4K
Price
$0.000001718
Token Age
2mo
Top 10 Holders
56.9%

Security Findings

1 High2 Med1 Low3 Info
High

Denial of Service in `mintInflation` due to Unbounded Loop

H-01The `mintInflation` function contains a `while` loop that iterates for each full year passed since `currentYearStart_`. If `block.timestamp` is significantly far in the future (e.g., many years), this loop could execute a large number of times, potentially exceeding the block's gas limit. This would prevent the `mintInflation` function from ever being successfully called, effectively halting the token's inflation mechanism and impacting the protocol's economic model (7.2 Code Security, 7.8 Operations).
IssueThe `mintInflation` function contains a `while` loop that iterates for each full year passed since `currentYearStart_`. If `block.timestamp` is significantly far in the future (e.g., many years), this loop could execute a large number of times, potentially exceeding the block's gas limit. This would prevent the `mintInflation` function from ever being successfully called, effectively halting the token's inflation mechanism and impacting the protocol's economic model (7.2 Code Security, 7.8 Operations).
FixRefactor the `mintInflation` function to calculate the total mintable amount over multiple years in a single, constant-time operation, rather than iterating year by year. Alternatively, implement a mechanism to limit the number of years processed per call, requiring multiple transactions for large time gaps.
StatusUnresolved
Medium

Division by Zero Vulnerability in Vesting Calculation

M-01The `computeAvailableVestedAmount` function calculates vested tokens using `getVestingDataOf[account].totalAmount * (block.timestamp - vestingStart) / vestingDuration`. If `vestingDuration` is initialized to `0` in the constructor, this division will result in a 'division by zero' error when `block.timestamp >= vestingStart`, causing the `release()` function to revert for all users (7.2 Code Security). The constructor does not validate `vestingDuration_` to be non-zero.
IssueThe `computeAvailableVestedAmount` function calculates vested tokens using `getVestingDataOf[account].totalAmount * (block.timestamp - vestingStart) / vestingDuration`. If `vestingDuration` is initialized to `0` in the constructor, this division will result in a 'division by zero' error when `block.timestamp >= vestingStart`, causing the `release()` function to revert for all users (7.2 Code Security). The constructor does not validate `vestingDuration_` to be non-zero.
FixAdd a `require(vestingDuration_ > 0, "Vesting duration must be greater than zero")` check in the constructor to prevent `vestingDuration` from being set to zero.
StatusUnresolved
Medium

Potential Integer Overflow in `mintInflation` Calculations

M-02The `mintInflation` function performs calculations like `(supply * yearlyMintRate_ * timeLeftInCurrentYear)`. While Solidity 0.8+ reverts on overflow by default, if `supply` becomes extremely large, the intermediate product of these multiplications could exceed `type(uint256).max` before the final division. This would cause the transaction to revert, preventing further inflation minting and disrupting the token's supply schedule (7.2 Code Security).
IssueThe `mintInflation` function performs calculations like `(supply * yearlyMintRate_ * timeLeftInCurrentYear)`. While Solidity 0.8+ reverts on overflow by default, if `supply` becomes extremely large, the intermediate product of these multiplications could exceed `type(uint256).max` before the final division. This would cause the transaction to revert, preventing further inflation minting and disrupting the token's supply schedule (7.2 Code Security).
FixConsider reordering the multiplication and division operations to minimize the size of intermediate products, or implement checks to ensure intermediate values do not exceed `type(uint256).max` for very large `supply` values. For example, `(supply / (1 ether * 365 days)) * yearlyMintRate_ * timeLeftInCurrentYear` (with careful consideration for precision loss).
StatusUnresolved
Low

Inaccurate Yearly Calculation for Inflation

L-01The `mintInflation` function uses `365 days` as a constant for a year's duration. This approximation does not account for leap years, which occur every four years and have 366 days. This can lead to minor inaccuracies in the calculated inflation amount over long periods (7.4 Economic).
IssueThe `mintInflation` function uses `365 days` as a constant for a year's duration. This approximation does not account for leap years, which occur every four years and have 366 days. This can lead to minor inaccuracies in the calculated inflation amount over long periods (7.4 Economic).
FixWhile common in smart contracts, for higher precision, consider using a more accurate average year length or a more sophisticated time-tracking mechanism if exact yearly inflation is critical. Acknowledge this as a known precision trade-off.
StatusUnresolved
Info

Centralization of Control by Owner

I-01The contract inherits `Ownable`, granting the `owner` address significant control over critical functions such as `lockPool`, `unlockPool`, `burn`, `updateMintRate`, and `updateTokenURI`. While the owner is a 3/6 multisig, this still represents a centralized point of control that could be a single point of failure if the multisig signers are compromised or act maliciously (7.3 Access Control, 7.5 Governance).
IssueThe contract inherits `Ownable`, granting the `owner` address significant control over critical functions such as `lockPool`, `unlockPool`, `burn`, `updateMintRate`, and `updateTokenURI`. While the owner is a 3/6 multisig, this still represents a centralized point of control that could be a single point of failure if the multisig signers are compromised or act maliciously (7.3 Access Control, 7.5 Governance).
FixEnsure the multisig wallet holding ownership is secured with robust operational procedures, strong key management, and regular audits. Consider implementing time-locks for sensitive operations to provide a window for community review or emergency intervention.
StatusUnresolved
Info

`PERMIT_2` Granted Unlimited Allowance

I-02The `allowance` function is overridden to return `type(uint256).max` if the `spender` is `PERMIT_2` (0x0000…8BA3). This grants unlimited spending approval to the `PERMIT_2` contract for any user who has approved the DERC20 token for `PERMIT_2` (7.2 Code Security, 7.6 External).
IssueThe `allowance` function is overridden to return `type(uint256).max` if the `spender` is `PERMIT_2` (). This grants unlimited spending approval to the `PERMIT_2` contract for any user who has approved the DERC20 token for `PERMIT_2` (7.2 Code Security, 7.6 External).
FixThis is a common and intentional design pattern for `Permit2` integration. Users should be aware that by interacting with `Permit2` for this token, they are granting it unlimited spending capabilities. Ensure the `PERMIT_2` address is correct and trusted.
StatusUnresolved
Info

`MaxTotalVestedExceeded` Prevents 100% Initial Supply Vesting

I-03The constructor includes a `require(vestedTokens < initialSupply, MaxTotalVestedExceeded(...))` check. This design choice prevents the entire `initialSupply` from being allocated to vesting. If `vestedTokens` equals `initialSupply`, the constructor will revert (7.4 Economic).
IssueThe constructor includes a `require(vestedTokens < initialSupply, MaxTotalVestedExceeded(...))` check. This design choice prevents the entire `initialSupply` from being allocated to vesting. If `vestedTokens` equals `initialSupply`, the constructor will revert (7.4 Economic).
FixThis appears to be an intentional design constraint. Document this behavior clearly in project specifications to ensure it aligns with the desired token distribution strategy. If 100% vesting is ever desired, this `require` statement would need to be adjusted.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages well-audited OpenZeppelin libraries for core ERC20 functionality, voting, and access control (7.2 Code Security). The `_update` override correctly implements a pool lock mechanism (7.1 Architecture). However, the `mintInflation` function contains an unbounded `while` loop, posing a denial-of-service risk if a significant amount of time passes between calls (7.8 Operations). Additionally, the inflation calculation is susceptible to integer overflow for extremely large token supplies, and a division-by-zero error can occur in vesting if `vestingDuration` is zero (7.2 Code Security).

GovernanceMedium4/10

The contract's economic model includes a linear vesting schedule and a yearly inflation mechanism with a capped mint rate (7.4 Economic). The `owner` (a 3/6 multisig) has significant control, including the ability to lock/unlock the pool, update the mint rate, and burn tokens (7.3 Access Control, 7.5 Governance). While the multisig mitigates single-point-of-failure risks, the identified technical vulnerabilities in `mintInflation` could disrupt the intended economic model by preventing inflation from being triggered or causing it to revert due to gas limits or overflows (7.4 Economic). The `PERMIT_2` address is granted unlimited allowance, which is a design choice requiring trust in the `PERMIT_2` contract (7.6 External).

UpgradesLow7/10

The DERC20 contract is not designed as an upgradeable proxy. Its logic is immutable once deployed. This eliminates upgrade-related risks but means any discovered vulnerabilities or desired feature changes would require a new deployment and migration (7.7 Upgrades).

Security Checklist

3/5 checks passed
Contract VerifiedPass
Ownership RenouncedFail
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

56.9% in top 10
5.2% in wallets51.7% in contracts
Effective Concentration25.9%

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

$104.4K

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

3 addresses
Deployer
0x3f0f…59a1
Unlocked LP Held By
0x0d68…3b7b0xa204…07c1

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)
  • Top-10 concentration > 20% (56.9% total → 25.9% effective; 5.2% in EOAs, 51.7% in contracts — mild)
  • 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)
  • 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
Coinbase Wrapped Staked ETH (CBETH)High RiskThe Innovation Game (TIG)High RiskCAPACITRHigh RiskKAITOHigh RiskViciCoin (VCNT)High RiskAvantis (AVNT)High Risk

Would You Like a More Detailed Audit of Basemate?

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

Get Detailed Audit